Skip to main content
All posts
Comparison

DeepSeek Harness vs Codex CLI (vs Claude Code): 2026 Comparison

Codex CLI vs Claude Code vs DeepSeek Harness: comparing OpenAI's, Anthropic's, and dsh's terminal agents on MCP naming, hooks reuse, and subagent delegation.

DeepSeek Harness (dsh) and OpenAI's Codex CLI are both open-source, terminal-oriented coding agents — but dsh is built as a general-purpose plugin harness (everything, including model adapters and hooks, is a Cordis plugin), while Codex CLI is OpenAI's own agent tightly coupled to its models and ChatGPT-based authentication. Notably, dsh can delegate work to Codex as a subagent and reuse a Codex hooks.json directly, so the two aren't strictly either/or.

Where they're structurally alike

Both projects are open source, both ship as CLI-first tools you run from a terminal, and both have grown fast-moving plugin/extension ecosystems around them since launch. Both also load AGENTS.md files from the working directory as project-level instructions — this convention is shared across several coding agents, dsh included, and it's one of the easier things to carry over if you're evaluating a move between the two.

Where they diverge is in how deep the extension model goes. dsh's Cordis architecture means a hook, an MCP bridge, a model adapter, and a tool are the same underlying construct — plugins registered against a shared Context. Codex CLI's extension surface is comparatively narrower and more focused on MCP client support and its own hooks format, without dsh's "register anything as a plugin" microkernel design.

MCP tool naming: the same shape

If you've wired MCP servers into Codex CLI before, the mental model carries over almost exactly to dsh. dsh's docs explicitly call out that its MCP tool naming — mcp__<serverName>__<rawName> — uses the same server-qualified shape that both Claude Code and Codex use. The practical benefit: you don't have to relearn how to think about which tool belongs to which server.

dsh's scope is narrower than a full MCP client, though — it explicitly bridges only Tools, not Resources or Prompts (both documented as deferred, with no harness-side consumer implemented yet). If a Codex-connected MCP server you rely on leans on those, check for that gap before assuming a 1:1 swap.

A dsh MCP server entry, stdio transport:

- id: mcp-github
  name: '@deepseek-ai/dsh-mcp-client'
  config:
    serverName: github
    transport: stdio
    command: npx
    args: ['-y', '@modelcontextprotocol/server-github']
    env:
      GITHUB_TOKEN: !!js process.env.GITHUB_TOKEN

See How to Use MCP Servers with DeepSeek Harness for the streamable-http variant and reconnection behavior.

Hooks: dsh reuses Codex's hooks.json directly

dsh ships an official dsh-hooks-codex bridge package that translates an existing Codex hooks.json into dsh's own extension-point listeners — the same pattern dsh applies to Claude Code hooks via dsh-hooks-claude-code. If your team already has Codex hook scripts, you may not need to rewrite them from scratch just to try dsh. See Hooks and slash commands in DeepSeek Harness for how the events map.

Subagents: dsh can call Codex's own app-server

dsh's subagent system includes a dedicated dsh-subagent-codex provider that delegates work to Codex through its official app-server protocol — one of several subagent backends alongside dsh-subagent-claude-code, an Agent Client Protocol provider, and in-process options. Subagents can be one-shot or continuable, and one-shot delegation supports outputSchema, depthLimit, toolFilter, and persona, each of which a provider must explicitly declare support for. Practically, this means dsh can orchestrate a Codex-powered subagent as one leg of a larger agentic workflow rather than treating Codex purely as competition. Full provider table: DeepSeek Harness subagents.

ChatGPT/Codex OAuth: a community bridge, not a dsh built-in

One thing that stands out in the plugin ecosystem: a cluster of community plugins exist specifically to let you reuse your existing Codex CLI ChatGPT subscription login inside dsh, exposing it as a model route rather than requiring a separate DeepSeek-native API key. Examples indexed on FindHarness include dsh-codex-connect ("Connect ChatGPT OAuth and OpenAI Codex models to DeepSeek Harness") and dsh-codex ("Use your ChatGPT subscription in DeepSeek Harness through OpenAI's Codex sign-in flow"). This is community-built, not an officially documented dsh feature — but its existence confirms that Codex CLI's OAuth-based ChatGPT login flow is well-known enough in the ecosystem that multiple independent authors have bridged it.

