Nested (grandchild) background agents can't message their direct parent — parent stalls indefinitely

Summary

A background agent spawned via the Agent tool, which itself spawns nested sub-agents (a "grandchild" level of the orchestration tree), stalls indefinitely once those nested sub-agents complete. The nested agents' completion never reaches their direct parent — instead their SendMessage reply is addressed to the parent's generic role/type label (e.g. general-purpose) rather than a resolvable agent ID, fails to deliver, and falls back to routing to the top-level session (main) instead. The parent agent, having said something like "I'll wait for the review agents to finish," never receives its children's results through its own await path and sits idle forever, with no further notification, until something external resumes it.

Environment

• Claude Code CLI, Agent tool (background agent spawning), isolation: "worktree", subagent_type: "general-purpose"
• Reproduced from a top-level interactive session that spawned several background agents, some of which internally fanned out into 3-4 nested review sub-agents during a self-review phase (a common pattern: implement → spawn N reviewer agents → synthesize findings → finalize)

Reproduction / observed behavior

1. Top-level session spawns Agent A (background, subagent_type: general-purpose) to do a task that includes a "review your own work" step.
2. Agent A itself calls the Agent tool to spawn 3-4 nested reviewer agents (B1, B2, B3...) in parallel, then its own turn ends with output like "I'll wait for the review agents to finish."
3. B1, B2, B3 each complete their review and attempt to report back — logged attempt: SendMessage(to="general-purpose", ...).
4. That SendMessage call fails ("recipient name not reachable" / "general-purpose wasn't a resolvable agent name or ID") because general-purpose is Agent A's role/type, not a unique identifier the messaging layer can route on.
5. The failure causes B1/B2/B3 to fall back to routing their reply to main (the top-level session) instead of Agent A — this happened 8 out of 8 times across 4 independent instances of this pattern in a single session (2 nested reviewers per instance on average).
6. Agent A never receives its children's output through any channel. It has no live background children of its own by this point, so it should be eligible for re-invocation/notification, but no such notification ever fires.
7. Agent A remains stalled — confirmed directly in one case via TaskOutput(task_id=<A's id>, block=false), which returned "No task found with ID: <A's id>" (i.e. A has no active task, it's simply idle, not crashed or still computing). In three other cases, 2-3+ hours passed with zero new commits/tool activity from Agent A despite all the information it was "waiting for" having already arrived (just at the wrong destination).
8. Workaround that reliably un-sticks it: the top-level session manually calls SendMessage(to=<A's actual raw agent ID>, message="status check, please finalize"). This resumes Agent A immediately ("had no active task; resumed from transcript in the background with your message"), and A then finishes its work in under 5 minutes in every case tested.

Suggested root cause

Nested (grandchild-level) agents appear to be given only their parent's role/type label as the addressable "reply to whoever spawned me" target, rather than the parent's actual unique agent ID. SendMessage can't resolve a type label to a specific running instance, so the report-back mechanism silently fails and falls back to the top-level session — which has no way to know it needs to relay the message back down to the actual parent (a parent it may not even be directly aware spawned children of its own).

This looks specific to 2+ levels of agent nesting (agent → agent → agent). Direct child → top-level-session notification worked reliably throughout the same session (I received proper <task-notification> events for every agent I spawned directly) — it's specifically the grandchild → parent-agent hop that breaks.

Impact

Any workflow that has a background agent do its own multi-agent review/verification internally (a natural and encouraged pattern — spawn N reviewers, synthesize, finalize) will silently hang at that step, indistinguishable from the agent still legitimately working, unless a human or the top-level session notices stray messages arriving from unrelated "general-purpose" senders and manually intervenes. In my case this stalled 4 parallel workflows for 2.5-3+ hours each before I diagnosed it and worked around it by killing and respawning with an explicit "do not spawn sub-agents" constraint.

Suggested fix direction

Give a spawned agent a way to address its actual parent (e.g. pass the parent's real agent ID/name into the child's context so SendMessage(to=<parent>) resolves), rather than only the type label. Alternatively/additionally, when a SendMessage to an unreachable role-label target falls back to main, propagate enough context that the top-level session can identify and forward it to the correct grandparent-of-origin automatically, rather than requiring a human to notice and manually bridge it.