DeepSeek Harness ecosystem review

Snapshot date: 2026-08-16.

Sources and limits

This review covered the official DeepSeek Harness repository and installation contract, the dsh-plugin GitHub topic, the Awesome DSH Plugin catalog, and the implementation pages of the closest projects. The community was only days old and changing rapidly on the snapshot date. Absence from these sources does not prove that no similar experiment exists.

Primary discovery sources:

• https://github.com/deepseek-ai/deepseek-harness
• https://github.com/topics/dsh-plugin
• https://github.com/awesome-dsh-plugin/awesome-dsh-plugin

Projects were grouped by the authority they control rather than by overlapping words such as security, guard, sandbox, or isolation. Several entries combine scanning, evaluation, recovery, and plugin management; each is listed under its closest material behavior so the review does not count the same idea as multiple independent gaps.

Ideas already covered by nearby projects

Candidate	Existing work	Deduplication conclusion
Durable runtime-composition history	william-jin-cmu/dsh-evolve hot-mounts and restores plugins; ZK-Andy/dsh-continual-evolve versions, audits, benchmarks, and rolls back harness state; swaylq/dsh-genie promotes dynamic Cordis packages into persistent plugins	Materially overlapping; not a distinct project gap
Generic plugin discovery or leasing	dsh-find-plugin, plugin markets and managers, dsh-tool-search, dsh-mcp-lens, and dsh-plugin-autoevo provide discovery, progressive disclosure, or installation	Already covered at several levels
Configuration and boot recovery	dsh-undo-plugin, dsh-guard, updater rollback, and Boot Guard restore configuration or recover from broken startup plugins	Recovery is not missing
Plugin evaluation	dsh-windtunnel, dsh-eval-harness, and forkprobe provide contract tests, scenario evaluation, and fork comparison	Evaluation is not missing
Trajectory governance	dsh-trajectory-governance, session audits, traces, and devtools observe loops, retries, and goal drift	Runtime observation is not missing

These projects are useful complements to Capsule. The deduplication conclusion is that scanning, scoring, installation, recovery, evaluation, and behavior observation are established categories; renaming one of them as a sandbox would not create a distinct runtime control.

Closest security projects

• BotonJ/dsh-plugin-sentinel: pre-install static bundle audit.
• truelove-dreamer/dsh-plugin-vetting: source and dependency scanning, integrity baselines, and an optional tool-call gate.
• omdsh-dev/dsh-security-audit: read-only deployment audit.
• SaiSenBox/dsh-boot-guard: recovery from likely broken startup plugins.
• x2802490130-prog/dsh-guard: snapshots and rollback after plugin failures.

These projects reduce risk before execution, constrain selected tool calls, report deployment state, or recover after failure. They do not remove ambient host authority from arbitrary JavaScript already executing inside the DSH process. Static analysis and integrity evidence also cannot enforce what malicious or compromised code may access at runtime.

Selected gap: runtime containment

The reviewed community guidance warns that an installed in-process plugin runs with the user's permissions, may read files and credentials, may reach the network, and is not constrained by model tool approval. This follows from the shared-process Cordis execution model rather than from a missing scanner rule.

dsh-capsule addresses that final gap for a narrower, explicit guest API:

1. the guest is a standalone integrity-pinned artifact and receives no Cordis Context or ambient host environment;
2. Linux Bubblewrap constructs an empty-root process, mount, PID, user, and network isolation boundary with Node controls as defense in depth;
3. activation and every tool invocation use separate ephemeral cells;
4. the trusted host publishes tools and static prompt sections through the real DSH registries and owns their disposal;
5. v0.1 may mount only an exact existing regular workspace file as read-only when the manifest request and deployment grant match exactly; directory, write, network, subprocess, and storage capabilities remain rejected;
6. failure to establish the requested artifact, policy, workspace mapping, or OS controls aborts activation without a weaker fallback.

This is runtime authority containment, not plugin trust certification. It does not make guest prompt text safe, protect against a compromised kernel or sandbox implementation, close side channels, or provide complete denial-of-service resistance.

No equivalent runtime plugin-isolation host was found in the reviewed DSH catalog or topic at the snapshot date. That dated finding is narrower than claiming that process isolation, capability security, Bubblewrap, or ephemeral execution is a new general technique.