Blog · Comparison

"It doesn't want to be the next Codex" — DSH vs Codex

August 14, 2026 · dshbase

Calling DeepSeek Harness "a DeepSeek version of Codex" is the first thing people say — and the thing the project most pushes back against. The pushback isn't marketing. The two tools disagree on a fundamental question: should an agent be configured by scenario ("what kind of task am I doing?") or by capability ("what plugins does this agent run?")? We've spent the last week running DSH 0.1.0-rc.6 and installing community plugins by hand, and the difference shows up in concrete places, not just in philosophy.

Agent presets, not scenarios

Codex-class products separate modes by scenario (daily/office, office/code). You pick a lane and the product fills in the rest. DSH instead uses Agent presets: the exact set of plugins an agent runs with — tools, prompts, and capabilities. You copy one, tweak it, or build a new one, including non-coding presets like a writing workspace.

That's a real ergonomic difference. In Codex you adapt to the modes you're given; in DSH the preset is the mode, and it's a file you can version and share. When a community preset like the Data Agent preset (dsh-data-agent) shows up in the plugin directory, it isn't a feature request to the vendor — it's just someone publishing a preset you can install in one command.

Rebuildable sessions

Codex sessions are opaque. DSH sessions are append-only event logs — system prompts, reasoning, tool calls, permission changes all become events, and the next turn's history is re-derived from that log rather than held in a black-box state. When an agent fails or loops, you trace the exact step it went wrong.

We leaned on this more than expected during testing: a plugin that crashed on load produced an error we could pin to a single event, not a vague "task failed". For a deeper look at what's actually in the log, see our session-log breakdown. This is an observability win Codex simply doesn't expose.

The plugin model

Where Codex lets users customize Skills and MCP but keeps the rest baked in, DSH makes everything a plugin — the UI, tools, workflow, even the agent loop. You assemble an agent, not rent one.

The claim is easy to make; the question is whether the ecosystem is real. We spent time verifying it. Our plugin directory catalogs 1,100+ community plugins, including the 101 we tested in depth on dsh 0.1.0-rc.6. The results aren't all clean:

• 11 npm packages install and work out of the box — one dsh plugin add <name> and you're done.
• 4 more need a Web/TUI context — they install fine but only do something inside the web UI or a terminal profile.
• 3 failed to install outright.
• 81 are GitHub-source repos you install with dsh plugin add github:owner/repo — the majority of the ecosystem, not yet on npm.

That last number matters. "Everything is a plugin" only works if plugins are easy to ship, and for 81 of 101 of them the distribution channel is a GitHub URL, not a registry. It's the early-days shape of an ecosystem that's moving fast — every card in the directory shows the exact install command and verified status.

Model flexibility

DSH supports directory and custom providers — you add a base URL, protocol, and model list, and you could run GLM inside it. Codex is tied to OpenAI models. If your cost or compliance constraints push you off OpenAI, DSH follows you; Codex doesn't.

DSH vs Codex at a glance

The reality check: installing 101 plugins

"Everything is a plugin" sounds clean until you actually try to install a few dozen of them. Here's what we hit that the marketing doesn't mention — all on dsh 0.1.0-rc.6:

• ERR_PNPM_FETCH_404 — the npm mirror lags behind the official registry, so a just-published package 404s. Fix: pin --registry=https://registry.npmjs.org.
• ERR_REQUIRE_ESM — a plugin compiled to CommonJS but depending on an ESM-only package. The author has to rebuild it as ESM.
• Installed but never activates — the package has no dsh.bundle manifest, so dsh plugin add drops it in as a plain dependency and it's never loaded.
• cannot get property "systemPrompt" without inject — a plugin bug where the code calls ctx.systemPrompt without declaring inject: ["systemPrompt"].
• allowBuilds prompt — GitHub-hosted plugins ship a prepare build script that pnpm blocks by default.

The full list with one-line fixes is in our troubleshooting guide. The honest framing: DSH's plugin model is more open than Codex's, but that openness means you are the quality gate. With Codex the vendor vets what reaches you; with DSH, you'll read a few error messages before you learn what a well-built plugin looks like.

FAQ

Is DeepSeek Harness just an open-source clone of Codex?

No. The surface similarities — an agent that reads files and runs commands — hide a different configuration model (presets vs scenarios), a different extension model (everything-as-plugin vs Skills+MCP), and rebuildable sessions Codex doesn't expose.

Which is easier to set up?

Codex. You pick a scenario and start. DSH asks more of you up front — pick or build a preset, add a provider — but returns the control afterward.

Can DSH plugins match Codex's Skills and MCP?

They're different mechanisms. A DSH plugin is a TypeScript module with an apply function, shareable as npm or a GitHub URL. It's simpler to write but lives inside the dsh process; MCP is more portable across clients.

How mature is the DSH plugin ecosystem really?

Early but real: the directory now catalogs 1,100+ community plugins — though in our first test pass, 81 of 101 were GitHub-source (not npm) and 3 failed to install. It's an ecosystem in week-one shape, not a polished marketplace.

Practically

• Codex-class: polished, scenario-driven, minimal configuration — the "rented" agent.
• DSH: assemble presets, rebuild sessions, audit every step, extend the agent itself — the "built" agent.

If you want a finished product, Codex wins on polish. If you want to see and change how the agent is put together — and you're willing to read a few ERR_REQUIRE_ESM errors along the way — DSH is the more interesting bet. The project's insistence that it "doesn't want to be the next Codex" is exactly right: it wants to be the thing Codex can't be — inspectable all the way down.

All articles →