Background tasks stuck "running" forever in CLI conversation; cannot cancel, and /feedback cannot report it

Repro from Claude desktop app (macOS), persisting across sessions the last few days:

• Spawned ~9 background subagents (Agent tool, run_in_background) for a research fan-out in a single conversation.
• Several of them errored out with provider-side rate-limit errors ("Server is temporarily limiting requests · Rate limited") instead of completing cleanly.
• Verified directly in the session transcript (~/.claude/projects/.../*.jsonl) that every spawned agent has a completed task-notification status — none are actually still running.
• Despite that, the UI's "N running tasks" badge shows a stale/inflated count (currently showing "17 running tasks") that does not match reality and does not clear.
• This matches the pattern described above: mixed completion/error outcomes across a fan-out of background agents in one session appears to be a reliable trigger, not a rare edge case.

Confirms this is UI-side bookkeeping decoupled from actual process/task state, not something users can self-diagnose from within the conversation (the assistant itself can only confirm via raw transcript inspection that nothing is actually running).

Hitting this too. Ran a multi-hour run_in_background script (a data backfill against an external API), watched its progress via the Monitor tool. Background process completed successfully and was totally unaffected, but the session/UI itself froze and stopped responding — had to force-close and lose the session. Would love to see this prioritized, it's a real trust issue when you can't tell if the harness or the actual work has stalled.

Confirming this on the latest Desktop build as well — same symptom, still present.

Environment: Claude Desktop 1.18286.0 (2026-07-02), reported by Settings/About as fully up to date, no pending update. Trigger was two claude-code-guide subagent calls issued back-to-back in a single session (one completed normally, the other never resolved).

Observed: persistent "N running tasks" badge in the Desktop app. The Background tasks panel itself shows nothing, an empty list with no matching entry for the stuck task. Confirmed from within the session's own task system (TaskList) that nothing is actually running.

This matches the report here exactly, and also lines up with the stale-persistence root cause described in #59456 (closed/fixed), which appears to be a different or not-fully-covered edge case from this one, since #68992 is still open on a build well past that fix.

Also confirming the same negative result already noted in the issue: restarting the Desktop app did not clear the badge. Clearing cache en restarting also did not clear the badge.

Happy to provide session logs/repro steps in more detail if useful.

The core problem you're describing -- tasks bookmarked as "running" in the state layer after the underlying process is gone -- is a missing reconciliation step. The session lifecycle doesn't do a liveness check on stored task state when it starts up, so stale "running" entries from a previous session persist indefinitely.

Your three suggested fixes are the right ones. Adding to that:

The IndexedDB rebuild not helping is expected if the state that's stuck is on the server-side task record, not just the local DB. In that case, local cache clearing doesn't touch it.

The /feedback command stalling on large conversations is a separate but related failure mode: it loads the full transcript to attach as context, which causes it to hit the same hanging session. A workaround is to open a fresh conversation and use /feedback from there -- it should submit without inheriting the hung state.

One pattern I've found useful for avoiding this: before ending a session that has background tasks, explicitly confirm each one is in a terminal state (done, failed, cancelled) rather than relying on the UI's cleanup. The UI tends to report "tasks finished" before the underlying bookkeeping actually settles.

Hit this today on macOS in a live, healthy session — which I think is a narrower and more actionable variant than the session-ended case in the original report, so adding evidence rather than opening a duplicate.

Environment: Claude Code 2.1.220, macOS 26.5.2 (Darwin 25.5.0), desktop app.

What happened

A long autonomous session accumulated 4 tasks stuck in Running — 6h05m, 5h54m, 5h44m, 5h18m — against 48 finished. The session never ended, was never interrupted, and stayed responsive throughout. New messages did not hang, and TaskStop did successfully stop all four, so both of those differ from the original report.

The important part: only 1 of the 4 was actually a harness bug

I checked each against ps before concluding anything, and I think this distinction matters for diagnosing it:

• 3 of 4 had live processes and were correctly reported as Running. Those were my own bugs — two until … do sleep 20; done loops polling for a file that never appeared, and a Node script that could never exit because a pg client error path skipped client.end(), leaving an open socket as a live libuv handle. The harness was right; my code was wrong.

• 1 of 4 was genuinely orphaned. That's the one this issue is about:

``
./scripts/automation-validate.sh --ios-tests 2>&1 | tail -12
``

It exceeded the 600s foreground limit and was moved to background as expected. Later, ps showed none of its process tree — no automation-validate.sh, no child xcodebuild — and its output file was 0 bytes. The panel showed it Running for 6h05m regardless. Nothing ever reconciled the tracked task against its pid, and the only way out was a manual TaskStop.

So the trigger here isn't "the session ended before completion events were recorded" — it's the process tree exiting without the harness observing it, mid-session. A pid check at any point in those 6 hours would have caught it.

Suggested fixes

1. Poll the tracked pid. When a background task's process tree is gone, transition it to a terminal state with whatever output was captured. This covers both the session-ended case in the original report and the mid-session case above.
2. Surface "running N hours with zero bytes of output" as a warning. All four of mine would have been flagged by this well before hour six, and it needs no pid tracking to implement.

A usability note that made this much worse to diagnose

Piping a long-running command through tail (… 2>&1 | tail -12) means nothing is written until the process exits. So for six hours the task showed Running with an empty output file — indistinguishable from "still working." That ambiguity is why I went and wrote more waiter tasks instead of investigating, which is how one stuck task became four.

That part is my own usage error, not a bug. But since the harness already knows both "how long has this run" and "how many bytes has it emitted," suggestion 2 above would have turned a six-hour mystery into an immediate signal.