Named Agent dispatches silently discard the subagent's final text, and `run_in_background` is ignored on that path (v2.1.220)

Summary

When the Agent tool is called with a name parameter under CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1, the dispatch is routed to a teammate/mailbox path. On that path the subagent's final assistant text is never delivered to the parent. The agent completes normally, its full report is written to its own transcript, and the parent receives an availability notification with no content.

There is no error, no timeout, and no indication that anything was lost. The observable symptom is an agent that appears to "go idle without reporting", which is easy to misread as a hang, a timeout, or a model regression.

Measured on one machine's corpus of ~3,200 subagent transcripts: 52 of 287 mailbox-era named dispatches (18%, about 1 in 5.5) lost their report, totalling 198 assistant text blocks and roughly 1,050,000 characters. 0 of 2,839 unnamed dispatches were affected.

(Those counts are a snapshot, and consecutive runs of the same detector over the same corpus can differ by one or two: an agent still mid-flight has not yet either delivered or stranded, so its classification is not final until it stops. The ratio and the direction are stable; the absolute count is only meaningful once the sessions are idle.)

In the same corpus, zero timeout records exist, every non-delivering agent's complete report is present in its own transcript, and 47 of the 52 ended in a normal end_turn: they finished cleanly and had nowhere to put the result.

Environment

• Claude Code 2.1.220 (macOS, arm64)
• CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1

Reproduction

Two dispatches, identical except for the name parameter:

Arm A (named):

Agent(subagent_type: "<any>", name: "probe-named", run_in_background: true,
      prompt: "Run `echo probe`. Then end your turn with exactly:
               MARKER-ALPHA. Do NOT call SendMessage.")

Arm B (unnamed, control): identical prompt and marker (MARKER-BRAVO), no name parameter.

Observed: MARKER-BRAVO reaches the parent in about 5 seconds. MARKER-ALPHA never arrives. Arm A's agent demonstrably ran its command and ended its turn normally, and the marker is present in its own transcript.

Expected: both markers reach the parent, or the parent is told that arm A's output was not delivered.

Mechanism

Two paths differ in the tool result they return:

• named: Spawned successfully ... The agent is now running and will receive instructions via mailbox.
• unnamed: Async agent launched successfully ... You will be notified automatically when it completes.

On the teammate path, the lead is notified by a per-teammate Stop hook whose payload carries an idleReason and a summary. The summary is produced by a function that walks the transcript backwards matching only SendMessage tool_use blocks; it never reads assistant text blocks. With no SendMessage call there is no summary, and the lead renders a bare "finished" state with no content.

This interacts badly with subagent system prompts that instruct the agent to return its report as its final message: an agent following that instruction produces a complete report that is structurally unreachable.

Second symptom: run_in_background is dropped on the named path

Of 32 named dispatches measured, all 32 returned the same 267-315 byte mailbox stub regardless of whether run_in_background was absent (19), false (9) or true (4). Unnamed dispatches honour the parameter normally. The team-spawn branch does not appear to forward the parameter at all.

Consequence: passing run_in_background: false on a named dispatch does not give you a foreground agent, and does not protect the result.

Regression boundary

Under an earlier CLI (2.1.170) with the same teams flag set, named foreground dispatches returned their report normally in the tool result; named background dispatches already returned a launch stub. What appears to have changed is that named foreground dispatches now also take the team-spawn route, so foreground effectively ceases to exist once name is present.

Impact

• Silent data loss. The work is done, billed, and discarded.
• No signal distinguishes it from a hang, so it is typically misattributed - in our case to a model upgrade that happened 97 seconds after the CLI upgrade.
• Recovery is possible but requires reading subagent transcripts directly, which most users will not think to do.

Workaround

Omit the name parameter when the dispatch's result is needed. This is consistent with the CLI's own guidance in its nested-teammate guard: "To spawn a subagent instead, omit the name parameter." If a name is required, instruct the agent explicitly to deliver via SendMessage(to: "main").

Suggested fixes, in preference order

1. Fall back to the final assistant text when a teammate ends its turn without a SendMessage, so the report is delivered rather than dropped.
2. Failing that, surface it: tell the lead that the teammate finished with undelivered output.
3. Honour run_in_background on the named path, or reject the combination explicitly rather than ignoring it.
4. Document that a named dispatch changes the result-delivery contract. It is currently documented nowhere.

Related

Issues #61547 and #48160 describe adjacent symptoms. Both are closed with no maintainer response.

• #48160 ("Spawned subagents cannot originate SendMessage despite CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1 and explicit name=") appears to be the same defect from the other side, and the two together are stronger than either alone: if a teammate cannot reliably originate SendMessage, and SendMessage is the only channel the completion summary is built from, then the report is structurally unreachable rather than merely undelivered. Fixing delivery without fixing that leaves no working path at all.
• #61547 ("Agent tool: spawned sub-agents go idle immediately without executing prompt") is a different failure mode: a subagent stalling before its first tool call. The behaviour reported here involves agents that run to completion successfully. It is listed because the two are easy to conflate from the parent's point of view, where both look like "went idle, produced nothing".