[BUG] SendMessage-resumed subagent's completion notification routes to the session root, not to the resumer

What's Wrong?

When a background subagent B resumes its own child C via SendMessage, C's next completion notification is delivered to the top-level session (the root conversation), not to B — even though B is the agent blocked waiting on C. B, having ended its turn to wait, never wakes; the work stalls until a human (or the root session) notices the orphaned <task-notification> and manually relays the result down to B.

Observed ~10 independent times in one week of multi-agent runs; worst cascade put an entire 3-level agent chain to sleep for 83 minutes. Fresh (never-resumed) children notify their spawner correctly — the misrouting starts with the first SendMessage resume.

What Should Happen?

A resumed subagent's completion should notify the agent that resumed it (or at least its original spawner) — the agent actually waiting on it. The session root should only be notified when the root spawned/resumed it.

Steps to Reproduce

1. In an interactive session, spawn background subagent A (general-purpose) whose prompt is: "Spawn one background child B (general-purpose) with the prompt 'Wait for further instructions, reply DONE when told to finish.' Record B's agentId, then end your turn to wait for B."
2. A ends its turn (correct wait behaviour — A has a live child).
3. Send A a message: "resume B via SendMessage telling it to finish, then end your turn and wait for B's completion." A does so and stops.
4. B finishes. Observe: B's <task-notification> (with its final result) arrives in the ROOT conversation; A is never re-invoked and sleeps indefinitely.

Context (shared setup for this report)

We run deep background-subagent trees (session root → coordinator agent → slice agents → task agents, all general-purpose, fork mode on, interactive CLI session). Since all Agent spawns became asynchronous, "end the turn with live background tasks" is the wait primitive: the harness re-invokes the parent when a child completes. That contract holds for fresh spawns — this report is about one specific case where it breaks. Observed across ~9 long autonomous runs on Claude Code 2.1.234–2.1.238 (Linux/Fedora, Anthropic API).

Error Messages/Logs

(see Steps to Reproduce; key strings quoted inline)

Claude Model

Not sure / Multiple models (sonnet + opus subagents)

Is this a regression?

I don't know (observed on every version we ran: 2.1.234 → 2.1.238)

Claude Code Version

2.1.238 (Claude Code)

Platform

Anthropic API

OS

Linux (Fedora 44)

---
Related (distinct bugs in the same subsystem, filed separately per the single-bug rule): #89043, #89044, #89045. Together they make completion delivery unreliable for anything except fresh never-resumed spawns; field evidence: ~4–5 h of stalls across 9 multi-agent runs in one week.