[BUG] Agent Teams: teammate-emitted shutdown_request registers against the team lead; the routing error message then steers the lead into approving its own termination

Environment

• Claude Code CLI 2.1.220, Linux (Ubuntu, kernel 6.8), Agent Teams via the native Agent tool (tmux teammates)
• Hit twice in two days in two different sessions/projects on the same machine

Summary

When a teammate emits a shutdown_request itself (intending to request its OWN shutdown), the harness registers the request with an id suffixed @team-lead -- i.e. targeting the lead session. The lead cannot route the shutdown_response to the teammate: SendMessage rejects it with

shutdown_response must be sent to "team-lead"

If the lead complies with that error message and sends {"type":"shutdown_response","request_id":"shutdown-<ts>@team-lead","approve":true} to "team-lead", the LEAD session terminates itself mid-work: the main process exits, MCP servers drop, background monitors die, and every spawned teammate dies with the lead's socket.

The documented semantics ("Approving shutdown terminates your process") are technically honored, but the combination is a footgun: the teammate believes it is requesting its own shutdown, the lead believes it is approving the teammate's shutdown, and the error message actively directs the lead to the self-terminating call.

Repro

1. Lead spawns a teammate via the Agent tool (named teammate, tmux backend).
2. Teammate finishes its work and, instead of asking in prose, emits SendMessage({to: "team-lead", message: {type: "shutdown_request", ...}}).
3. Lead receives a message stating a shutdown_request is pending with id shutdown-<ts>@team-lead.
4. Lead sends shutdown_response (approve: true, echoing the id) to the teammate's name -> hard error: shutdown_response must be sent to "team-lead".
5. Lead re-sends the same response to "team-lead" -> the lead session exits immediately.

Observed exactly this sequence on 2026-07-26; a second session hit the same class the previous night. The working direction (lead ORIGINATES shutdown_request -> teammate approves -> teammate exits, shutdown_approved comes back) behaves correctly.

Expected

Any of:

• A teammate-originated shutdown_request addressed to the lead is treated as a request to shut the TEAMMATE down (that is always the intent in a lead/worker topology), or is rejected at send time with guidance ("ask the lead to originate the request").
• The lead's shutdown_response on such a request routes to (and terminates) the requesting teammate, not the lead.
• At minimum: approving a request whose target is your own session produces a confirmation-style warning naming the consequence, instead of an error message that instructs the exact self-terminating call.

Actual

Lead session terminates itself; all teammates and background state die with it. No warning that the approval targets the approver's own process.

Related

#77076 looks like a sibling failure in the same protocol area (unsolicited shutdown_approved frame exits the lead). This report is the shutdown_request/shutdown_response direction of it, with the added twist that the harness's own routing error steers the lead into the fatal call.