DeepSeek Harness Treats Claude Code as a Plugin. That Is the Actual Bet.

The subagent seam in DeepSeek's MIT-licensed `dsh` can hand a turn to whatever agent binary sits on your PATH. Here is how to run it in ten minutes, and where that design moves your trust boundary.

Open the repository layout in deepseek-harness/AGENTS.md and scroll to the package list. Between guard/ and session/ there is a directory called hooks/, and its one-line description reads: "Claude Code/Codex hook bridges + wire-protocol library."

A few lines further down, in the section on editing the instructions, you find this: "CLAUDE.md symlinks AGENTS.md at root, packages/, and examples/; edit the real file."

DeepSeek released its own coding agent on August 13 and, in the same commit, pointed Anthropic's coding agent at its instruction file and shipped a bridge that runs your existing Claude Code hooks configuration. Most of the coverage filed this under "open-source Claude Code rival." The repository is doing something stranger than rivalry.

The competitor is a provider

Here is the sentence in docs/architecture.md that reframes the whole release:

Subagent providers vary just as widely behind one interface, from a fresh child agent to a delegated turn in another product.

A fresh child agent and a delegated turn in another product sit behind the same interface. In DeepSeek's design, Claude Code is not a competitor to be beaten on benchmarks. It is a subagent provider, occupying the same slot as any other implementation of that capability.

Coverage of the launch and the plugin ecosystem that formed around it both report that the harness can delegate work to Claude Code or Codex binaries already installed on your machine, resolved from the host PATH, with both switched off by default. I could not read the subagent subsystem doc directly this session, so treat the PATH resolution and the default-off state as reported rather than as something I confirmed line by line. What I did confirm from the repository itself is the shape underneath it: a subagent/ package group described as "subagent capability: Service Definition + providers + delegation Consumers," and an architecture document that names delegation into another product as one of the things that seam covers.

The position I will defend: this is the most important thing in the release, and it is not a feature. It is a claim about where value sits. If your harness can drive somebody else's finished agent as a subprocess, then the finished agent is a commodity and the thing that routes between them is the product. DeepSeek did not build a better Claude Code. It built the layer above Claude Code and gave it away under MIT.

How the seams work

The mechanism is worth understanding because it explains why one small change ripples through the whole product.

dsh is built on Cordis, a plugin kernel DeepSeek vendored rather than wrote. The architecture doc states the consequence bluntly: every part of the product is a plugin, including the model adapter, the tool registry, the session log, and the agent loop itself, "so every part is replaceable from configuration." And then: "There is no privileged core to patch."

The unit of replaceability is what the docs call a capability seam, and a seam is three roles, never one. A Service Definition declares the interface. A Service Provider implements it. A Consumer uses it, usually a model-facing tool. The repository's conventions file is strict about this: "A capability seam comprises Service Definition / Service Provider / Consumer roles. It is complete, never one role."

Why that matters shows up in one example from the architecture doc, and it is the cleanest illustration of the design I have read this year:

Filesystem and subprocess providers share one execution world, so pointing them at a remote sandbox moves Bash, PTY, and LSP with them, with no provider forks.

Swap two providers and three tools relocate. You never touched Bash. Bash was already asking the subprocess seam where to run, and the seam changed its answer. That is the same trick the subagent seam plays with other vendors' agents: the loop asks for a subagent, and what comes back might be a child of itself or might be Codex.

Underneath, registrations are effects. The conventions file requires that "every contribution goes through ctx.effect() / ctx.on(); a registry's register() returns the disposer." Mount a plugin and its contributions unwind when it unloads. That is the property that makes a plugin tree composable rather than a pile of side effects.

The composition itself is layered. A profile is a named stack of bundles plus your own cordis.patch.yml. Layers apply in order: each bundle, then the profile's patch, then the home-level patch, then any --patch overlay. A patch targets a row by id and replaces its whole config or inserts new rows. Which means you can see and rewrite the machine you are actually booting:

dsh --profile web --dump-config

Every row that prints can be replaced by a patch of your own. I would run that before running anything else, and I would read the output.

There is one more invariant worth carrying around: model-visible means logged. Anything that reaches a model request must be reconstructable from the append-only session log, and a runtime check asserts it. Fork, resume, transcripts, telemetry, and persistence all derive from that one stream.

Now hold that invariant next to the subagent seam, because this is my own reading rather than the docs': when a turn gets delegated into Claude Code, the steps inside that turn happen in Claude Code's session, under Anthropic's logging, on your Anthropic credentials. The dsh log can record that delegation happened and what came back. It cannot make another product's internals reconstructable from its own event stream. The invariant holds for dsh. It stops at the seam.

