[Bug] Duplicate tool names across scopes: Teams' send_message shadows tool-subagent-control's, breaking plain continuable subagents

[omnisurge]

Summary

Since 0.1.6 (Agent Teams), a plain continuable subagent can no longer be messaged after it stops. The send_message tool that reaches the model resolves only Agent Team members, so a plain subagent id is rejected.

Reproduction (0.1.6-alpha.2, web profile)

1. subagent with run_in_background: true → returns { kind: "continuable", subagentId: "<id>" }.
   The child itself reports: "will do no further work unless you send it more" — i.e. it is continuable.
2. send_message { target: "<id>", message: "..." }
3. → ToolCallError: active teammate "<id>" not found

Note the wording: teammate. The tool that answers is the Teams one.

Root cause

Two shipped packages register a tool with the same name, in different scopes and with different parameters:

package	registration	tool	parameters
@deepseek-ai/dsh-tool-subagent-control	ctx.tools.register (global)	send_message	{ agent_id, message }
@deepseek-ai/dsh-experimental-tool-agent-team	scoped.tools.register (team-member scope)	send_message	{ target, message }

When both are in scope, the Teams (scoped) registration wins, so the global continuable-child path becomes unreachable. interrupt_agent has the same collision (Teams { target } vs global { agent_id }).

This looks like a regression introduced by mounting Agent Teams: before 0.1.6 only the global tool existed, so plain subagents could be messaged.

Impact

Plain continuable subagents — the non-Teams delegation path — lose their only way to receive follow-up instructions. The failure is silent from the caller's perspective: the tool exists, it just cannot see the target.

Workaround we ship

We registered a differently-named tool, send_to_subagent { agent_id, message }, that calls ctx.subagents.sendMessage(sender, id, content, { signal }) directly, mirroring what tool-subagent-control does. Naming it differently is the only way we found to reach the global path.

Suggestion

Rename one of the two, or have scope resolution fall back to the global registration when the scoped one cannot resolve the target.

---

Related reports (added after posting)

• Bug: tool registration accepts control-character names, megabyte descriptions, and duplicate names — ambiguity reaches the wire instead of failing loud at load #4105 — tool registration accepts control-character names, megabyte descriptions, and duplicate names. Same root cause, and it explicitly notes: "No shipped producer emits such values today; exposure is the third-party plugin surface this repo explicitly invites." This report is that counter-example: two official packages do exactly this, and the consequence here is a user-visible regression rather than a hypothetical.
• [Lifecycle] Duplicate waiting subagent tool names can roll back late providers #1526 — Duplicate waiting subagent tool names can roll back late providers. Different mechanism (two instances of the same plugin, transaction rollback), but it documents that a reservation check exists: toolName "shared_subagent" is already reserved by another tool-subagent instance. That check does not cover two different packages registering the same name in different scopes.
• [Bug] Agent Team roster reads `model` from a stale creation-time snapshot (offline teammates get the Lead's model) #7054 — Agent Team roster reads model from a stale creation-time snapshot. Same area (Agent Teams), different defect.