[BUG] A nested Agent's completion notification is delivered to the parent lane, not the sub-agent that launched it (2.1.220-2.1.229)

Summary

When a sub-agent launches a background Agent (run_in_background: true), the completion <task-notification> is frequently delivered to the parent lane instead of the sub-agent that launched it. The launching sub-agent is told nothing, so a sub-agent that ends its turn to wait for its own background agent never wakes — its only wake signal was the notification that went somewhere else.

Background Bash tasks launched from the same place never do this. That asymmetry looks like the actual bug: Bash task notifications carry lane affinity, nested-Agent completions do not.

Measured behaviour

I measured one full day of my own local traffic (30,174 captured API requests plus every sidechain transcript for that day). Launches were enumerated structurally from tool_use/tool_result block pairs in the sidechain transcripts, never by string-matching task ids, because the id also appears inside delivered notification text.

Nested Agents launched from inside a sub-agent, one day:

| outcome | count |
|---|---|
| delivered to the launching sub-agent (correct) | 7 |
| delivered to the parent lane only (the bug) | 7 |
| never delivered | 8 |
| total background nested Agents launched | 22 |

Background Bash launched from inside a sub-agent, same day: 146 launches, 118 delivered, 0 misrouted (28 undelivered — 13 with no enqueue record, 15 enqueued and never removed).

Mechanism, as far as the observations constrain it

A nested-Agent completion appears to be consumed by whichever lane of the session issues the first API request after completion, consume-once.

• All 7 misroutes: delivered 0-8s after completion, with 0 requests from the launching sub-agent inside that window (it was idle-waiting, or inside a long tool call).
• All 7 correct deliveries: pended 4-46s and rode the launcher's own next request, with 0 parent-lane requests inside that window.
• Decisive specimen: one sub-agent, two nested Agents, 7 minutes apart, opposite outcomes. The first completed while the launcher had been idle for ~4 minutes and went to the parent lane at +0s. The second completed while the launcher was actively working and reached the launcher 46s later.

So this is not "nested agents always misroute". It misroutes iff the launcher is not the next requester — which is exactly the case the feature exists for, a sub-agent parking itself to wait.

Bash notifications behave differently under the same pressure: 16 of the 118 pending Bash notifications survived 1-47 distinct parent-lane requests (one pended 74 minutes across 47 parent-lane requests) and still reached the launching sub-agent. None fell through to the parent. When the launching lane dies first, a pinned Bash notification strands in the queue rather than being delivered elsewhere (15 cases), which is again consistent with a pin that nested-Agent completions lack.

Reproduction

1. In a session, have the top-level agent launch a sub-agent (Agent/Task tool) that will run for several minutes.
2. Inside that sub-agent, launch a background Agent (run_in_background: true).
3. Let the sub-agent end its turn to wait for the notification, and have the top-level lane make any API request in the meantime (it usually will).
4. On completion, the <task-notification> block for the nested agent appears in the top-level lane's next request. The sub-agent's transcript (~/.claude/projects/<project>/<session-uuid>/subagents/agent-<taskid>.jsonl) contains no notification record for it, and the sub-agent never resumes.

Substituting a background Bash call for the background Agent in step 2 delivers correctly in the same conditions.

Corroborating detail on a single earlier instance: the agentId: <nested-task-id> anchor existed in exactly one file on the machine, the launching sub-agent's sidechain transcript, while the queue-operation enqueue record was written on the parent session (isSidechain: false) and the delivery landed in a parent-lane request body carrying agentId anchors only for the four agents the parent had launched itself.

Impact

• A sub-agent cannot reliably use a background Agent, because parking to wait is the failure case.
• The parent lane receives completions for tasks it has no anchor for. A well-behaved agent treats those as untrusted foreign content and ignores them, so the work result is silently dropped.

Environment

• Claude Code CLI, first measured on 2.1.220. Still occurring on 2.1.229: my detector for this shape reported 20 instances in one day on that build. Current local build is 2.1.232.
• macOS (Darwin 25.3), headless/SDK sessions with sub-agents enabled.
• Measurements came from local session transcripts plus request payloads captured by a local logging proxy in front of the API.