Put this into practice

The lowest-friction path takes about two minutes and needs no clone.

Run the published package. npx @deepseek-ai/dsh web starts the local web UI on 127.0.0.1:3080. No git, no build step, nothing installed globally.
If you clone instead, do not skip the build. The sequence circulating on social media (clone, pnpm install, pnpm dsh web) is missing pnpm run build between the last two. You need Node 22.19+ or 24+, and pnpm. One more trap: the default branch is master, not main, so any raw-file URL you construct with /main/ in it returns a 404.
Dump the config before you trust it. dsh --profile web --dump-config prints the plugin tree your machine actually boots. Read it once. This is the single highest-value ten minutes in the whole exercise, because everything else in this project is an argument about what is in that tree.
Start on the Minimal preset. It gives the agent two tools, persistent bash and str_replace_editor, and nothing else. Point it at a scratch repository. Minimal is also the preset DeepSeek's own published benchmark methodology names for its V4-Pro code-agent numbers, so running it is the cheapest way to see how much of an agent's behavior comes from the model and how much comes from the scaffolding wrapped around it.
Decide your sandbox before you turn anything on. The repository ships its own Node addon at native/, @deepseek-ai/node-addon-landlock-run, for Linux confinement, alongside macOS and Windows paths. Which one you get depends on your host, and most people will never check. Check.
Leave the Claude Code and Codex subagent providers off until steps 3 through 5 are done. Turning them on means DeepSeek's harness spends your Anthropic and OpenAI seats, under those vendors' terms, with those products' own permission models governing what happens inside the delegated turn. That is a decision, not a toggle.

Honest limitations

This is a developer preview and the repository says so in capital letters. The package version reads 0.1.0-rc.5. There are no GitHub releases and no tags behind the "v0.1" label the press is using.

The sharpest warning is in the project's own AGENTS.md, in a section headed "Pre-release stance: foundation over blast radius," which begins "Remove this section at the first tagged release." It goes on:

With no external consumers, prefer the correct foundation over compatibility shims: rename or repackage freely and update every reference together. Backends reject old on-disk formats. SQLite uses monotonic SCHEMA_VERSION; dsh-session keeps SESSION_FORMAT_VERSION at 0 with no compatibility promise.

Backends reject old on-disk formats. Your session history is not guaranteed to survive an upgrade, and the project has told you so in advance. Build plugins against this. Do not pin anything you care about to it.

Governance is one-directional. GitHub Issues are disabled on the repository; the tabs are Code, Discussions, Security, and Insights. Feedback routes through Discussions and a Discord, and coverage reports that DeepSeek is pointing contributors at plugins rather than at pull requests against its own tree. An architecture with no privileged core also has no privileged place to run a security review, and the project is recruiting third-party plugin authors while keeping its own repository closed to outside patches. Those two facts belong in the same sentence.

Star counts are useless here and I would ignore every one you see quoted. Loading two GitHub pages for this same repository minutes apart in one session returned 22.6k stars with 1.6k forks on one and 9.8k with 619 on the other. VentureBeat counted roughly 27,500 on August 13. One API query on August 14 read 88,975. Those numbers cannot all be describing the same thing, and none of them tells you whether the code is good.

The surface is also narrower than the incumbents. Primary interfaces are a local web UI, a headless command, and a Python SDK. There is no documented hosted background-agent service and no finished GitHub-native pull-request workflow. If you are choosing a daily driver today, this is not it.

What I would watch

The plugin ecosystem is the experiment, not the harness. DeepSeek asked third-party authors to tag their repositories with the dsh-plugin GitHub topic, and within days that topic filled with routers, UIs, vision chains, and subagent bridges written by people nobody has vetted. A plugin in an agent harness runs with whatever the agent has, which is your shell, your filesystem, and your credentials.

So the open question I cannot answer yet: does a plugin kernel with no privileged core make security better or worse? The optimistic reading is that a swappable sandbox provider and an unwinding effect system give you more places to put a control than a monolith does. The pessimistic reading is that every one of those places is also an injection point, and the project shipping them is not reviewing the plugins.

If you install a dsh-plugin this week, read the source of it first, and tell me what you found. I am more curious about that answer than about any benchmark row in the model card.

Sources: deepseek-ai/deepseek-harness, its AGENTS.md and docs/architecture.md (quoted directly), with release details and version status from Digital Applied and VentureBeat. Subagent PATH resolution and default-off state are reported by that coverage, not confirmed by me at the source.