[BUG] Background subagent's nested background Bash task stays "running" in UI after subagent completes, invisible to ListAgents

### Preflight Checklist

- [x] I have searched [existing issues](https://github.com/anthropics/claude-code/issues?q=is%3Aissue%20state%3Aopen%20label%3Abug) and this hasn't been reported yet
- [x] This is a single bug report (please file separate reports for different bugs)
- [x] I am using the latest version of Claude Code

### What's Wrong?

When a background subagent (spawned via the Agent tool with run_in_background) itself starts a background Bash command (e.g. a polling loop waiting on an external condition like a GitHub PR comment), that inner background process is not tracked as its own task once the parent subagent finishes its turn.

The subagent reports status: completed via its task notification, but the Bash command it spawned continues to show as actively running in the task/tool-call UI with a live elapsed-time counter (observed: 49+ minutes and counting). It does not appear in ListAgents output from the parent session, so there is no way to inspect or confirm whether it's actually still running.

Running `ps aux` from a fresh Bash call in the parent session found no matching process, suggesting it may have already exited — but the UI kept showing it as running regardless, with no way to reconcile the two.

### What Should Happen?

- A subagent's own nested background Bash tasks should be surfaced as children of that subagent (e.g. in ListAgents or an equivalent listing), so the parent session can inspect/verify their real status.
- When a subagent completes its turn, any background Bash process it spawned that is no longer needed should either be auto-terminated, or clearly flagged as orphaned/detached instead of continuing to show a live-looking "running" counter.
- The parent session should have a sanctioned way to confirm the actual status of, and terminate, a background process started by itself or its subagents, without needing raw ps/pkill (which the auto-mode permission classifier blocks as "Interfere With Workloads").

### Error Messages/Logs

```shell
Permission for this action was denied by the Claude Code auto mode classifier. Reason: [Interfere With Workloads].
```

### Steps to Reproduce

1. In an interactive session, spawn a background subagent via the Agent tool with run_in_background: true (e.g. a "git-publisher" style role tasked with pushing a PR and waiting for a bot review comment).
2. Instruct the subagent (in its prompt) to poll an external condition in a loop using a Bash command with run_in_background: true, e.g.:
until gh pr view --json comments --jq '[.comments[] | select(.author.login=="some-bot" and (.createdAt > ""))] | length' | grep -qv '^0$'; do sleep 15; done; echo "NEW COMMENT DETECTED"
3. Let the subagent finish its own turn and report status: completed via the task notification (its outer Agent-tool result).
4. Observe the task/tool-call UI: the inner polling Bash command keeps showing as running with an increasing elapsed-time counter (in this case 49m23s+), even though the subagent that started it already completed.
5. From the parent session, run ListAgents: the subagent shows as completed, but there is no entry for the nested Bash polling task.
6. From the parent session, run a fresh Bash `ps aux | grep ...` for the polling command: no matching process is found.
7. Try `pkill` on the process name to clean up the stale UI entry: blocked by the auto-mode permission classifier with "[Interfere With Workloads]", with no alternative sanctioned way offered to reconcile the UI state.

### Claude Model

None

### Is this a regression?

I don't know

### Last Working Version

_No response_

### Claude Code Version

2.1.276

### Platform

Anthropic API

### Operating System

macOS

### Terminal/Shell

Terminal.app (macOS)

### Additional Information

_No response_

Start at the Agent tool's run_in_background flow and the ListAgents/task-tool-call UI, then trace how nested Bash tasks are registered and finalized when the parent subagent completes. Reproduce the polling-loop scenario on macOS and compare the UI with process state. Done means nested tasks are surfaced with accurate lifecycle status and have a sanctioned inspection or termination path, or are clearly marked orphaned or detached.

Written by the indexing model from the issue text.