[BUG] Desktop sidebar keeps showing session "running" dot after all background tasks have exited
What's Wrong?
In the Claude Desktop app (macOS), the session list in the sidebar keeps showing the "running" indicator dot next to a session after everything in that session has finished. The session had two background Bash tasks (started with run_in_background); one was killed (exit 143) and the other completed (exit 0). Verified via ps that no processes from the session remained on the machine — yet the sidebar still showed the session as running many minutes later, across multiple turns.
A second session in the same project that genuinely had a live background watcher showed the dot correctly, so this appears to be stale per-session state rather than a global rendering issue.
What Should Happen?
The running indicator should clear once the session's foreground turn and all its tracked background tasks have reached a terminal state (completed/failed/killed).
Steps to Reproduce
- In a Desktop session, start a background Bash command (
run_in_background: true) that waits indefinitely (e.g. a device-code login flow likegh auth login --web). - Kill that process from a later turn (
kill <pid>), so the background task ends with exit 143; start a second background task and let it complete normally (exit 0). - Let the assistant finish its turn; confirm with
psthat nothing from the session is still running. - Look at the session list in the sidebar: the session still shows the running indicator dot. It persists across subsequent turns.
Impact
Can't trust the sidebar to tell which sessions are actually doing work — a finished session looks busy indefinitely. Possibly related in spirit to #64036 (stale status classification in FleetView) and #72822 (activity header leaking into idle sessions), but this one is the Desktop sidebar dot specifically.
Version
Claude Desktop app 1.17377.2 (macOS)
Operating System
macOS 26.5.2 (Darwin 25.5.0), Apple Silicon
Claude Model
Fable 5 (claude-fable-5)
3 Comments
Independent reproduction on a different machine and a newer Desktop build:
Same symptom: sessions that have fully finished (turn ended, nothing running) keep showing the blinking "running" indicator dot in the sidebar indefinitely. It affects some ended sessions but not others, which matches the stale per-session state theory in the original report.
Additionally, a related variant is observed on the same build: for some ended sessions the dot instead gets stuck in the orange/brown "waiting for approval" color, even though the conversation has ended and there is no pending permission request at all. Filed separately as #74119, since the misclassified color (permission-waiting vs. running) may have a different root cause.
Root-caused; fix is up in the desktop app repo (anthropics/apps#61167, internal).
The desktop tracks CLI background tasks via the
task_started/task_notificationsystem-message bookends on the SDK stream. The CLI only emits the closingtask_notificationsystem message when the completion notification is dequeued at the top of the next turn (idle close). A background task that finishes mid-turn — while a foreground command or the model still holds the turn — has its notification consumed between tool batches instead, delivered only as the inline<task-notification>text in a user message, with no system bookend.The desktop never saw a close for those tasks, so its per-session background-activity flag stayed set, which both keeps the sidebar dot pulsing and exempts the session from the idle teardown that would have cleared it. The only recovery was a 24-hour staleness reaper. Both repro scenarios here (killed via
kill <pid>, and tasks that "delivered their completion notifications before the turn ended") are exactly the mid-turn close path.The fix teaches the desktop to also treat the inline mid-turn notification as a close, so the dot clears as soon as the turn ends. (The sibling-session theory in the report was a red herring — the state is per-session; it was the same leak in both.)
This issue has been automatically locked since it was closed and has not had any activity for 7 days. If you're experiencing a similar issue, please file a new issue and reference this one if it's relevant.