pi2dsh

English | 中文

Move a Pi setup to DeepSeek Harness without rebuilding it. The extensions, MCP manager, subagents, memory and background tasks you use on Pi install on DSH as the same npm packages and run unmodified — web, terminal and headless.

dsh plugin add pi2dsh            # once
dsh plugin add pi-mcp-adapter    # then the Pi packages you already use, straight from npm

MCP is the deepest-verified path: the full protocol surface — OAuth, resources, prompts, MCP Apps, elicitation, sampling, cancellation — runs through DSH's own approval and rendering (evidence matrix). What has been verified end to end is listed in What actually works today; nothing outside that table is claimed.

Version support is explicit:

pi2dsh	DSH host	Maintenance
0.27.1	0.2.1-rc.2 / 0.2.1-rc.3	Acceptance and release status
0.27.0	0.2.1-rc.2	Acceptance and release status
0.26.0	0.2.0-rc.2	Release verification
0.25.2	0.1.5-rc.2	Frozen checkpoint: release evidence

Pi extension semantics remain pinned to 0.84.1. New engine releases target the validated current DSH line; historical fixes start from their release tag when needed. DSH owns stored-session format migration. An untested host version is not included in the compatibility declaration.

For either supported DSH version, the validated terminal packages are @deepseek-harness-tui/[email protected] and @xmoon76/[email protected]. The older dsh-pi-tui 0.5.1 still references removed host components; upgrade that terminal rather than bypassing compatibility checks with allow-version.

Why this exists

DeepSeek Harness is built on ideas worth betting on — a durable, reconstructable session log, a clean service composition, an agent loop you can actually reason about. Its plugin ecosystem is young. Pi has a mature one: hundreds of published packages, many with real users.

pi2dsh is one compatibility layer that implements Pi's public extension ABI on top of DSH's native services, so a Pi package runs on DSH as published — no fork, no patch, no per-package adapter. For a Pi user or team that means switching hosts without rebuilding the toolchain; for a Pi plugin author it means a second host with no port to maintain. To the user everything looks like DSH; to the plugin everything looks like Pi.

At the same time, pi2dsh is an ongoing, full-surface, real-world test of DSH's architecture. Instead of patching individual plugins, it asks whether the models, tools, sessions, interaction, resources and client capabilities that Pi plugins rely on can preserve their logic and lifecycle using only DSH's public services and extension seams. If they can, that is strong evidence that DSH's architectural goals for building agents and an agent-plugin ecosystem have been achieved, at least along this dimension. Wherever the bridge must bypass, degrade or cannot express a capability, it pinpoints an architectural gap that remains.

Install

One engine, then whatever plugins you want:

dsh plugin --profile web add pi2dsh
dsh plugin --profile web add pi-mcp-adapter

Then restart dsh — plugins mount at startup.

…