[Bug] Agent teams: separate-process teammates honour a plugin agent's restricted `tools:`, so they can never SendMessage a report back

Status Open
Reported on v2.1.219
Maintainer reply None cached
Activity 1 comment · opened Jul 25, 2026

Summary

A teammate's only channel for returning a result is SendMessage. When a teammate's --agent-type resolves to a plugin agent whose frontmatter declares a restricted tools: list, that list is honoured — and because it contains neither SendMessage nor ToolSearch, the teammate completes its work and has no way to deliver it. It goes idle and the lead receives a contentless idle_notification. Nothing errors, so the failure is invisible from both sides.

Evidence — controlled comparison, same session and launch path

| --agent-type | tools declared | report delivered? |
|---|---|---|
| feature-dev:code-reviewer (×5) | no SendMessage / no ToolSearch | ❌ 0 / 5 |
| general-purpose (×3) | * | ✅ 3 / 3 |

Only the agent type differed. Asked to enumerate its own tools, a feature-dev:code-reviewer teammate replied:

I have access to these tools in this session: Read, WebFetch, WebSearch, TaskStop, TaskOutput, Glob, Grep. I don't have SendMessage or ToolSearch — I can't message teammates or search for additional tools.

Another wrote its finished report into its final assistant message with the note:

Note: The SendMessage tool isn't available in this session, so I'm delivering the report directly here.

The work existed in every case; only delivery was impossible. Recovering it required reading each agent's .jsonl transcript out of band. A stale inbox at ~/.claude/teams/<team>/inboxes/<agent>.json still holds 2 undelivered inbound messages for one such agent.

Why ToolSearch matters too

Per the analysis in #68408, SendMessage is a deferred tool: its schema must be loaded via ToolSearch("select:SendMessage") before it can be invoked. An agent whose tools: list omits both therefore has no recovery path — it cannot even discover the tool.

This appears to be backend-dependent

#78234 reports that for in-process teammates, plugin-scoped subagent definitions are silently dropped (the teammate spawns with tools: ["*"]). We observe the opposite for teammates spawned as separate claude processes: the plugin definition is applied, restricted tool list included. If both observations hold, teammate tool resolution differs by backend, and only the separate-process path is affected by this bug.

Also observed: the tool list has drifted

The plugin declares Glob, Grep, LS, Read, NotebookRead, WebFetch, TodoWrite, WebSearch, KillShell, BashOutput, but the teammate actually reports Read, WebFetch, WebSearch, TaskStop, TaskOutput, Glob, Grep — LS, NotebookRead and TodoWrite resolve to nothing, and KillShell/BashOutput surface as TaskStop/TaskOutput. Unrelated to the delivery bug, but it suggests plugin agent definitions aren't validated against the current tool registry.

Expected

Any one of:

  1. Always grant team-coordination tools (SendMessage, and ToolSearch while SendMessage remains deferred) to teammates regardless of the definition's tools: list. The agent-teams docs already imply coordination tools are always available to a teammate.
  2. Make SendMessage non-deferred so it needs no ToolSearch to invoke (also suggested in #68408).
  3. Fail loudly at spawn if a teammate's resolved toolset cannot reach SendMessage, instead of silently producing an agent that can never report.

Repro

  1. CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1, teammates spawned as separate claude processes into tmux panes.
  2. Spawn a teammate with --agent-type feature-dev:code-reviewer (any plugin agent with a restricted tools: list) and instruct it to SendMessage its result to the lead.
  3. It performs the work, then goes idle. The lead receives only a bare idle_notification with no content. The report is present in the agent's transcript.
  4. Repeat with --agent-type general-purpose → delivery succeeds.

Note on setup

Our teammates are launched into panes managed by a local IDE that provides a shim tmux on PATH and intercepts tmux commands, rather than genuine tmux. The shim only handles pane creation/teardown — --agent-type resolution and tool assignment happen inside the real spawned claude process (launched with --agent-id/--agent-name/--team-name/--agent-type/--settings). Flagging it for reproducibility, since it may or may not be relevant.

Environment

  • Claude Code 2.1.219
  • macOS
  • CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1
  • Plugin: feature-dev@claude-plugins-official, gitCommitSha 96276205880a60fd66bbae981f5ab568e70c4cbf

Related

  • #68408 — SendMessage advertised but unavailable / deferred-schema problem
  • #74113 — background agents go idle without delivering their final SendMessage report
  • #78234 — plugin-scoped subagent definitions silently ignored in agent teams (in-process path)
  • #80569 — teammates ignore effort frontmatter from subagent definitions

View original on GitHub ↗

This issue has 1 comment on GitHub. Read the full discussion on GitHub ↗