pi2dsh

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.

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: Published 0.27.x uses Pi 0.84.1; the 0.28 candidate targets Pi 1.4.0 with explicitly documented capability limits. 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 the 0.27.x / DSH 0.2.1 line, the validated terminal packages are @deepseek-harness-tui/dsh-tui@0.17.0 and @xmoon76/dsh-pi-tui@0.5.3. The older dsh-pi-tui 0.5.1 still references removed host components; upgrade that terminal rather than bypassing compatibility checks with allow-version.

For DSH 0.2.2-alpha.3, use pi2dsh@next (or Web suite dsh-work-x@next) with Node.js 24.9+. The published third-party terminals checked in this preview do not declare support for this host; Web and headless are independently tested. Stay on pi2dsh@0.27.1 / dsh-work-x@0.6.1 for DSH 0.2.1-rc.2 or rc.3. 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:

Then restart dsh — plugins mount at startup. A profile needs a surface bundle. DSH's built-in templates are web and headless. A custom profile is valid when its product installs a surface — for example @deepseek-harness-tui/dsh-tui in the dsh-tui profile. A bare arbitrary profile has no surface and can start with nothing to drive it, so add the intended surface to dsh.profile.bundles first.