Your Pi extensions now have a second host: run them unmodified on DeepSeek Harness

[weijiafu14]

For Pi extension authors: your packages now have a second host.

pi2dsh is a compatibility engine that runs Pi ecosystem packages on DeepSeek Harness as published on npm. No fork, no source modification, and no per-package conversion step.

Installation from the DSH side

# Install the compatibility engine once
dsh plugin --profile web add pi2dsh

# Then install any Pi package exactly as published
dsh plugin --profile web add <your-pi-package>

Restart DSH and the engine discovers the Pi packages explicitly added to that profile. The engine and each package remain independently upgradeable.

Nothing is required from the Pi package author. The package still sees Pi vocabulary: tools, commands, lifecycle events, ctx.ui, sessions, model registry, providers, OAuth, subprocesses, attachments, and child-agent creation. pi2dsh maps those calls onto DeepSeek Harness services through one general Host ABI implementation; the core does not contain package-specific branches.

A visual example: two ways to give a text-only model eyes

DeepSeek text models do not accept image input, while many coding-agent workflows need to inspect screenshots. pi2dsh automatically creates an image-admission companion for each text-only DSH model route, shown in the model picker as DeepSeek + Vision Bridge:

A user can paste an image into the normal Web composer:

Then a Pi package can handle it in either style:

• @kassing/pi-vision automatically calls a configured vision endpoint before the main model step and injects the analysis into the conversation.
• pi-vision-tool exposes describe_image, letting the agent decide when to inspect the image and control the prompt, compression, and reasoning depth.

Both packages install directly:

dsh plugin --profile web add @kassing/pi-vision
# or
dsh plugin --profile web add pi-vision-tool

Here is the automatic path running in a real DSH Web session: the pi2dsh:@kassing/pi-vision context-injection row carries the visual analysis, and the text-only DeepSeek model answers correctly:

Before the request reaches the original text-only adapter, image blocks are removed and only text is forwarded.

The same bridge is used beyond vision: Pi tools, slash commands, skills, event hooks, interactive OAuth flows, model calls, persistent session data, session control, compaction, and subagents run on the corresponding DSH host services.

• Repository: https://github.com/weijiafu14/pi2dsh
• Runnable vision example: https://github.com/weijiafu14/pi2dsh/tree/main/examples/vision-bridge
• npm: https://www.npmjs.com/package/pi2dsh

If you maintain a Pi package, no port is needed. If your users also work in DeepSeek Harness, point them at pi2dsh. Stars, real package reports, and Host API coverage requests are very welcome.

[weijiafu14]

Current install and demo:

dsh plugin --profile web add pi2dsh@0.10.0
dsh plugin --profile web add @kassing/pi-vision

No generated host bundle is required. pi2dsh is installed once as the compatibility engine; Pi packages are then added directly from npm and mounted unmodified.

The vision example is verified in both CLI and the DSH Web app: a pasted image is admitted through an automatically registered companion route, @kassing/pi-vision injects the visual analysis, and the original text-only DeepSeek adapter receives text only.

A second Pi package, pi-vision-tool, also runs through the same engine and gives the agent an on-demand describe_image tool.

Runnable example and screenshots: https://github.com/weijiafu14/pi2dsh/tree/main/examples/vision-bridge

[Averyyy]

Complementary direction: if you want to stay in Pi and give DeepSeek V4 Pro the official Harness minimal catalog (the model-card eval surface: one-line persona + bash + str_replace_editor), there is now pi-dsh-minimal:

pi install npm:pi-dsh-minimal

pi2dsh is Pi packages → DSH. This one is DSH minimal surface → Pi. Different job.

[weijiafu14]

Update: a provider/OAuth/attachment-heavy Pi package now runs unmodified on DSH too: @crazygit/pi-codex-image-gen.

dsh plugin --profile web add pi2dsh
dsh plugin --profile web add @crazygit/pi-codex-image-gen
# restart, then:
/login openai-codex

The full path is now verified on a real DSH Web session: ChatGPT Plus/Pro OAuth login → Codex model calls codex_generate_image → the package calls gpt-image-2 → returned PNG becomes a native DSH attachment → pixels render inline in the tool card. Reference-image editing also crosses Pi's ctx.ui.confirm into a real DSH approval dialog before the local file is uploaded.

The Pi package is unchanged. The host-specific work stays in pi2dsh: provider/model projection, OAuth credential publishing and refresh, tool ABI, attachment persistence, and the DSH browser surface.

Runnable example: https://github.com/weijiafu14/pi2dsh/tree/main/examples/codex-image-gen