[BUG] Tasks sidebar shows zombie "Running" entries after background Bash tasks complete; Stop button is no-op

Resolved 💬 3 comments Opened May 17, 2026 by leithl Closed May 17, 2026

What's Wrong?

Background Bash tasks launched via run_in_background: true (e.g., until grep -q ...; do sleep 5; done polling loops) leave zombie entries in the Tasks sidebar after they've actually finished. The sidebar shows them as Running with a Stop button, but:

  • The underlying shell processes have already exited (ps aux | grep returns nothing matching)
  • The harness itself has dropped the tasks — calling the TaskStop tool with the original task ID returns No task found with ID: <id>
  • Clicking the Stop button in the sidebar does nothing — the entry stays visible
  • The completion notification DID fire correctly in the chat at the time the process exited; only the sidebar UI is stale

After several deploys in one session, four zombie entries accumulated in the panel. None of them can be cleared.

What Should Happen?

When a background Bash task exits, the corresponding sidebar entry should either move to a "Completed" section or be removed. The Stop button on a sidebar entry should reliably terminate the underlying process OR (if the process is already gone) clear the sidebar entry as a fallback.

Steps to Reproduce

  1. Launch a short-lived background Bash task in the assistant tool — e.g., poll a log file for a sentinel line:

``bash
echo "DONE" > /tmp/sentinel.txt
# then in a separate assistant turn with run_in_background: true:
until grep -q "DONE" /tmp/sentinel.txt; do sleep 5; done
``

  1. Wait for the completion notification in chat (arrives within seconds since the sentinel already matches).
  2. Open the Tasks sidebar — the task still appears as Running.
  3. Click Stop — nothing changes.
  4. Confirm via shell that no matching process exists:

``bash
ps aux | grep "until grep" | grep -v grep
``

  1. Repeat steps 1–5 a few times during the same session — the panel accumulates zombie entries.

Error Messages/Logs

TaskStop tool result for the zombie's original task_id:
  "No task found with ID: bb39ysgjg"
  "No task found with ID: b4ulwd5aw"

(So the harness has cleaned up its task records; only the sidebar UI is stale.)

Claude Model

Opus 4.7 (1M context) — model id claude-opus-4-7[1m]

Is this a regression?

I don't know

Claude Code Version

2.1.71 (Claude Code)

Platform

Anthropic API

Operating System

macOS

Terminal/Shell

Other — Claude Code desktop app (Cowork) on macOS Darwin 25.4.0, zsh shell.

Additional Information

  • Workaround: /clear or session restart drops the zombie entries.
  • Conjecture: the harness emits the completion event to the chat (notification arrives) but doesn't emit it to the sidebar UI's task-state store, so the sidebar's render keeps showing Running. The fact that TaskStop reports "No task found" suggests the harness-side task record is correctly cleaned; only the UI subscription is missing an update.

View original on GitHub ↗

This issue has 3 comments on GitHub. Read the full discussion on GitHub ↗