Verdict: adopt, study, or wait?

The short answer

Study it now; do not build production on it yet. dsh is a genuinely well-architected agent harness and an even more valuable case study in agent-driven development — but it is a developer preview that promises to break, accepts no external contributions, and rests its safety on a single boundary that leaves several capabilities uncovered. Read it, copy its best ideas, prototype against it if you like churn — but do not ship a product whose foundation is a thing its own authors say has no compatibility floor.

Who should do what

If you are designing your own harness: this is required reading. Steal, in priority order: the log-as-single-source-of-truth with a runtime desync invariant (strength 1), the single-sourced prompt/executor predicates (strength 4), monotonic guards-by-type (strength 5), fail-closed defaults everywhere (strength 2), and the honest "this is not a boundary" comment discipline (strength 3). These are portable design ideas independent of Cordis.

If you want to run an agent on a trusted machine over trusted input: dsh is usable today via dsh web or headless, with the caveat that its confinement means "keeps file writes in the workspace", not "safe against hostile content". Understand Theme A before you point it at anything you did not write.

If you want to run an agent over untrusted input, or ship a product on it: wait. There is no command-level shell gate, run_code escapes the file sandbox, there is no web authentication, and the whole surface is explicitly non-contractual. The security model is honest but thin, and the version line is churning daily.

If you are running your own high-velocity, agent-heavy team: the most transferable asset in this repo is not the harness — it is .agents/ and the process around it. The mandatory-Agent-Note discipline, the chain-of-thought-leakage scrubbing skill, the "verify external state, never trust an agent's report" review rule, and the postmortems are a working playbook for keeping agent-generated code honest at 39 PRs/day. Copy the practices; you do not need the harness to use them.

What to copy, concretely

1. A durable event log that the model's request is derived from, checked by a runtime invariant — the highest-leverage idea here.
2. Generate the model's rule text and the executor's enforcement from one predicate.
3. Make safety properties type properties (deny-only guards) rather than review disciplines.
4. Comment honestly where a boundary is not a boundary — and then remember that a green freshness gate does not make a generated doc true (Theme B).
5. Force per-package "Known Limitations" sections and write postmortems about process failure, not just bug fixes.

What to distrust

• The generated capability/tool docs — eight verified drifts from code; read the source, not docs/tool-catalog.md or docs/capability-seams.md, when it matters.
• The word "sandbox" in any doc — check whether the specific path is kernel-enforced (process argv) or advisory (fs fence, workflow VM, code runtime).
• Any file:line in this very review after upstream moves — the repo changes ~104 commits a day and promises breaking changes; re-verify before relying on a claim.
• Coverage and CI green as a completeness signal — the 100% gate exempts the client half, and master pushes currently get almost no hosted validation.

The one-paragraph bottom line

DeepSeek Harness is a serious, unusually honest piece of engineering built at extraordinary speed by a small team and a fleet of agents. Its architecture — everything-is-a-plugin over a vendored framework, with an enforced event-sourced session log — is sound and worth learning from. Its weaknesses are the weaknesses of its method and its stage: a security model with one boundary doing all the work, elaborate automation that guards format and freshness while correctness drifts underneath it, god files and a fix-heavy history from high-throughput generation, and a formal promise that none of it is stable yet. The most remarkable thing in the repository is that it tells you almost all of this about itself, in its own comments and postmortems, if you read closely — which is exactly what this review did.