DeepSeek-Harness Subagents: Delegate to Claude Code, Codex, and ACP

DeepSeek-Harness (dsh) delegates work to subagents through ctx.subagents, a named provider registry that can host multiple implementations at once — including two that hand the task off to entirely different agent products: Claude Code and Codex. That's the detail most comparison posts miss: dsh and Claude Code aren't purely competitors here, dsh can orchestrate Claude Code as one of its own execution backends.

What makes a dsh subagent different from a bash executor

Most capability seams in dsh have a single active implementation at a time — a ShellExecutor service typically has one provider backing it. Subagents are different: ctx.subagents is explicitly a registry, meaning several providers can be registered simultaneously, and the caller picks which one to delegate to per task. A subagent doesn't inherit the parent's agent-scope (the mechanism that isolates which tools/prompts/variables an agent can see) — scope isolation and delegation lineage are two separate systems. Lineage — which session spawned which — is tracked independently via parentSession and delegationDepth fields, not through the scope structure.

The five official providers

Provider package	What it does
`dsh-subagent-spawn-in-process` / `dsh-subagent-fork-in-process`	Runs the subagent inside the same dsh process, spinning up a child session without a separate process
`dsh-subagent-acp`	Spawns a separate process driven over the Agent Client Protocol (ACP)
`dsh-subagent-codex`	Delegates to Codex, via Codex's official app-server protocol
`dsh-subagent-claude-code`	Delegates to Claude Code, via Claude Code's official Agent SDK
`dsh-subagent-dsh-sdk`	Drives another dsh runtime as a subprocess, over the SDK's stdio JSON-RPC protocol

Three of these stay entirely within the dsh world (in-process, ACP, dsh-sdk); two hand execution to a different agent product outright. Which provider is available depends on which subagent plugin is installed in your profile — none of them are guaranteed present by default outside the base bundle's own delegation needs.

One-shot vs continuable

Subagent invocations come in two modes:

One-shot — the subagent runs to completion on a single delegated task and returns a result. This mode supports four optional capabilities, each of which a provider must explicitly declare support for:
- outputSchema — structured output instead of free text
- depthLimit — a cap on how many levels of further delegation the subagent itself is allowed to perform
- toolFilter — restrict which tools the subagent can see/use
- persona — a system-prompt-level identity override for the delegated task
Continuable — the subagent's session stays alive and can receive follow-up delegations without re-establishing context from scratch.

A provider that doesn't declare support for one of the four one-shot capabilities will reject a request that asks for it outright — dsh doesn't silently degrade or ignore an unsupported capability request, which is worth knowing if you're building automation that assumes outputSchema is universally available.

Why "dsh can run Claude Code as a subagent" matters

This is the fact that complicates the usual "dsh vs Claude Code" framing. Because dsh-subagent-claude-code exists and is an official, maintained provider, a dsh session can delegate a subtask to a real Claude Code Agent SDK instance and get the result back into its own session — the two tools aren't mutually exclusive the way, say, two competing IDEs would be. The same is true for Codex via dsh-subagent-codex. If you're evaluating dsh specifically because you want to keep using Claude Code or Codex for certain tasks while standardizing your top-level orchestration on dsh, this delegation path is the mechanism that makes that workable — see DeepSeek-Harness vs Claude Code and DeepSeek-Harness vs OpenAI Codex CLI for the fuller comparisons.

Delegating from your own plugin code

Since ctx.subagents is an injectable service like any other capability seam, calling it from your own plugin doesn't require adopting a whole workflow framework — a tool's execute function can hand its work off to a named provider instead of doing the work inline, the same general shape as any other inject: ['subagents'] plugin covered in our custom tool tutorial. (The exact call signature for invoking a specific provider isn't reproduced here since it isn't pinned down in the sourced documentation used for this article — check docs/subsystems/subagent.md in the dsh repository for the current exact API before writing against it.) What is documented, and worth designing around regardless of the exact call shape: pass a conservative depthLimit for any delegated task, so the subagent you're calling can't itself delegate arbitrarily deep, and pass toolFilter whenever you don't want the subagent to inherit every tool the provider would otherwise expose.

Why depth and tool limits matter for security

Delegation is a place where a security review deserves real attention, not an afterthought. A subagent that isn't toolFilter-restricted inherits access to whatever tools the provider exposes by default — for an out-of-process provider like dsh-subagent-claude-code, that can mean a separate agent product with its own tool set operating against the same workspace. Combine depthLimit and toolFilter deliberately for any delegation path that touches untrusted input (for example, summarizing content fetched from the web before deciding what to delegate further), the same way you'd think about permission presets for the top-level session — see our permissions and sandbox guide for the underlying sandbox modes a delegated subagent still runs under. None of the four one-shot capabilities override the sandbox mode a provider runs its work in; they control what the subagent can attempt, not what it's permitted to actually execute once it tries.

Subagents vs the plugin-based orchestration ecosystem

The ctx.subagents mechanism is the primitive; plugins in the Workflow & Automation category build higher-level orchestration on top of it. Two examples worth knowing:

dsh-agent-teams implements multi-agent "teams" coordination on top of dsh's delegation primitives.
dsh_workflow is a broader, savable/governable multi-agent orchestration workflow in the style of UltraCode, also built on the underlying subagent and workflow engines.

Neither of these plugins is required to use subagents at all — you can call ctx.subagents directly from your own plugin code for a single delegated task, without adopting a team/board abstraction. Reach for one of these plugins when you need persistent multi-agent coordination state across many turns, not just a one-off delegation.

FAQ

Can a dsh session delegate to Claude Code?

Yes — dsh-subagent-claude-code is an official provider that delegates to Claude Code via its Agent SDK. This is a native dsh capability, not a community workaround.

What's the difference between a subagent and a hook?

A hook intercepts a lifecycle extension point (see our hooks and commands guide); a subagent is a delegated execution of a task to a separate agent instance, in-process or out-of-process. They're unrelated mechanisms.

Does a subagent inherit the parent session's tool permissions?

Not automatically through scope — subagents don't inherit the parent's agent-scope. Delegation lineage (parentSession, delegationDepth) is tracked separately, and capabilities like toolFilter exist precisely to control what a delegated subagent can access.

For the full picture of how dsh's delegation model compares to Claude Code's and Codex's own subagent/task tooling, read DeepSeek-Harness vs Claude Code and DeepSeek-Harness vs OpenAI Codex CLI. For multi-agent orchestration plugins built on top of this primitive, browse best DeepSeek-Harness workflow plugins and the Workflow & Automation category. For the underlying terms (agent-scope, turn/step/round), see the glossary.