[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 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

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 <PR> --json comments --jq '[.comments[] | select(.author.login=="some-bot" and (.createdAt > "<timestamp>"))] | length' | grep -qv '^0$'; do sleep 15; done; echo "NEW COMMENT DETECTED"

1. Let the subagent finish its own turn and report status: completed via the task notification (its outer Agent-tool result).
2. 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.
3. From the parent session, run ListAgents: the subagent shows as completed, but there is no entry for the nested Bash polling task.
4. From the parent session, run a fresh Bash ps aux | grep ... for the polling command: no matching process is found.
5. 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_