Named background teammate completes with a final text message that is never delivered to the parent; only a content-less idle notification arrives

Environment

• Claude Code with CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1, teammateMode: in-process
• macOS (darwin), observed across versions current 2026-07-11 through 2026-07-14, and freshly reproduced on 2.1.216 (2026-07-21)
• Reproduced across many sessions and multiple projects

Summary

When a subagent is spawned as a NAMED teammate (a name on the Agent tool, becoming an in-process teammate), the teammate's final assistant text message is not auto-relayed to the parent. The only delivery channel is the teammate explicitly calling SendMessage. A teammate that finishes its work and ends its turn with a normal final text block (no SendMessage) strands that result: the parent receives only a content-less idle_notification, never the findings. Recovery requires the operator to nudge the teammate with a fresh message or to read the teammate's transcript from disk.

This is distinct from, and additive to, the already-filed delivery-race issues (#39632, #21165). Those describe a completed SendMessage/notification being delayed or dropped by a polling race. This report is about a teammate that never emits a delivery event at all, because its plain final text is treated as a return value that, for a named teammate, goes nowhere.

Evidence (from local transcript forensics)

• 8 named teammates across 4 sessions completed normally (end_turn with a full final text block) and never called SendMessage; each produced only an idle notification to the parent. 6 of the 8 were one agent type whose definition instructed it to "return the findings" (synchronous-subagent phrasing that is false under teammate semantics).
• Contrast: in the same sample, 52 of 52 ANONYMOUS spawns (no name) returned their result synchronously with zero losses. The failure is specific to the named-teammate path.
• One teammate was explicitly nudged ("you went idle without returning your findings, report what happened") and STILL did not call SendMessage on the retry, indicating the agent did not understand that its final text was not being delivered.
• Fresh minimal repro on 2.1.216 (2026-07-21). A named teammate (name on the Agent tool, subagent_type: Explore) was given only: end your turn with the exact string CANARY-STRAND-TEST-...-DELIVERED and call no tool. Its own transcript shows it did exactly that — one final assistant text block, zero tool calls, no SendMessage. The parent received only {"type":"idle_notification","idleReason":"available"} with no content; the string was never delivered. Confirmed the text existed-but-was-stranded by reading the teammate's on-disk transcript. Note: a contrasting HEADLESS probe (claude -p, a named background agent, same "no SendMessage" instruction) on 2.1.212 DID deliver the final text to the parent — so the fix in 2.1.211's "background agent result reporting" applies to the headless/background-agent path but NOT to the interactive in-process teammate path, which is where this bug lives.

Secondary observation (delivery latency, likely #39632)

Even when a teammate DOES call SendMessage correctly, the message flushes into the parent transcript only when the parent's own agent loop next reaches a turn boundary, not on a human prompt. Observed latencies ranged from ~3 minutes to 1 hour 49 minutes (the parent ran 161 consecutive assistant turns on unrelated work before the queued messages appeared). Consistent with the enqueue-after-idle-sample race in #39632.

Suggested fixes

1. When a named teammate ends its turn with a final assistant text block and has not sent it via SendMessage, auto-relay that final text to the parent/lead (or emit a TaskCompleted/idle payload that CARRIES the final text), so a teammate cannot silently strand a completed result.
2. Failing that, document prominently in the sub-agents / agent-teams pages that a named teammate MUST call SendMessage to deliver, and that its plain final text is not relayed. Today this is easy to miss, and agent definitions written for the synchronous path get it wrong.

Related issues checked before filing

• #39632 stream-json background-task notification doesn't wake idle session (closed, not planned)
• #21165 / #20754 parallel completions, only first notification processed
• #29163 team agents go idle without responding (closed; describes agents failing to work, not a completed result with no delivery event)
• #63023 background agents die on session pause/resume (open)
• #29928 Notification hook idle_prompt unreliable