Yichen Jiang
0512b12714
$DSH_HOME/.env had just become an ordinary environment layer, which left the harness resolving user-facing values from a flattened process.env that could no longer say where a value came from. A key stored through the web page stayed shadowed by an older key in the user's own .env. An endpoint could be redirected by the project: the invoking directory's .env is materialized like every other layer, and a base URL decides where a resolved API key is sent, so a DEEPSEEK_BASE_URL written into a model-editable workspace would send the user's credential — and the prompts carrying their code — to whatever host that file named. Give every user-facing value one ordering, with four kinds of source: explicit for this run per-operation override, CLI argument > authored by deployment --config / --config-replace > this launch's shell inherited process environment > product-managed store settings.yaml, .credentials.yaml > discovered file $DSH_HOME/.env > defaults schema default, shipped base, public default The domains differ only in which tiers exist. The earlier split — credentials ranking the environment over the managed file while settings ranked over the environment — was inconsistent: the distinguishing fact is who authored the source, not the domain. packages/util/environment owns an immutable snapshot with per-layer provenance. getFrom(name, sources) searches only the layers a caller names, and omitting one is a refusal rather than a demotion: the adapters ask for ['process', 'user-env'], so no reordering can let a project file back into a decision it was excluded from. isBootstrapOnly rejects, before anything is materialized, any .env setting a variable that governs how a process launches (PATH, SHELL, NODE_OPTIONS, LD_PRELOAD), where code or model-visible instructions load from (the whole DSH_* namespace, HOME, XDG_*), or how the network is reached (proxy and CA variables). The namespace is denied wholesale so a switch added later cannot become settable by being forgotten, and there is no opt-out. verify-config-source-ownership keeps both rules: no unregistered process.env read under packages/*/*/src (26 allowlisted with reasons), and no apiKey, baseURL, or headers inlined from the environment in shipped Cordis config — removing those inlines is what makes the deployment tier meaningful.
Examples
English | 中文
Runnable demos (not workspaces) that showcase how the harness is wired. Each example is a thin leaf: either a cordis.yml tree that picks swappable backends and loads one app package, or an overlay — a patch list dsh --config applies over the shipped composition (apps/cli/config/base.cordis.yml plus a surface overlay). Bundled compositions live in @deepseek-ai/dsh-cli-demo, @deepseek-ai/dsh-acp-demo, and their shared @deepseek-ai/dsh-agent-spine-demo bundle; the dsh surfaces use flat config trees instead. There is no start.ts; the terminal demo:* scripts boot through the dsh CLI, and the headless/ACP scripts invoke the cli-demo/acp-demo bins.
mcp-memory
Three default-off reference overlays connect a memory MCP server through the generic MCP client. Pick one file and pass it to dsh --config; DSH does not install or configure the upstream memory system. See mcp-memory/README.md for pinned prerequisites, identity mapping, the shared optional prompt, and the write → fresh-session recall → use verification recipe.
headless-agent
A non-interactive agent demo that accepts one positional task, runs one complete model/tool turn on the @deepseek-ai/dsh-cli-demo app, persists a fresh session, prints text, json, or stream-json, and exits.
Run with: pnpm run demo:headless "task" (needs DEEPSEEK_API_KEY). See headless-agent/README.md for the output contract, safety boundaries, and snapshot suite.
jsonrpc-agent
An unattended coding agent driven through the Python SDK: JSON-RPC stdio, foreground-only bash, read / write / edit, one foreground subagent, todo_write, JSONL persistence, and compaction. It excludes terminal UI, stdout logging, approvals, skills, and background task controls. See jsonrpc-agent/README.md.
web-cordis
The self-referential demo: the coding spine plus @deepseek-ai/dsh-tool-cordis, whose three tools (cordis_inspect / cordis_mount / cordis_unmount) let the agent inspect the current DSH process, mount model-written temporary Plugins (an event listener, a brand-new tool, or a service another temporary Plugin injects), and unmount them again. These Plugins exist only in memory and share one internal cordis-dynamic fiber subtree; ctx.fs/ctx.web ride along provider-only as capabilities they can use.
Run the browser UI at http://127.0.0.1:3081 with pnpm run demo:cordis, or the ACP server with pnpm run demo:cordis acp (both need DEEPSEEK_API_KEY). See the toolset Agent Note for the design and sandbox caveats.
acp-agent
An agent exposed as an Agent Client Protocol (ACP) automation server over JSON-RPC stdio, via @deepseek-ai/dsh-acp-demo. Programmatic clients create fresh sessions, send text prompts, consume committed assistant text, answer one-shot permission requests, and cancel work. It owns the ACP keyless snapshot suite.
Run with: pnpm run demo:acp (needs DEEPSEEK_API_KEY); pnpm run demo:code-mode boots the same server in Code Mode via the code-mode.cordis.yml overlay. See acp-agent/README.md for the protocol and snapshot-test contracts.
The default cordis.yml composes @deepseek-ai/dsh-sandbox-local, @deepseek-ai/dsh-bash-sandbox, and @deepseek-ai/dsh-user-approval. workspace-write confines bash and filesystem mutations to each session workspace; a wider retry becomes a one-shot machine permission request over ACP.