DeepSeek Harness: duplicate list_agents, stuck subagents

DeepSeek Harness (DSH)'s Agent Teams is a "change the addressing" experimental capability: it replaces the native subagent control-class tools with versions that address by roster name (tool-subagent-control, tool-subagent-list-agents, tool-subagent, and tool-subagent-fork are all replaced). So once Team is mounted, the anonymous subagent you dispatch directly with subagent in the session falls into a blind spot — it is not in the roster, interrupt_agent and send_message report active teammate "<id>" not found, list_agents returns only the lead, and a runaway subagent cannot be reclaimed. More troublesome is the second form: the Team patch acts on the root layer by id only, while each preset declares a copy with the same id inside a nested plugins: section that the patch cannot reach, so two list_agents coexist in the same scope and wait_agent forever returns noProgress: no-active-peer (#9764, #9523).

DSH plugin: the parent agent cannot stop the subagents it dispatched

The one-line conclusion: the tool is not broken, the "addressing system changed" — the control-class tools are provided by the Team build, the Team build addresses by roster name, and the anonymous subagent you produced by direct delegation was never in the roster, so its session id finds nothing. The symptom trio (#9764):

1. interrupt_agent reports active teammate "<id>" not found;
2. send_message reports the same line;
3. list_agents returns only the lead, without the subagent you just dispatched.

DSH plugin criterion: compare parameter names, no source reading needed

The easiest way to prove it to yourself is to look at the parameter-name convention. The two implementations use different target-addressing parameters — one uses agent_id, the other uses target (the roster name). Per community source review, this difference comes from the patch's four-line change and the Team build's re-convention of parameter names, and the error originates in the team module's roster.ts (#9764).

1. Do one comparison call: call interrupt_agent with the documented parameter name; if it is judged "missing required parameter" or "target does not exist", try again with the other parameter name.
2. Look at the target shape it returns: the Team build expects a name in the roster, not a session/agent id; if all you have is an id, you can basically conclude the Team build is mounted (#9764).
3. Confirm whether the subagent tool description is misleading: the thread notes that under the Team profile the subagent tool's description does not match its actual behavior — it still claims the returned id can be used with send_message, but in practice it does not hold (#9764).

DSH plugin three ways to handle it

1. Switch uniformly to the Team way of doing things (recommended, smallest change):

spawn_teammate  →  create a member into the roster
list_agents     →  get the name in the roster
interrupt_agent(target: <roster name>)  →  terminate the specified member

The key point is to address by roster name throughout, never mixing in ids (#9764).

2. Do not mount agent-team-profile: if the team way of working is not a real need for you, dropping it immediately restores the native delegation addressing (#9764).
3. Add a prompt constraint for delegation: in the dispatch prompt, require the subagent to "write its conclusion to disk before finishing", so that even if it is briefly unreclaimable its results are not lost — this also works for "subagent terminates abnormally and its output cannot be read back" (#9764). A subagent that "cannot be reclaimed or whose output cannot be read back" has its own family of diagnostics and lifecycle troubleshooting — see DeepSeek Harness subagents: product-error, stale entries.

DSH plugin list_agents name conflict: the root-layer patch cannot reach the preset layer

The one-line conclusion: the Team patch acts on the root layer by id only, while each preset declares a copy with the same id inside a nested plugins: section; the patch structurally cannot reach the preset layer, so the root copy is replaced while the preset copy remains, two list_agents appear in the same scope, and wait_agent has no way to tell "who is running". The symptom is wait_agent forever returning noProgress: no-active-peer (59 idle spins measured in a single session in the thread) (#9523).

DSH plugin mechanism: addressing recurses only within its own group

Per mutual confirmation between the reporter and the community: the patch's id-addressing implementation recurses only over sibling groups, while the preset declares its config one level deeper in plugins:, so the root-layer replacement hits another line; more insidiously — this miss is silent, with no "patch did not match" error (#9523).

DSH plugin four steps to confirm and handle

1. Confirm the criterion: wait_agent repeatedly returns noProgress: no-active-peer, while list_agents looks like "there are two of them" (duplicate names or inconsistent behavior) (#9523).
2. Handling one (temporary, runtime): install the community plugin @argszero/cordis-plugin-team-delegation-guard to add a guard before delegation (#9523):

npm i @argszero/cordis-plugin-team-delegation-guard

3. Handling two (structural, choose one of three): the thread gives three patch-branch directions — A add a teams condition per line (replace only when needed); B rename to decouple (let the two tools use different names, sidestepping the name clash entirely); C change only the wording (write the tool description accurately, so at least it is not misleading) (#9523).
4. Verify: after handling, confirm there is only one list_agents in the same scope, and that wait_agent can observe a peer (no longer forever no-active-peer) (#9523).

DSH plugin troubleshooting notes

This family has only one main troubleshooting thread: first confirm "which set of tools is currently in effect", then decide how to address — far faster than reading the source. Seven points:

1. The parameter name is the identity marker: the difference between agent_id and target immediately tells you which set is mounted (#9764).
2. list_agents returning only the lead is a strong signal: it means the anonymous subagent is not in the roster (#9764).
3. Do not trust the tool description's self-claim: under the Team profile, subagent's description does not match its behavior (#9764).
4. Removing the Team profile is the fastest certain solution, if the team way of working is not a real need (#9764).
5. A patch miss is silent: symptoms like no-active-peer are often "the patch hit another line", not a logic bug (#9523).
6. Same-named tools shadow each other's behavior: when two implementations coexist, parameter conventions and return structures may both differ, so troubleshooting must defer to "the one actually in effect" (#9523).
7. State the fix status honestly: the addressing replacement and the patch's inability to reach the preset layer are both unfixed in the version discussed (0.2.0-rc.2); the community plugin is a runtime guard that will not change your profile structure, and no official fix has been announced.

Capabilities like Agent Teams, which "swap tools and swap addressing", most need a clear view of "which plugins and config lines are actually mounted". Instead of typing commands everywhere to infer it, use a visual marketplace like DSH Plugin Hub: the installed list carries source markers and install/uninstall history and system logs sit in one panel, so you first pin down "what exactly is mounted in this environment".

Source: Discussion #9764, Discussion #9523.