Orphaned background sub-agents spawned by another agent are invisible/uncontrollable from the main loop

Description

A subagent spawned via the Agent tool internally spawned its own child subagents, then returned its final answer to the main loop without waiting for or cleaning up those children. The children kept running in the background (29+ minutes and counting at report time), visible to the user in the Claude Code UI's "Background tasks" panel, but invisible and uncontrollable from the main loop / model side — there was no tool available to list or stop them by ID, since the model never received their task IDs in the first place.

Steps to reproduce

1. In a Claude Code session, ask the assistant to investigate something that causes it to spawn an Agent (e.g. subagent_type: general-purpose) for research.
2. That subagent, given access to the Agent tool itself, invokes it to fan out into further sub-agents to parallelize its own investigation.
3. The subagent's final returned text contains a remark indicating it attempted a tool call that didn't behave as expected and gave up waiting on the children, e.g. (verbatim from the transcript that triggered this report):

> "That's fine — that tool was for a different task type. The background agent will just complete harmlessly; I have all findings verified directly."

1. The subagent returns its final answer as the Agent tool's result. The main loop receives this as a completed task notification and reports the work as done.
2. Meanwhile, the two child agents it spawned (visible in the UI's "Background tasks" panel as e.g. "Find user avatar self-lookup and logout logic" and "Find notification and privacy policy fetch calls") keep running indefinitely in the background — well past the point where their output is needed.
3. The user notices the still-running tasks in the UI panel and asks the assistant what they're doing / to stop them.
4. The assistant has no way to answer or act: it never received task IDs for these grandchild agents, and none of the available tools (TaskList/TaskGet/TaskUpdate — a todo-list feature, not background-process tracking; TaskStop — requires a task ID the model never had) can enumerate or terminate background agents that were spawned transitively by another agent rather than directly by the main loop.

Expected behavior

• Background agents/tasks spawned (even transitively, by a subagent rather than directly by the main loop) should be enumerable and stoppable by the orchestrating model — e.g. a "list all background tasks in this session, including those spawned by subagents" tool, or task IDs for transitively-spawned agents should be surfaced back up through the parent's tool result.
• At minimum, when a subagent returns its final result, any background children it spawned and did not wait on should be automatically cancelled (or the parent should be prevented from returning until its own children resolve/are explicitly detached) — an agent shouldn't be able to "walk away" from work it started.
• The model should never have to tell the user "I can't reach my own agents, please stop them yourself via the UI" — that's a loss of control over the agent's own delegated work, and it fully defeats the purpose of routing through the assistant in the first place.

Environment

• Claude Code CLI, claude-sonnet-5 model
• macOS (Darwin 24.6.0)
• Observed via the Agent tool (subagent_type: general-purpose) spawning nested subagents during a multi-step investigation task