Background tasks started by a non-root sub-agent become permanently orphaned once that sub-agent's turn ends

Title: Background tasks started by a non-root sub-agent become permanently orphaned once that sub-agent's turn ends

Claude Code version: 2.1.208

Summary

A background task (Bash run_in_background: true, likely also applies to a nested
Agent/Task dispatch) started by a sub-agent that is not the root session becomes
completely untrackable — not pollable via TaskOutput, not stoppable via TaskStop,
no completion notification ever surfaces — the moment the spawning sub-agent's own
turn ends. This isn't a routing gap (e.g., "the notification goes to the wrong
place") — the task appears to vanish entirely from the root session's task registry.

Repro steps

1. From a root session, dispatch a sub-agent (Agent tool).
2. Within that sub-agent's own turn, have it start a Bash command with

run_in_background: true (e.g., sleep 25 && echo done), then immediately report
the assigned task_id in its final message without waiting on it, polling it, or
calling TaskOutput, and stop.

1. Back in the root session, once notified that the sub-agent's own turn ended, call

TaskOutput(task_id=<the id the sub-agent reported>, block=false).

Expected: either the background task is discoverable and its eventual completion
is reported to root somehow, or at minimum TaskOutput returns a real status
(running/completed) for a task that verifiably exists.

Actual: TaskOutput returns No task found with ID: <id>. The task is invisible
to root immediately, well before the sleep 25 would even complete. TaskList shows
no trace of it either.

Why this matters

This breaks any multi-level agent architecture where an intermediate (non-root) agent
needs to delegate work asynchronously — e.g., an orchestrator dispatching a persistent
"lead" sub-agent, which itself dispatches further sub-agents for individual work
batches. If any of those non-root dispatches ever background something (intentionally,
or because a tool defaulted to backgrounding despite the caller not asking for it), the
work is silently lost with no way for anything in the session tree — including the
root — to recover it, retrieve its output, or even learn it's stuck.

We hit this as the apparent root cause of real, multi-hour hangs in an autonomous
overnight orchestration workflow (nested sub-agent backgrounds a test run, the
immediate parent waits for it forever, and even the top-level session has no way to
intervene since it can't see the orphaned task at all).

Notes

• A separate, possibly related observation: the harness's own boilerplate

task-notification text states "A task-notification fires each time this agent stops
with no live background children of its own" — in our test, the parent's own
completion notification fired promptly despite it having a live background Bash
child at that moment. Not sure if that's expected behavior for raw Bash children
specifically (as opposed to nested agent children), but flagging it as a possible
related inconsistency.