Yichen Jiang
ef089ed6ec
`code` still carried `bash-env` behind its own `isolate` realm and its own `tool-subagent-report` row — the two the other three presets had already given back to the host. It was added a layer above the fix, so the rebase carried it forward untouched, and the shipped deployment ran a preset whose sessions get no `DSH_WEB_URL` in their shell and hand every subagent a second `report` registration on the host registry. Nothing caught it. A tool-catalog assertion cannot: neither row contributes a tool. The web lane cannot: no scenario composes `code` beside another preset, which is when the second `report` throws. The presets are near-copies of one another, so "fixed in three of four" is the shape this failure takes, and it will take it again. So the invariant is checked rather than described. `verify-cordis-config` now rejects any shipped preset row that is also active on the host plane, which is the property both defects violated: a row active on both planes is mounted once per process and once per session, and what that costs depends on the row — a provider behind an `isolate` realm shadows the host's for its own consumers, so a host contributor reaches nobody; a row registering into a host singleton registers once per live session, so the second collides.
@deepseek-ai/dsh
English | 中文
The dsh command is the product launcher for profiles: ordered stacks of plugin-bundle patch layers under the user's own overrides. src/args.ts owns the command grammar, and src/bin.ts loads only the selected runner. Invalid commands, options from another mode, configuration errors, and boot failures exit nonzero.
Entry modes
| Command | Purpose |
|---|---|
dsh --profile <name> |
Boot the named profile under $DSH_HOME/profiles/<name>. |
dsh --profile headless "task" |
Run one fresh persisted session, print the final answer, and exit. |
dsh web |
Alias of --profile web with the Web flag family (--host, --port, --dev, ...). |
dsh plugin --profile <name> <pnpm args> |
Manage a profile's plugins by forwarding to pnpm in the profile directory. |
The invoking directory is the default workspace root. The web and headless profiles auto-initialize on first use from shipped templates; any other profile must be created through dsh plugin.
Profiles
A profile directory holds a package.json (out-of-tree plugin dependencies plus the profile manifest dsh.profile with its ordered bundles list) and a cordis.patch.yml (the user's own patch layer, hot-reloaded on long-lived surfaces). The tree composes over an empty root: each bundle's patch in dsh.profile.bundles order, then the profile's cordis.patch.yml, then the home-level $DSH_HOME/cordis.patch.yml, then --patch overlays, then flag patches. Bundles named in dsh.profile.bundles resolve from the dsh installation first (@deepseek-ai/dsh-base, @deepseek-ai/dsh-web-app, @deepseek-ai/dsh-headless), then from the profile's own node_modules, where pnpm installs out-of-tree plugins. Use --dump-default-config and --dump-config to inspect the composed tree without booting it.
The CLI behavior reference owns exact layer precedence, flags, shutdown behavior, deployment defaults, and the source launcher.
Development
Production runs require built package and frontend artifacts. From a checkout, pnpm run dsh runs the TypeScript entry and forwards arguments; the source-launcher reference describes the PATH symlink and module-resolution contract.