[BUG] Session status stuck on "Running" in Code sidebar after work is gone (background-agent orphan / idle-kill / pause) — no terminal lifecycle event, TaskStop finds no task

Summary

In the Claude Desktop Code sidebar, a session's status dot latches on "Running" (visible as a tooltip on hover) and never reconciles to a finished/idle state after the underlying work is actually gone. Nothing is executing — the turn completed, or the embedded CLI child process was torn down — but the sidebar keeps advertising the session as Running indefinitely.

This appears to be a single underlying defect (session/task lifecycle status is not updated when the process is torn down) that surfaces through several already-filed issues. Filing a consolidated report because the individual issues each capture one trigger path, but the root symptom — orphaned "Running" status in the sidebar — is shared.

Environment

• Claude Desktop (macOS), Code mode
• Reproducible across background agents, normal turns interrupted by process exit, and idle-timeout teardown

Steps to reproduce (any one of these triggers it)

1. Background agent orphaned by process exit — launch a background agent/task in a session, then have the app/process exit (or the session's in-process state is otherwise lost) before it completes. The session's dot stays "Running." On relaunch, a completion event never arrives.
2. Idle-timeout kill — leave a session with the tab/window hidden past the idle timeout. The lifecycle manager (WarmLifecycle, ~15 min on Windows; SessionIdleManager, ~5 min on macOS) kills the child process tree, but the sidebar status is not updated — still "Running."
3. Session pause/lock/resume — sleep the laptop / lock the session while a background agent runs. The agent dies with no completion notification; the status remains "Running."

Expected

When the underlying turn/agent/background task completes OR its process is torn down (idle-kill, pause, restart, exit), the session's sidebar status should reconcile to the real state (idle / done / killed).

Actual

The status dot stays "Running" indefinitely for sessions that are demonstrably finished. There is no in-app way to bulk-clear these. Reopening the individual session (re-reading the on-disk transcript) reconciles it, but this is manual and per-session.

Tell-tale that the "Running" state is orphaned rather than live: attempting TaskStop on such a task returns "No task found" — the app cannot find a task to stop because there is none, yet the UI continues to show it active (per #65925).

Related issues (same root symptom, different trigger paths)

• #65925 — Background Agent tasks persist as "running" in /workflows after full process restart; elapsed-time counter keeps incrementing past completion; TaskStop returns "No task found" while UI still shows active; zombie entries accumulate.
• #72851 — Session lock alone (no sleep/quit) kills long-running background tasks; the UI should reflect the killed state instead of continuing to show "running" after teardown.
• #68625 — Windows: run_in_background tasks silently killed after ~15-min idle (WarmLifecycle idleTimeoutMs, timeoutOnHidden); UI still shows "running."
• #63023 — Background agents silently die on session pause/resume with no completion notification and no work recovery.
• #23092 — Desktop idle-timeout teardown (SessionIdleManager) not reconciled with visible session status.

Suggested fix

Treat status as derived from the actual process/task state, not a sticky flag. On every teardown path (turn complete, idle-kill, pause/lock, process exit/restart), emit a terminal lifecycle event that reconciles the sidebar status to idle/done/killed. As a safety net, when a session is opened or the app relaunches, re-derive each session's status from its on-disk transcript rather than trusting the last-written in-memory status. A "Mark all as read / reconcile statuses" affordance would also let users clear accumulated zombies without opening each session one by one.

Impact

The Running indicator is the primary signal users rely on to know "which session needs me." When it is chronically wrong, it is worse than absent — every finished session reads as active, so the signal is untrustworthy and users learn to ignore it.