[BUG] TaskStop cannot dismiss or reach tasks visible in the Background Tasks UI panel

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?

The Background Tasks UI panel shows N "active shells" (in my session, 24). They include:

1. Tasks from the current session that have already completed (showing the red/green dot "Stop Task" → completed/failed state).
2. Long-running polling loops (until ssh ...; do sleep N; done, ssh host "ps aux | grep ...") left over from prior sessions that outlived their parent assistant context. Many target .local hostnames that no longer resolve, so they sit blocked on DNS/SSH timeouts indefinitely.

When the assistant calls TaskStop with IDs visible in the UI (e.g. bxixpfkst, bl2776033, br5mjokkz, b2zxf20pe, bg446ei8e, bb63t5mn9, bqyyfgdwg, b31cejiu1, b5z7rgz5q, brihddycm), the tool returns:

▎ Error: No task found with ID: <id>

…even though the UI continues to display them as dismissable items. Only tasks spawned inside the current assistant turn and still running in the task pool are addressable by TaskStop.

There is no assistant-facing API to:

• dismiss completed/failed entries from the UI history
• stop stale shells from prior sessions
• enumerate the list the UI sees (no TaskList equivalent for background Bash tasks)

What Should Happen?

Environment

• Claude Code CLI (macOS)
• Model: Claude Opus 4.7 (1M context)
• Session type: /loop autonomous mode with multiple run_in_background: true Bash calls

Expected behaviour is either:

1. TaskStop should accept any task ID visible in the Background Tasks UI panel regardless of which assistant turn spawned it, and should be able to dismiss completed/failed entries; OR
2. A separate TaskDismiss / BashCleanup tool that lets the assistant garbage-collect stale shells on the user's behalf.

Actual behaviour

Only tasks from the current run are reachable; everything else persists forever and must be cleared via the UI keybinding (which the user discovered themselves — there's no documented procedure).

Impact

In long autonomous loops with many fleet-check SSH commands, the list grows unboundedly and can mask actual active work. Stale shells from prior sessions continue burning CPU on dead polling loops (low overhead but non-zero), and the user has no assistant-side way to clean them between sessions.

Error Messages/Logs

⏺ Stop Task
Error: No task found with ID: bxixpfkst

⏺ Stop Task
Error: No task found with ID: bl2776033

⏺ Stop Task
Error: No task found with ID: br5mjokkz

⏺ Stop Task
Error: No task found with ID: b2zxf20pe

⏺ Stop Task
Error: No task found with ID: bg446ei8e

⏺ Stop Task
Error: No task found with ID: bb63t5mn9

⏺ Stop Task
Error: No task found with ID: bqyyfgdwg

⏺ Stop Task
Error: No task found with ID: b31cejiu1

⏺ Stop Task
Error: No task found with ID: b5z7rgz5q

Steps to Reproduce

1. Start a long Claude Code session.
2. Launch several Bash calls with run_in_background: true.
3. Let some complete and some fail.
4. Start a new session in the same workspace.
5. Observe that prior-session backgrounds still appear in the Background Tasks panel, and TaskStop returns "No task found" for any of their IDs.

Claude Model

Opus

Is this a regression?

I don't know

Last Working Version

_No response_

Claude Code Version

2.1.116 (Claude Code)

Platform

Anthropic API

Operating System

macOS

Terminal/Shell

iTerm2

Additional Information

_No response_