The remaining P1 from the #939 review, plus the P2 it shares a mechanism with. Nothing carried a version, so two tabs editing one namespace silently overwrote each other — reproduced as tab B's `reasoning` lost to tab A's older draft. The seam's per-namespace write queue orders writes; it cannot tell a fresh writer from one replaying a snapshot a predecessor superseded. Each namespace now carries a monotonic `revision` over its RAW section. A write may send `expectedRevision`, checked at the FRONT of the queue (not at call time, which would race the very predecessor it guards against); a mismatch rejects with `SettingsConflictError` → `settings-conflict` on the wire, carrying both revisions. The editor captures the revision it opened at and, on conflict, asks the user to reopen rather than replaying its snapshot. The same counter fixes the missing broadcast. `settings/updated` is gated on the resolved value — correct for consumers, wrong for configuration surfaces: storing an override equal to the composition base leaves the resolved value alone while changing what the document says (the field is now overridden, not inherited) and moving every open editor's revision. `settings/document-updated (ns, revision)` fires on any raw-section change, in-process or external, and `host/settings-changed` now rides it. That event also closes the stale model picker: editing a provider's `models` changes no route, so `llm/adapters-updated` never fired and an open picker kept serving the old catalog. A change to an exposed provider namespace now emits `host/models-changed` too — that namespace holds the catalog. Docs: both sides of the five touched README pairs, a type-equiv block for `SettingsPathOp`, and an Agent Note recording what the plane exposes and who may overwrite what. The deferred wire-redaction gaps (secrets behind union/intersection/transform, `.default(...)` in the served envelope, schema text in rejection messages, `new Function` rehydration, pi-ai's `headers`) are recorded as TODO(settings-wire-redaction) and in Known Limitations rather than half-fixed.
DeepSeek Harness
English | 中文
DeepSeek Harness (dsh) is an open-source coding agent built on the DeepSeek Harness SDK.
It uses an architecture where everything is a plugin.
Install
Install dsh with one command:
curl -fsSL https://raw.githubusercontent.com/deepseek-harness/deepseek-harness/master/scripts/install.sh | sh
The installer requires git and Node ^22.19 || >=24, offers to install pnpm when it is missing, and prompts for a DeepSeek API key.
The installer keeps every checkout under ~/.dsh/source: the master clone at ~/.dsh/source/master and each install's staging checkout as a git worktree ~/.dsh/source/staging-<timestamp>. The stable symlink ~/.dsh/source/current points at the active staging worktree, and dsh in ~/.local/bin links to current/bin/dsh, so an upgrade repoints one symlink and the dsh on PATH never moves. Re-running the command adds a fresh staging worktree from an updated master and repoints current at it. See scripts/install.sh for alternate install locations and other options.
Use DeepSeek Harness
Web UI
For the recommended local interface, build the frontend after installation and after each update, then start the Web UI. Resolve the running checkout from the dsh launcher so the command holds regardless of which staging worktree is current (the launcher resolves through the stable current symlink):
dsh_bin=$(cd "$(dirname "$(command -v dsh)")" && pwd -P)/$(basename "$(command -v dsh)")
while [ -L "$dsh_bin" ]; do
link=$(readlink "$dsh_bin")
case $link in /*) dsh_bin=$link ;; *) dsh_bin=$(cd "$(dirname "$dsh_bin")" && cd "$(dirname "$link")" && pwd -P)/$(basename "$link") ;; esac
done
dsh_dir=$(cd "$(dirname "$dsh_bin")/.." && pwd -P)
pnpm --dir "$dsh_dir" run build && pnpm --dir "$dsh_dir" run build:web
dsh web
The Web UI is served at http://127.0.0.1:3080 by default.
TUI
Start the full-screen terminal interface:
dsh
Headless
Run one task, print the final answer, and exit:
dsh -p "summarize this workspace"
Why DeepSeek Harness
Built-in capabilities cover file reading, editing, and search; shell execution; reusable skills; task tracking; subagents and workflows; persistent sessions; and context compaction. The TUI also includes Plan Mode.
- Everything is a plugin. Models, tools, policies, storage, context management, and interfaces are composable Cordis plugins, so deployments can extend or replace behavior without forking the agent loop. See the architecture for the underlying design.
- Code Mode (opt-in). It exposes a
run_codetool and a generated TypeScript SDK; only program output re-enters model context. See Code Mode. - Self-referential Cordis tools are opt-in. They let the agent inspect its live runtime and mount or unmount plugins while it runs. See the Cordis tools.
Community
Follow DeepSeek Harness on Twitter for project updates.
Development
pnpm install
pnpm run test:coverage
Start with the development guide and read the architecture before changing packages.
For agents, follow AGENTS.md.
DeepSeek Harness is currently pre-release.