[BUG] Agent Teams mailbox: 5-62 min turn-boundary delays, lost final reports (idle_notification arrives instead), /clear queue leak, shutdown handshake never completes

Environment

• Claude Code 2.1.206, macOS (darwin 25.6.0)
• CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1
• Orchestrator session + teammates spawned via the Agent tool (tmux backend)

Summary

Four related delivery defects in the Agent Teams mailbox, all observed in one day across two sessions (a 5h orchestrator run and the diagnostic session that analyzed it). Together they force both sides of a team to act on stale state; in our case the orchestrator only avoided corruption by re-verifying git log/status before acting on any message.

1. Messages are delivered only at the receiver's turn end (measured 5-62 min delays)

When the receiving session is mid-turn (long builds, verification), incoming teammate messages queue until the turn ends. Measured deliveries (sent timestamp inside the idle_notification payload vs. wall-clock delivery into the transcript): 5, 6, 19, 21, 25 and 62 minutes. Both directions are affected; the teammate side repeatedly asked about things the lead had already resolved because the lead's answers were still queued.

2. Substantive final messages lost entirely while idle_notifications arrive

Reproduced 4 times in a single session: a spawned agent finishes, calls SendMessage with its full final report, and the recipient (team lead) receives only the automatic idle_notification. The report never arrives, at any turn boundary. The content was recoverable only by reading the teammate's transcript .jsonl from disk. The teammate's transcript shows the SendMessage tool call succeeding.

3. Queue leaks across /clear

An idle_notification generated by a teammate of the previous session (before /clear) was delivered into the new session 62 minutes after it was generated, with no marker distinguishing it from current-session traffic.

4. shutdown_request handshake never completes

Lead sends shutdown_request (tool result confirms delivery and returns a request id). Teammates process it but their shutdown_response never reaches the lead, and the teammates do not terminate: they go idle and emit more idle_notifications. Repeated with three teammates simultaneously; all three had to be killed via tmux kill-pane.

Expected

• Documented delivery semantics (ordering, latency bounds) for teammate messages, or turn-interrupting delivery for substantive messages.
• No message loss: an idle_notification should never overtake and replace the substantive message that preceded it.
• Mailbox flush or epoch-tagging on /clear.
• shutdown_request/shutdown_response handshake completing without manual pane kills.

Related

#47930 (idle-notification noise), #46691 (lead stall after teammates report back), #28627 (idle notifications rendered as Human turns) look adjacent but none covers message loss, turn-boundary latency, the /clear leak, or the shutdown handshake.