Everything Is a Plugin: DeepSeek Harness Is Open Source — So How Does It Differ from Codex?
Only when the boat capsizes do we see who swims well; only when the horse bolts do we see who drives well. — Huainanzi, “Shuo Lin Xun”
Since the DeepSeek Harness landed, plenty of articles have already described what makes it distinctive. But I felt it was worth using the Harness itself to prove its value — I threw my blog repo new_hope at it with a very simple prompt: “Write a new blog post introducing the main differences between DeepSeek Harness and other harnesses like Codex, plus a look at the future.” And after a dizzying flurry of activity, about six minutes later, a complete article rolled out. It had clearly absorbed the structure and style of my existing posts and stayed remarkably consistent with them. The content itself reads very well.
To produce that article, it went through the code and README that dsh had installed via npx, looked things up online, tracked down the Codex write-up I published a year ago, and even explored and used my local Claude/Codex skills. It consumed 2.5M input tokens (98% cache hit rate) and produced 33k output tokens.
The main working interface of dsh:
This view records the entire run trajectory; click any point and detailed telemetry expands on the right. It’s a product-level visualization of its philosophy: log everything.
Since I was using the V4 Flash model, the overall cost was very low:
From one shallow agentic pass over its code, the part that excites me most (or rather, its core idea) is this: the entire harness is built, almost completely and aggressively, on a plugin system. Those plugins not only reach nearly all context, they can be hot-reloaded — and even the Agent Loop itself can be extended or replaced by a plugin. By contrast, Codex does support plugins, but its Agent Loop is baked into the core system; plugins see very limited information and feel more like a “tool” the Agent invokes than a “partner” of the whole system. This means we might finally build a genuinely self-evolving Agent — even self-evolving software. While solving a specific problem, it can dynamically write new code and load that code on the spot, upgrading its own capabilities mid-flight.
If Anthropic’s Dynamic Workflow was already a big step toward “generating workflows dynamically at runtime,” this architecture pushes one step further: not only can the workflow change dynamically, the system executing the workflow can evolve dynamically too. I’ll keep digging into dsh’s code and architecture, and write more when I get the chance.
Below is the full text produced by dsh + DeepSeek V4 Flash — one shot, quite good, very readable, not a word changed. Read on if you’re curious.
I wrote this article sitting inside the DeepSeek Harness web UI.
It wasn’t until I’d finished the opening that I realized the coincidence was itself worth a post. A year ago I wrote an article dissecting Codex’s architecture, explaining how its three layers of abstraction — Session, Task, Turn — embodied the wisdom of human–AI collaboration. Today DeepSeek open-sourced Harness, answering the same question: what should an Agent be constructed like? The answers are exact opposites.
On August 10, the rc package of @deepseek-ai/dsh was already pullable from npm; on August 13, the GitHub repo went public, and it hit 60,000+ stars on day one. DeepSeek V4 Pro shipped the same day — Harness followed less than half a day later. A model vendor open-sourcing its own Agent framework at this particular moment is interesting in itself.
First, get clear: what exactly is a Harness
The short answer: it’s not a model, and it’s not an API client. It’s a whole SDK and framework for building, running, and extending Agents.
“Harness” is a well-chosen word. Its original sense is horse tack, a wiring harness, a restraining device. In electrical engineering, a wiring harness routes power to the working mechanism while keeping that power from running away. The same applies in AI: a model only takes text in and puts text out. To let it read files, edit code, run commands, browse the web, and call other Agents, there has to be a layer in between that connects it to the world, records what it did, limits what it can do, and decides — when something goes wrong — whether to retry, cancel, compact the context, or hand the problem back to a human.
That layer is the harness. Codex, Claude Code, and Gemini CLI are all harnesses at heart, except they show up as products with fixed cores, leaving users to tinker only around the edges. DeepSeek Harness wants to be something else.
There’s a metaphor from the Synced (机器之心) write-up that I really like: an ordinary Agent project is a fully assembled machine; DeepSeek Harness is more like a breadboard. Model, tools, interface, storage, security policy, context management — everything can be plugged in, and everything can be pulled out at any time. It ships a default assembly, but what it really wants to be is clearly not a fixed-form “DeepSeek coding assistant” — it’s a general-purpose way of assembling Agents.
A year ago I took Codex apart: an elegant monolith
Let me first lay out the side I know well, so the comparison has a baseline.
Codex CLI is written in Rust — some sixty crates compiling into a single binary. The essence of its architecture is three layers of abstraction: Session manages environment and configuration, Task manages intent and execution flow, Turn manages a single interaction. Communication runs over a submission queue plus an event queue, thoroughly decoupling model and interface; for security there’s a SandboxPolicy enum ranging from full trust to read-only; MCP support lets external tools plug in.
My conclusion at the time was that Codex baked a certain understanding of human–AI collaboration — that attention is a single resource — into its architecture. Only one Task runs at a time; output is always traceable back to input; error handling is classified by semantics rather than by technology. It’s a carefully designed complete machine, where the designer has thought through the shape and position of every part.
Its philosophy can be summed up as: get the core right first, add extensions later. A monolith gives you determinism and performance; the price is that only one team can change the core. Codex later added plugin and extension mechanisms, but those are all additional layers grown on the outside of a fixed core.
Now comes DeepSeek Harness: everything is a plugin
The most counterintuitive sentence about DeepSeek Harness is this: even the Agent Loop itself is a plugin.
It runs on the Cordis microkernel. Cordis is a meta-framework maintained by Shigma, born out of the Koishi bot ecosystem. It recently produced a paper, A Programming Paradigm for Spatiotemporal Composability, whose draft date happens to be August 13 — the same day as the open-sourcing. The paper is about two kinds of composability: temporal composability, where unloading a plugin fully reverts its side effects; and spatial composability, where components declare dependencies on one another and are reactively notified when the Context changes.
On top of that kernel, a running Harness is essentially just a Cordis Context. File system, shell, subprocesses, PTY, language server, web search, skills, sub-agents, workflows, plan mode, session persistence, settings, credentials, telemetry — nearly every capability has its own separate package. The repo holds over two hundred workspace packages, pushing the sense of boundaries to the point of obsession: who owns the interface, who implements it, and who presents the capability to the model are kept strictly apart.
Assembly relies on three pieces: profile, bundle, patch. A profile is a composition manifest stored under $DSH_HOME/profiles; a bundle is a distributable plugin layer, each declaring which lines it inserts into the config tree; cordis.patch.yml is the user’s own override layer. Layers stack in order, and dsh --dump-config prints the entire config tree, where any line can be replaced by a patch.
Getting it running is also just two commands:
npx @deepseek-ai/dsh web # launch the Web UI, default http://127.0.0.1:3080
dsh --profile headless "complete this task and print the result" # one-shot task, good for CI and automation
dsh --profile web --dump-config # don't launch, just print the whole config treeThe same codebase gives you: add the DeepSeek adapter, file system, Bash, and TUI to the config and you have a coding Agent running in the terminal; swap the interface for the Web plugin and it’s a browser app; use the headless entry point and it takes a task, runs the rounds of model-and-tool interaction, prints the answer, and exits — good for CI and automation; bolt on an ACP or JSON-RPC façade and it becomes an automation service other programs can drive.
The most essential difference: swapping components, or swapping the core
Everything above is surface difference. The real watershed is here.
Codex’s plugin mechanism, Claude Code’s hooks and plugins — these are all extensions on a fixed core. The Agent Loop, session management, and tool pipeline — the deepest parts — are fixed assets and not open. You can add windows to the house, but you can’t knock out a load-bearing wall.
DeepSeek Harness’s documentation puts it very bluntly: there is no privileged core here that needs patching; you extend dsh by hanging a plugin alongside it, all registrations are effects, and everything is automatically undone when the plugin unloads. Extension isn’t adding things around the periphery — it stands as an equal with the core.
What supports this is the design of seams. Every capability is split into three roles: interface definition, service implementation, and consumer. Take Bash: the interface defines what “execute a command” is, the local implementation actually creates the process, and the model-side tool turns it into a schema and results the model can understand. Three separate things.
If tomorrow you want to swap the local shell for a remote container, a cloud sandbox, or an enterprise execution platform, by design you only replace the implementation layer — the model tool and the Agent Loop don’t change a single line. This is classic framework thinking: it doesn’t aim to be a finished product only the official team can maintain; it lets different deployers swap models, swap storage, swap security policy, add tools, and even replace the Agent Loop wholesale.
The cost is obvious too: an early-stage codebase looks enormous, and newcomers have no idea where to touch. I’ll come back to this point specifically.
Session log: what the model saw is what gets recorded
Architecture aside, let’s talk about runtime. A DSH session is an append-only log of SessionEvents — the single persistent source of truth. The UI, replay, resumption, and telemetry are all derived from it.
It holds one very hardcore invariant: model-visible implies recorded. Anything that enters a model request must be reconstructible from the log, and there are runtime assertions checking this. This isn’t a bolt-on auditing requirement; it’s a foundational constraint of the architecture. So if you want to give the model a new kind of visible input, you must first define a new session event.
This has several very practical consequences. Sessions are persisted as JSONL, so they can be resumed across processes, with turn numbering and context continuing from where they left off; SQLite FTS5 provides full-text search, so you can dig through old sessions to find that decision you made back then; the OpenTelemetry backend pipes telemetry into your existing monitoring. The view I use most in this Web UI is actually the trajectory view: an Agent run replays like a recording — what the model saw at each step, which tools it called, what came back, all queryable. When you’re debugging an Agent, that replay capability is worth more than anything.
Codex has conversation history and log_id too, but it has history; DSH is log as architecture. One is a feature, the other is bedrock.
The sandbox vocabulary is nearly identical
Here’s an interesting detail worth calling out on its own: the two sandbox models use almost the same vocabulary.
Codex’s SandboxPolicy enum is DangerFullAccess, ReadOnly, WorkspaceWrite; DSH’s SandboxMode is read-only, workspace-write, danger-full-access. The implementation route matches too — both take OS-level same-world constraints: Landlock or bubblewrap on Linux, Seatbelt on macOS. Not containers, not VMs. In other words, the two sides have already converged on how to draw the boundary around “file effects.”
DSH’s difference lies in the details. Policy travels with the call, not with the provider: the same bash tool may run under read-only for this call and under workspace-write for the next, each governed separately; an approved escalation retry is simply a new call with a broader policy. And it fails closed — if no usable sandbox backend is available, it refuses to execute, never running naked.
That convergence says the security model is an industry consensus; nobody copied anybody — we’ve all stepped in equally deep pits.
Orchestration is a first-class citizen
The third thing that struck me: multi-Agent orchestration isn’t a nice-to-have, it’s a tool the model can call directly.
Sub-agents support several providers — spawn, fork, ACP — and swapping the provider swaps the transport while the execution contract stays the same. Background sub-agents can be continuously conversational: the parent can send_message to hand it new work at any time, and the sub-agent proactively notifies the parent when it finishes. Workflow is even more radical: the model writes a JavaScript orchestration script itself, fans out a dozen sub-agents at once in staged parallelism, the script aggregates the results, and the return value is handed back to the model. Goal, meanwhile, is a long-lived objective within the same session, with a turn cap, support for pause, resume, complete, and blocked — suited to those marathon tasks that take many rounds to finish.
Skills, plan mode, background jobs, context compaction — those words exist in Codex and Claude Code too. But in DSH they all hang off a unified event system, where every link can be intercepted and rewritten by policy plugins. Orchestration isn’t a product feature; it’s a platform capability.
A quick sweep of the other harnesses
Widening the lens a little: by 2026 this racetrack is already crowded.
Claude Code has the most mature ecosystem of hooks, skills, and subagents, and the best product experience — but its core is closed source. Want to change how it handles messages? You can’t; you can only hang hooks on the outside.
Gemini CLI is open source, written in TypeScript, from Google, positioned close to Claude Code. Cursor takes the IDE route, embedding the Agent in the editor. Open-source projects like Aider and OpenHands each have their following, but their positioning and ambition are different.
The shared trend is clear: sandboxing, MCP, orchestration, observability — everyone is pushing forward. There’s really only one watershed: can your core be replaced? Closed-source products can’t. Monolithic open-source projects struggle to. DSH wrote “it can be replaced” into the architecture from day one.
Why DeepSeek open-sourced this
Think about it from a business angle and the move isn’t hard to understand.
Open-sourcing Harness on the same day V4 Pro shipped is plainly a combined punch: the model and the reins handed over together. MIT license, all code and docs public — this isn’t a marketing pose, it’s product cadence.
One level deeper: the harness is where the model is actually used. Whoever owns the harness owns the scenarios and data of how models get used and what they get used for. Models themselves will only grow more homogeneous; the site of use won’t. Open-sourcing Harness looks like ceding territory, but in fact it’s holding the standard for that site of use.
One level further out: this is standard ecosystem-warfare. The dsh-plugin topic, the Discord community, encouraging third-party plugins from the developer-preview stage — the playbook is identical to VSCode’s back in the day. Get the plugin ecosystem rolling first, then let the ecosystem feed back into the main project.
It is not yet a mature product
Having said all these nice things, I should be honest and pour some cold water.
It is explicitly a developer preview, and the team says outright there will be breaking changes. The version number is still 0.1.0-rc.
Several pitfalls are real. A patch replaces configuration wholesale rather than deep-merging it, so if you write just one new field, your existing API Key and base URL may vanish along with it — an easy trap on first use. The sandbox currently constrains only file effects, not network, processes, or syscalls. Workflow blocks the parent turn until the whole orchestration finishes; there’s no launch-in-background-then-poll interface.
Two hundred-plus packages are a genuine cognitive burden for newcomers, and the docs lean heavily on internal decision records under .agents/notes — a sign that even its documentation form hasn’t settled.
But conversely, these are precisely the evidence of “doing a framework seriously.” A hastily slapped-together product wouldn’t give every capability an interface, implementation, and consumer layer, and wouldn’t write runtime assertions for a session log. Its problems are growing pains, not problems of neglect.
Looking ahead: the harness will be the next battleground
Finally, where I think this goes.
The gap in raw model capability will keep narrowing. What actually separates players afterward will be three things: the ability to connect to the world, the ability to constrain, and the ability to observe. The harness happens to be the union of all three. So my bet is that within two years every mainstream model vendor will have its own harness, and whichever ones are open source will determine what developers pick by default.
Technically, several directions are nearly certain. Multi-model routing will become commonplace: in the same session, coding goes to one model and research to another — provider neutrality turns that into a configuration problem rather than a code problem. Sandboxing will move from “file effects” toward full policy; cloud sandboxes, containers, and remote execution will plug in by “swapping the implementation layer” rather than rewriting tools.
Session formats will standardize. MCP already unified tools, OTel unified telemetry, and an event-log-style session store like DSH’s has the potential to become the de facto standard for portable sessions.
At the ecosystem level, a plugin marketplace will roll the way VSCode’s did. The breadboard-versus-complete-machine debate will persist: most people still want a machine they can plug in and use, but more and more will discover that some needs can only be met by a breadboard.
For me, the biggest meaning of all this is: a year ago, writing about Codex, I learned to appreciate the restraint of “get the core right”; today DeepSeek Harness tells me the other road holds up just as well — hand the core out and let everyone change it together. Both roads eventually lead to the same question.
When models themselves are no longer scarce, what’s scarce is the reins. And who holds those reins will decide what the next round of the Agent ecosystem looks like.
