Background sub-agents spawned by a subagent stay "Running" forever after the parent completes; TaskStop can't reach them

The orphaned-children problem points at a deeper lifecycle gap: once a subagent's own turn ends, its spawned children have no parent context to report back to, so the system has nowhere to route their completion signals. "TaskStop returns No task found" is the symptom - the underlying issue is that child-of-child agent IDs were registered under the intermediate parent's context, which is now closed.

The per-row stop button and Clear working as expected makes sense - those are UI-level operations that don't go through the same ID resolution path as TaskStop.

One pattern that sidesteps this for now: instead of letting the intermediate agent spawn its own background children, have the orchestrator (main session) spawn all background agents directly, and use SendMessage to coordinate handoffs between them. It's more verbose in the orchestration prompt but keeps all agent IDs under the main context where TaskStop can reach them.

Something like:

• Main session spawns Agent A (background) + Agent B (background) + Agent C (background) upfront
• Uses SendMessage to tell A it's ready to receive B's output
• B/C complete and notify main; main can TaskStop any of them cleanly

The tradeoff is you lose the convenience of having an intermediate agent manage its own sub-team. Would be good to see a supported re-parenting mechanism here - or at minimum a flag to register child agents under the top-level context regardless of which intermediate spawned them.

Confirming this on a second, independent trigger — not an explicit run_in_background: true orchestration prompt, but a general-purpose subagent (dispatched via a Skill-driven task: auditing ~60 files) that autonomously decided to parallelize by spawning 2 of its own children. Same symptom:

• Parent agent completed normally and delivered its result via <task-notification>.
• Its two children (a1ea60339c3a2122d, a464c6b4cd9abee5a) kept showing "Running" in the panel for 1h15min+ after the parent had already returned, counters still ticking.
• TaskStop(task_id=<child>) → No task found for both, as reported here.
• New data point: TaskOutput(task_id=<child>, block=false) (the non-blocking, non-destructive status probe) returns the same No task found — so it's not that TaskStop specifically can't reach them, the entire ID is gone from whatever registry both tools query. Matches @kcarriedo's "registered under the intermediate parent's context, which is now closed" theory.
• Child transcripts (267.9KB / 272.0KB) confirm real work completed, not an infinite loop — this is purely a lifecycle/notification-propagation gap, not a runaway process.

+1 on a supported re-parenting mechanism, or at minimum registering child agent IDs under the top-level session context regardless of which intermediate spawned them.

Tried this on the released 2.1.233 (Linux CLI in tmux, nesting depth 3) following your recipe with three timings: children finishing before the parent completed, children outliving the parent's completion, and children left to finish on their own after the parent was done.

On 2.1.233 the reported behavior no longer occurs:

• Grandchildren of a completed background agent stay visible in the task list, and their completion notifications reach the main conversation.
• TaskStop from the main conversation with the grandchildren's IDs succeeded while they were still running ("Successfully stopped task: …"). Once they finish they leave the list, so a later TaskStop correctly reports no such task.
• Nothing stayed listed as "Running" — the tasks panel ended at Completed/empty in every run.

This was fixed in 2.1.203: "Fixed TaskStop and TaskOutput failing to find background agents spawned by another agent" (changelog). Heads-up: nested spawning was briefly off by default in 2.1.217 and is back on (depth 3) since 2.1.219.

Closing as fixed — if you still see stuck "Running" entries on 2.1.203 or later, reply here and we'll reopen.

🤖 Generated with Claude Code