Install DSH subagent providers: Codex, Claude Code, ACP

DeepSeek Harness does not enable every subagent backend by default: Codex and Claude Code are separate optional bundles. Install one with dsh plugin add, restart the profile, then enable the matching tool row in a copied preset. Skip any step and the result is not an error—it is an agent that cannot see the tool.

DeepSeek Harness: What Codex, Claude Code, and ACP are

All three sit at the subagent-provider layer, but their installation paths and prerequisites differ. Start with the roles:(source)

The point is that “subagent” is not one plugin; it is a replaceable backend layer. The provider you install determines where the subagent runs, which credentials it uses, and which limits apply.

DeepSeek Harness: Install commands and bundle behavior

Installation is two dsh plugin add commands; they update only the chosen profile. Examples:(source)

# Codex only
dsh plugin --profile web add @deepseek-ai/dsh-subagent-codex

# Claude Code only
dsh plugin --profile web add @deepseek-ai/dsh-subagent-claude-code

# Both
dsh plugin --profile web add \
  @deepseek-ai/dsh-subagent-codex \
  @deepseek-ai/dsh-subagent-claude-code

Check three things:

1. --profile comes first — dsh plugin reads its own flags before forwarding the rest to pnpm. Expected: the package lands in $DSH_HOME/profiles/web.
2. pnpm is on PATH — the command is a thin wrapper around pnpm. Expected: pnpm -v prints a version before you install.
3. The bundle list updates — a package with a dsh.bundle declaration joins the configuration layer stack. Expected: no “no bundle declaration” warning for the package you intended to install.

If you are experimenting, install one provider first. Installing both works, but it makes “which backend actually ran?” harder to answer.

DeepSeek Harness: Why the tool is still missing

The bundle registers the provider; the preset grants the tool. Those are separate steps. The official behavior is explicit: on the next startup each installed bundle registers its dormant host provider, and you must still enable the corresponding tool row in a copied preset before a new agent sees it. (source)

Check in this order:

1. Restart the profile — stop and start dsh web. Expected: the startup log loads the new bundle.
2. Open the preset you actually use — confirm it is a copied, editable preset, not a read-only built-in. Expected: subagent tool rows are visible.
3. Enable only the provider you installed — do not turn on a backend that is not present. Expected: new agents show the matching tool.
4. Start a new session — old sessions may keep a tool snapshot from creation time. Expected: asking the model to list tools shows Codex or Claude Code.

If step 3 has no row, verify the package and profile name. If step 4 still fails, check whether you are reusing an old session or an old preset.

DeepSeek Harness: What changes in the manifest

Every successful add, remove, or update updates dsh.profile.bundles from the current install state. The rules:(source)

• Dependency with a dsh.bundle declaration — added to the configuration layer stack. Expected: the bundle appears in the profile manifest.
• Dependency without a bundle declaration — kept as a normal dependency with a one-time warning. Expected: it does not change the layer stack.
• Removed dependency — removed from the layer stack. Expected: its patch is no longer applied after restart.
• Running profile — keeps the bundle set from its startup. Expected: no new provider until you restart.

The manifest will show a bundle entry such as @deepseek-ai/dsh-subagent-codex. Check the bundle list, then the preset row; both must be right.

DeepSeek Harness: Three integration paths

Official bundles are for ready-made backends, a custom provider is for an internal agent platform, and in-process spawning is for task splitting without external dependencies. Compare:(source)

1. Official Codex / Claude Code bundles — fastest install; best when the team already has the CLI or account. Cost: you still maintain the backend executable and authentication.
2. Custom subagent provider — implement SubagentProvider and register it under ctx.subagents. Cost: you own startup, continuation, and failure handling.
3. In-process spawn / fork — no external product; good for pure task splitting. Cost: weaker isolation and capability limits compared with an external backend.

The paths can coexist. A common setup is “in-process by default, heavy work to Codex or Claude Code”.

DeepSeek Harness: Restart, verify, and uninstall

Bundle membership changes always require a restart; removal follows the same order—remove, restart, clean the preset row. Removal commands:(source)

dsh plugin --profile web remove @deepseek-ai/dsh-subagent-codex
dsh plugin --profile web remove @deepseek-ai/dsh-subagent-claude-code

1. Remove one package at a time — confirm the other provider still works. Expected: the matching bundle disappears from the manifest.
2. Restart the profile — make the running process drop the old bundle set. Expected: the removed provider no longer loads.
3. Remove the preset tool row — do not leave an entry pointing at a missing backend. Expected: new agents no longer show the tool.
4. Check for residue — inspect dsh plugin --profile web list and the profile directory. Expected: no stale dependency or orphan patch row.

To find alternative subagent plugins, browse categories in DSH Plugin Hub under Settings → Plugin Market. The official Codex and Claude Code bundles are still best installed with dsh plugin add so their versions stay aligned with the current DSH.

DeepSeek Harness FAQ

If I install both providers, will the agent choose automatically? No. The preset’s enabled tools and the delegation prompt decide which backend runs. If both are enabled, state the priority in the delegation instruction.

Can I install a provider for one project only? Yes. Use a separate profile, for example dsh plugin --profile myproj add ..., then start with dsh --profile myproj. Plugins and presets are profile-scoped.

Do old sessions still work after uninstalling a provider? The logs remain, but tool calls that point at the removed provider fail. Keep the provider or switch to another backend in a new session.

The short version: installing a subagent provider is not “install and use”; it is bundle → restart → preset tool row → new-session verification. Skip one step and the tool stays invisible.