Background tasks (run_in_background Bash + Agent) stay "Running" in the panel forever after completing

Status Fixed / completed

Reported on v2.1.170

Maintainer reply ✓ Yes — bcherny

Activity 4 comments · opened Jun 10, 2026 · closed Aug 17, 2026

💡 Likely answer: A maintainer (bcherny, collaborator) responded on this thread — see the highlighted reply below.

Bug

Background tasks (run_in_background: true Bash, and Agent/subagent tasks) never transition out of the Running section of the Background-tasks panel, even after they complete successfully — they accumulate indefinitely and persist across app restarts.

Repro

Have the model run a Bash command with run_in_background: true that exits quickly (e.g. an until-loop poll that completes).
The task completes: exit code 0, the <task-notification> is delivered to the conversation, and TaskStop/TaskOutput on its ID return "No task found" (the agent-side registry has GC'd it).
The Background-tasks panel still shows it under Running — forever. Foreground Bash invocations from the same session correctly appear under Finished.

Observed scale

One project accumulated 88 "Running" entries (durations up to 27,929 minutes ≈ 19 days). After a manual flush, 9 re-accumulated within a day — including a task that verifiably completed with a delivered notification 5+ hours earlier (panel showed Bash 332m, still Running). Agent-type tasks from ~3 weeks ago show the same stuck state with viewable transcripts.

Expected

A background task whose process has exited (success or failure) should move to Finished like foreground tasks do, or at minimum be reaped when the harness GC's it from the tool-facing registry (the two views currently disagree: TaskStop says "No task found" while the UI says "Running").

Environment

Linux dev box (Ubuntu, kernel 6.17), Claude Code CLI with Remote Control enabled (panel observed via Remote Control UI)
Version: 2.1.170 (Claude Code)

View original on GitHub ↗

4 Comments

zaziszaz · 1 month ago

Possibly explains why this persists past v2.1.198's announced fix ("Background tasks in web, desktop, and VS Code task panels no longer get stuck on 'Running' after finishing or resuming") — worth checking for a stale Desktop-app bundle before assuming the fix didn't work or regressed.

Repro'd this on macOS Desktop today: two Agent-tool subagents dispatched, both completed cleanly (TaskOutput(block=true) → status:completed, clean transcript termination, correct final tool/token counts shown in the panel), backend registry correctly evicted them post-retrieval (TaskOutput(block=false) → "No task found" — not a crash/ghost-handle case, confirmed no process restart in the session). Panel kept both listed under Running 35+ min later with a live elapsed timer just counting wall-clock-since-dispatch.

Checked claude --version → 2.1.200. But every message in the session's own transcript stamps "version":"2.1.197" — three releases behind, and predating the panel fix entirely. Confirmed via the in-app diagnostics export: Updater state: idle, hourly auto-check ran and found nothing newer than the currently-installed build. So this Desktop install's bundled engine never received 2.1.198+ — it isn't that the fix regressed, it's that the Desktop app's embedded engine updates on a separate, slower cadence than the CLI, and this install hasn't picked up a newer bundle.

cc #72965 — that report's environment info also lists Version: 2.1.197, same stale version, independent machine.

oconnorjoseph · 1 month ago

+1, hitting this too — Claude Code 2.1.207 on macOS 26.5.1.

Confirmed it's not project-side config for us: our repo has a custom statusLine command, but it only renders model name/context %/rate-limit bars — zero agent-tracking logic. So the stuck "Running" state is definitely coming from the built-in Background-tasks registry/panel, not anything a user's settings.json or hooks could cause.

Also worth noting: our repro was a plain top-level Agent tool spawn from the main session (not nested/child-of-child like #73916 and #74219) — so this looks like the general registry-vs-panel desync described here, not something specific to nested spawning. Broadens the blast radius a bit.

This is a daily annoyance for anyone doing multi-agent orchestration workflows — would appreciate this getting prioritized.

bcherny collaborator · 14 days ago

Thanks for the detailed report and repro. I attempted a fresh black-box repro on 2.1.233 on Linux (tmux, clean install), but our test environment couldn't authenticate the released build, so I verified against the release history instead.

What you describe — background Bash and Agent tasks completing (notification delivered, stop/output saying "No task found") while the tasks panel keeps them under Running forever, accumulating across restarts — matches a known bug class that was fixed after the version you reported (~2.1.16x):

2.1.198: "Fixed background tasks in web, desktop, and VS Code task panels getting stuck on 'Running' after they finish or after resuming a session"
2.1.205: fixed stale "Running" status in the web/mobile Remote Control panels
2.1.208: orphaned-background-task notices on resume collapse into a single summary

On current releases, tasks orphaned by a previous process exit are also reconciled to a terminal state on resume instead of showing as running forever. Changelog: https://github.com/anthropics/claude-code/blob/main/CHANGELOG.md

Closing as fixed in 2.1.198 — if you still see stuck "Running" entries on 2.1.233 or later, please reply with the exact panel you're looking at (terminal Ctrl+B dialog vs. Desktop/VS Code/claude.ai task panel) and we'll reopen.

🤖 Generated with Claude Code

zaziszaz · 12 days ago

Thanks for looking into this — appreciate the detail. I'll update Desktop and keep an eye out; will reopen if it resurfaces.