Model providers and interface

DimensiondshCodex CLI
LicenseMIT, open sourceOpen source
Native modelDeepSeekOpenAI's Codex/GPT models
Provider flexibilityBuilt-in directory (Anthropic, OpenAI, Bedrock, Vertex, Azure, Codex-native auth) plus any OpenAI-compatible custom endpointPrimarily oriented around OpenAI's own models and authentication
Primary interfaceLocal Web UI plus a headless CLI modeTerminal-first CLI
Version statusDeveloper preview, no SemVer promise, GitHub Issues disabledActively developed open-source project

Which one fits your workflow?

  • You already use Codex CLI's ChatGPT OAuth login and want to keep it: a community bridge plugin lets you carry that credential into dsh, and dsh's dsh-subagent-codex provider means you can call Codex as a backend from inside a dsh-orchestrated workflow instead of picking one exclusively.
  • You want the broadest native multi-provider config out of the box: dsh's built-in provider directory (Anthropic, Bedrock, Vertex, Azure, Codex-native, any OpenAI-compatible endpoint) is more expansive than a tool built primarily around one vendor's models.
  • You want a single, tightly integrated tool with fewer moving parts: Codex CLI's narrower extension surface is more predictable if you don't need a general-purpose plugin microkernel.
  • You're building an agent-of-agents system: dsh's subagent provider registry — which can call Codex, Claude Code, or in-process agents interchangeably — is the more natural fit.

Codex CLI vs Claude Code vs DeepSeek Harness at a glance

Codex CLI and Claude Code are both terminal-first, single-vendor coding agents — one tightly coupled to OpenAI's models and ChatGPT auth, the other to Anthropic's Claude models — and on paper that makes them direct competitors. dsh changes that framing in a concrete way: it can run either one as a subagent (dsh-subagent-codex, dsh-subagent-claude-code), it ships official hooks bridges for both (dsh-hooks-codex, dsh-hooks-claude-code) that translate an existing hooks.json from either tool, and its MCP tool naming (mcp__<serverName>__<rawName>) is deliberately documented as the same server-qualified shape both Codex CLI and Claude Code use. So a Codex CLI vs Claude Code comparison done in isolation misses the more useful question for dsh users: which one (or both) do you want dsh to orchestrate, rather than replace.

DimensionCodex CLIClaude CodeDeepSeek Harness (dsh)
Vendor / modelsOpenAI, OpenAI's Codex/GPT modelsAnthropic, primarily Claude modelsDeepSeek native + built-in multi-provider directory
dsh can call it as a subagentYes — dsh-subagent-codexYes — dsh-subagent-claude-code— (dsh is the orchestrator)
Hooks bridge into dshYes — dsh-hooks-codex reuses hooks.jsonYes — dsh-hooks-claude-code reuses hooks.jsonNative Cordis hook listeners
MCP tool namingmcp__<serverName>__<rawName>mcp__<serverName>__<rawName>Same shape — mcp__<serverName>__<rawName>

FAQ

Is dsh's MCP support compatible with the MCP servers I already use with Codex CLI?

If the server only exposes Tools, the naming convention matches and it should work the same way. dsh doesn't currently bridge MCP Resources or Prompts, so verify that gap if your Codex setup depends on those.

Can I reuse my Codex hooks.json in dsh without rewriting it?

Yes, that's the specific purpose of the dsh-hooks-codex bridge package — it translates the file into dsh's extension-point listeners. Test your specific hooks after installing, since we haven't independently verified every hook type.

Does dsh let me use my existing ChatGPT/Codex subscription instead of a DeepSeek API key?

Not as a built-in dsh feature, but several community plugins — like dsh-codex-connect — bridge Codex's ChatGPT OAuth login into a dsh model route. Review the plugin's source before installing, same as any third-party plugin.

Can dsh call Codex CLI as part of a larger workflow instead of replacing it?

Yes — the dsh-subagent-codex provider delegates a task to Codex through its official app-server protocol, so dsh can act as an orchestrator that includes Codex as one of its execution backends.

Which one is more open?

Both are open source. The bigger architectural difference is that dsh treats every extension type — including hooks and MCP bridges — as the same kind of Cordis plugin, whereas Codex CLI keeps a narrower, more focused extension surface.

Next steps