Background task UI shows stale "Running" state after task is killed externally; Stop button has no effect

Environment

• Claude Code version: 2.1.150 (Claude Code)
• OS: macOS (zsh)
• Date observed: 2026-05-27

Description

A background Bash task spawned via Bash(run_in_background: true) continues to display as Running in the Background Tasks panel of the UI for hours after the underlying OS process tree has been killed externally. Clicking the Stop button next to the task has no effect — the entry remains stuck in "Running" state.

The assistant-side TaskStop tool call against the same task_id returns No task found with ID: <id>, indicating the task harness has already removed the task from its registry, but the UI still displays it.

Steps to reproduce

1. Start a long-running shell command in the background:

``
Bash(command: "./gradlew :oa-cms:bootRun > /tmp/log 2>&1", run_in_background: true)
``

1. Externally kill the underlying process tree from another bash invocation:

``
pkill -f "java.*oa-cms"
``

1. Observe the Background Tasks panel in the Claude Code UI — the task entry still shows "Running Bash" with an incrementing timer (in my case it stayed at "Running" for 150+ minutes after the process died).
2. Click the Stop button on the entry — no visible effect, the entry stays.

Expected behavior

• UI should reconcile with the task harness. Once the harness no longer holds the task in its registry, the UI entry should be removed (or marked as failed/killed).
• Clicking Stop on an already-dead task should at minimum remove the UI entry.

Actual behavior

• UI state diverges from harness state and stays stale until the user fully restarts the Claude Code client.
• Stop button click is a no-op.
• The assistant cannot resolve this — TaskStop returns No task found, yet the UI persists.

Evidence (from my session)

Task ID: b3trtztoj (started ~13:13, observed at ~15:46 still "Running 153m 56s")

$ ps aux | grep "java.*oa-cms" | grep -v grep
(no output — process is gone)

$ lsof -i :19098 -nP | grep LISTEN
(no output — port is free)

# Assistant-side tool call:
TaskStop b3trtztoj
→ Error: No task found with ID: b3trtztoj

# UI: still shows "Start oa-cms backend in background — Running Bash 153m 56s"
#     with active Stop button that does nothing on click

Severity

Low (cosmetic) but confusing — users have no reliable way to tell from the UI whether a background task is actually alive without manually ps-ing the process tree. Particularly noticeable during dev-server workflows where users kill/restart frequently.

Suggested fix

Add a periodic reconcile in the UI's Background Tasks panel that re-fetches the active task list from the harness; if a displayed task is no longer present in the harness registry, automatically remove the UI entry (or mark it as terminated).