Agent Teams: teammate output never surfaces — silent completion, stale inspector, delayed mailbox

Status Fixed / completed
Reported on v2.1.220
Maintainer reply None cached
Activity 1 comment · opened Jul 30, 2026 · closed Jul 30, 2026

Agent Teams: teammate output never surfaces — silent completion, stale inspector, delayed mailbox

Flag: CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1
Version: 2.1.220 (macOS)

Summary

With agent teams enabled, Agent-spawned teammates almost always appear idle/silent to the team lead, even when they did real work and produced a full report. Three separate bugs compound into this:

1. No forced delivery channel — teammates print instead of send

Agent spawn is fire-and-forget: the tool result is just "Spawned successfully… will receive instructions via mailbox", no return value. The only way output reaches the lead is if the teammate calls SendMessage. Nothing enforces this — teammates frequently just print their final report as assistant text and stop, exactly like a normal subagent would. That text is never delivered anywhere.

Repro: spawned advocate-009-b (general-purpose) with a review task. It produced two reports as plain assistant text (5,761 and 5,116 chars, in its own session transcript) and made zero SendMessage calls. Lead received only:

{"type":"idle_notification","from":"advocate-009-b","idleReason":"available"}

No content, no way to know work was even done, short of grepping the raw .jsonl.

2. Team inspector shows only the spawn prompt, never live output

~/.claude/teams/session-*/config.json stores each member's spawn prompt once, statically, and never updates it. inboxes/<agent>.json is a drain queue — empties to [] once delivered into the lead's context. Neither file, nor anything else discoverable, points at the teammate's own session transcript (which does contain the real output, in a separate nested tmux server the lead process doesn't read). Net effect: any "inspect this teammate" UI/view shows nothing but the original task instructions, indefinitely, even while/after the teammate does substantial work.

3. Mailbox only flushes into the lead's context on its next turn

<teammate-message> events (idle notifications, summaries) are injected as synthetic turns only when the lead's own session advances. If the lead is idle at the prompt, delivery can be delayed for hours. Example from logs: teammate idle-notified at 17:45:50 on day N, delivered to lead at 08:22:29 the next day (~14.5h later).

4. (Related, lower severity) Orphaned teammates after team-ID churn

When the team session ID rotates mid-conversation, SendMessage to an existing, still-running teammate can fail with No agent named 'X' is reachable, while the process keeps running (and burning tokens) in its own detached tmux server with no way to reach it. Found 6 such orphaned claude-swarm-* tmux servers dating back several days.

Expected

  • Teammate completion should reliably surface its result to the lead without depending on the teammate remembering to call SendMessage.
  • An "inspect teammate" view/tool should show live output, not just the frozen spawn prompt.
  • Mailbox delivery shouldn't silently wait on the lead's next turn if the lead is otherwise idle.

Workaround in use

Explicitly instructing every spawned teammate: "call SendMessage with your FULL report before finishing; printed text is not delivered." This helps but doesn't fix root causes 2–4.

View original on GitHub ↗

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