Nested subagents remain stuck as "Running" in Background tasks panel after parent subagent completes

Confirmed reproducing a similar pattern here -- nested agents getting stuck as "Running" after the parent completes is a lifecycle registration gap that bites you specifically in reviewer/implementer flows where the parent is short-lived but the nested validators keep running.

The TaskStop failure ("No task found with ID") points to the core issue: the main session's task registry only tracks agents it directly dispatched. Grandchild agents registered against the intermediate parent's task context, and when the parent exited, that context was torn down -- but the Background tasks panel never got the tombstone event.

A few things that reduce the blast radius while waiting for a fix:

1. Run nested agents with an explicit timeout rather than letting them run to natural completion. They will still show as "Running" in the panel but will actually terminate.

1. Use hooks to emit a completion event from each nested agent before it exits -- a shell hook that writes to a temp file the orchestrator polls. Crude but gives you a kill-signal path.

1. Keep nested fan-out to one level deep. If subagent A needs parallel work done, have it report back to the main session and let the main session dispatch the grandchildren. That way all active agents are children of the main task registry and the panel tracks them correctly.

The underlying fix needs to be propagating task lifecycle events through the full agent tree, not just one level deep.

Same root cause as the flat task registry problem in #74133 -- nested subagents spawned by an intermediate agent don't propagate their IDs up the chain, so the main session's TaskStop has nothing to call against them.

The "stuck as Running for 11 hours" behavior makes sense given how the state machine works: the nested agents completed their work and sent their results, but the lifecycle notification that should flip the UI state never traveled up through the intermediate agent to the parent session. The parent never knew to mark them done.

Workaround that helps: in the intermediate subagent's system prompt, add an explicit instruction to collect all child task IDs it spawns and echo them in its final report. The main session can then attempt TaskStop on those IDs directly. It doesn't always work because the IDs aren't in the main session's namespace, but sometimes it does.

The better fix is what you're asking for: automatic propagation of terminal state through the delegation tree, or a TaskList that shows all descendants regardless of dispatch depth.

Confirming this also reproduces on Windows Desktop app (not just macOS reported above), with an additional data point: even the parent agent itself, when resumed via SendMessage and explicitly asked to stop the 4 nested children it had spawned, called TaskStop on their IDs and got No task found for all 4 — same result as calling TaskStop directly from the main session. So the "no owner context to route the stop through" issue holds even when you go through the original spawning agent, not just the top-level session.

Environment: Claude Code Desktop, Windows

Repro: Main session dispatches an agent for a research task (4 independent verification sub-tasks: CVE lookup, GitHub repo stats, third-party source check, npm/PyPI data). The agent spawns 4 nested children via the Agent tool to parallelize this, then returns a consolidated report and completes. The Background tasks panel continued showing all 4 nested children as "Running" for 3h49m+ (token counters: ~65k/73k/63k/104k, frozen). Restarting the app did not clear the display.

TaskStop on the 4 children's IDs → No task found (from main session).
Resuming the parent agent via SendMessage and asking it to stop its own children → it also got No task found on all 4 IDs when trying TaskStop itself.

No apparent ongoing token cost (consistent with the work having actually finished), but the panel display never clears — purely a UI/lifecycle-tracking bug, matching the root cause theory already discussed in this thread (nested-agent completion never propagated once the intermediate parent's context tears down).

A few things that reduce the blast radius while waiting for a fix: 1. Run nested agents with an explicit timeout rather than letting them run to natural completion. They will still show as "Running" in the panel but will actually terminate. 2. Use hooks to emit a completion event from each nested agent before it exits -- a shell hook that writes to a temp file the orchestrator polls. Crude but gives you a kill-signal path. 3. Keep nested fan-out to one level deep. If subagent A needs parallel work done, have it report back to the main session and let the main session dispatch the grandchildren. That way all active agents are children of the main task registry and the panel tracks them correctly. The underlying fix needs to be propagating task lifecycle events through the full agent tree, not just one level deep.

Thanks for the tips! I never thought to put a timeout on subagent fan-out, that seems like a good suggestion for a default instruction for agents.