[Bug] Subagent results route to root teammate instead of spawning teammate

I encountered the same issue - rendering the nested subagents a bit ad-absurdum since the main context gets all these stray messages and tries to deal with them.

Corroborating with a clean, fully-instrumented repro from today (Claude Desktop 1.18286.0, embedded Claude Code engine 2.1.197, macOS).

Environment: a top-level session dispatched several general-purpose review/investigation subagents via the Agent tool. At least one of those subagents itself called Agent(..., run_in_background: true) to spawn its own nested investigation (three confirmed instances: a Zoom F3 file-format investigation, a Zoom H3-VR investigation, and a removed-behavior audit angle).

What happened: the nested agent's Agent tool call returned the standard async-launch response — "The agent is working in the background. You will be notified automatically when it completes... If the user asks for progress, say the agent is still running." The spawning subagent (itself a one-shot, non-persistent invocation) faithfully followed that guidance, reported back to its own caller that it was "waiting for a background investigation agent," and then terminated its own turn — at which point it had no further ability to receive that notification. The notification instead had to surface somewhere else in the hierarchy later.

Downstream effect observed in the same session: the top-level user later noticed "three tasks running from hours ago" and, in a second occurrence, "still 7 running tasks" — these were exactly the orphaned grandchildren whose results had nowhere valid to land, because the immediate parent that spawned them (the one-shot subagent) was long gone. The top-level orchestrator ended up having to manually re-launch each investigation synchronously with explicit instructions ("there is no other agent doing this work; do not spawn sub-agents, do not wait for anything").

This matches the routing description here exactly — the fix likely needs to either (a) route nested-agent completions to a live ancestor rather than nowhere/root, or (b) prevent an ephemeral one-shot subagent from being offered run_in_background: true at all, since it structurally cannot act on a later notification.

Happy to share exact task IDs / timestamps from my session transcript if useful for triage.

Stronger follow-up evidence from a second repro today (same environment: Claude Desktop 1.18286.0, embedded engine 2.1.197, macOS) — this time inspected directly on disk rather than inferred from conversation text.

A single top-level call ("Verify external technical facts in heimdall spec", one Agent dispatch) cascaded into 22 subagent transcript files, 5 spawn-levels deep, per the spawnDepth field in each .meta.json sidecar:

• Depth 1: the actual requested fact-check
• Depth 2: OS credential-store research, sandboxing claims, licensing checks — including one agent whose recorded description is literally "noop" and another "Placeholder while awaiting background agents"
• Depth 3–5: the same handful of claims (Secret Service headless reliability, Windows Credential Manager, macOS Keychain silent access) independently re-researched by multiple different descendants, apparently because each depth's agent, unable to actually await its own nested spawn, moved on and let a sibling/later agent redo the same lookup

The "Placeholder while awaiting background agents" entry is a directly self-documented instance of the exact failure mode described in this issue and #69824 — a subagent spawned a nested background agent, couldn't wait on it (no live context to receive the eventual notification), and synthesized a placeholder child instead of the real result.

On the cost/danger side, for anyone else finding this thread worried about runaway billing: checked file mtimes against wall-clock time — the newest of the 22 transcript files had been untouched for ~1h50m at inspection time, all ending in cleanly-terminated assistant messages, none still appending. So once the routing failure occurs, the orphaned descendants don't keep burning tokens forever — they just silently stop and leave a stale "running" indicator + a lot of untraceable, duplicated work product behind. Still a real bug (wasted work, misleading UI, and the recursive fan-out itself burns real tokens before it stalls out), just not an open-ended cost bleed.

Happy to share the raw .meta.json set or transcript paths if it helps triage the routing/depth-cap fix.