[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, GrepLS, 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 ↗