dsh-work-x
One install that turns a stock DeepSeek Harness into a batteries-included agent workstation.
dsh plugin --profile web add dsh-work-x dsh-better-sidebar
Restart dsh (plugins mount at startup). One line, two packages: the suite,
and the sidebar its Memory/Tasks/MCP workbench tabs live in — the sidebar IS
the primary form of the suite's product UI. (Headless/CLI profiles can drop
dsh-better-sidebar; DSH has no way yet for one plugin to auto-install a
companion — proposed upstream —
which is the only reason this is two names instead of one.) That is the entire setup: the suite
carries the pi2dsh engine and six
capability packages, versions pinned to combinations that have been verified
end to end on a real DSH loop — never "should work", always "was watched
working".
一条命令，把官方 DSH 变成开箱即用的全能 agent 工作台。装完重启 dsh 即可；
所有组件版本锁死在真机端到端验收过的组合上。
What you get, and why native DSH alone doesn't have it
| Capability | Stock DSH | dsh-x |
|---|
| MCP | Config-file servers, statically mounted; every tool costs context window | Lazy proxy (one tool + on-demand search/describe — dozens of servers without eating context), in-session manager, OAuth flows, MCP Apps (ui://), prompts→slash-commands, elicitation, sampling, fast cancellation — full verified matrix |
| Subagents | Low-level agent registry, no product surface | Spawn / parallel / background delegation, mid-run steering, resume (in-session and across restarts), stop-with-parent, per-child model & thinking level, live inheritance of your /model switches — acceptance report |
| Side conversations | — | /btw <question>: ask something off-topic without polluting the main context; answer lands in a side panel |
| Image generation | — | Codex-backed image generation as a normal tool call, generated pixels shown inline (bring your own Codex credential) |
| Persistent memory | Sessions forget everything | Cross-session facts, corrections and preferences (memory_add/memory_search, /memory-* commands), plus a Settings → Memory page on the web: browse and search what the agent remembers, pin/unpin standing rules with a hard budget |
| Background tasks | A long tool call pins the conversation | bg_run starts named shell jobs and keeps talking, bg_logs reads output mid-run, plus a tasks chip on the web: it joins the composer's status row while jobs run — live output, one-click kill |
The suite: pi-mcp-adapter ·
@tintinweb/pi-subagents ·
pi-btw ·
@crazygit/pi-codex-image-gen ·
pi-hermes-memory ·
pi-background-tasks,
running unmodified through the pi2dsh compatibility engine.
pi-hermes-memory builds a native SQLite store (better-sqlite3); if the
install stops with ERR_PNPM_IGNORED_BUILDS, run pnpm approve-builds inside
the profile directory (select better-sqlite3) and re-run the add — that gate
is the host's own supply-chain approval, not an error. Vision companion
routes are off in this suite; subscription logins stay whatever your DSH
profile already has.
Web first
dsh-work-x targets dsh web (and the desktop shells that wrap it) as its primary
surface. The automated regression drives a real browser against a clean
install and asserts each bundled package's own command is offered by the
composer — not that a file exists somewhere.
dsh plugin --profile web add dsh-work-x dsh-better-sidebar
dsh web --port 5179
dsh-better-sidebar is the
community sidebar the suite's product UI seats into: its Tasks page shows your
subagents natively (click through to steer or stop them), and dsh-work-x adds an
MCP tab there — this session's servers grouped by layer (project /
global), with per-project enable/disable. A machine-wide view of the same
servers lives in Settings → MCP and works with or without the sidebar.
With the sidebar installed, Memory and Jobs tabs appear there too —
the same panels in workbench form. Without
dsh-better-sidebar everything still runs — Settings → Memory and the tasks
chip carry the same functionality. (DSH has no way yet for one plugin to declare a companion bundle —
we've proposed one —
so the install command names both.)
On the DSH 0.1.2-alpha line? The sidebar ships per DSH generation:
install dsh-better-sidebar@0.18.0-alpha.0 there (its latest tag serves the
rc lines). dsh-work-x itself is one build for every supported generation.
Memory & background tasks
Primary form — the sidebar. With the one-line install above, the right
sidebar (VSCode-style, per session) carries the suite's workbench tabs: open
the ＋ next to the tab strip and add Memory or Jobs — they sit
beside Files, Terminal, Source Control, and stay while you chat.
- Memory tab — This project's memories first (named as such), then
other projects, global, and about-you groups, with search. The Pinned
rules section manages standing instructions injected into every turn:
pin from the input, unpin per entry, hard budget shown. Writes run
pi-hermes-memory's own /memory-pin command, so the store's
single-writer anti-injection design holds; the memory list itself is
read-only by design — edits and deletions go through the agent's memory
tools so store and search index never drift.
- Jobs tab — each background job's status, runtime and bytes; show
output streams a job's output while it is still running; Kill runs the
package's own
/kill.
Without the sidebar (headless-leaning installs) the same functionality
stays reachable: Settings → Memory is the full memory page, and while
jobs run a small clickable "N tasks running" chip joins the host's own
status row under the composer — click for the same panel; no jobs, no chip.
The side-chat dot stays the only floating piece either way.
Verified by the automated regression end to end on clean installs: the
memory surfaces show a fact that exists only in the plugin's store, a pin
round-trips through STANDING.md and back out, and the kill provably ends a
180-second job early — asserted from the store files and task snapshots on
disk, not from page text.
Configuration
Override engine config in your profile's user patch layer
($DSH_HOME/profiles/<p>/cordis.patch.yml), targeting the row by id — never
insert a second row:
- id: pi2dsh
config:
exclude: ["pi-btw"] # drop a suite member you don't want
Plugin-specific settings follow each plugin's own environment variables and
slash commands, as documented by the plugin.
How it works
dsh-work-x is a normal DSH bundle. Its patch mounts the pi2dsh engine (re-exported
through this package, so it resolves under pnpm's isolated layout), and the
engine reads this package's pi2dsh.suite manifest — an explicit list, one
dependency-hop from your profile — and mounts each member exactly as if you
had dsh plugin add-ed it yourself. No directory scanning, no forks, no
patched DSH internals; remove it with dsh plugin remove dsh-work-x and the whole
suite is gone.
Relation to pi2dsh
dsh-work-x is the curated product; pi2dsh is the engine and remains
independently installable for anyone who wants to pick their own Pi packages.
Anything verified for pi2dsh is inherited here at the same version pins.
