[BUG] Sidebar shows "Running" for a session that has already completed

Status Fixed / completed
Reported on v2.1.209
Maintainer reply None cached
Activity 0 comments · opened Jul 18, 2026 · closed Jul 20, 2026

Preflight Checklist

  • [x] I have searched existing issues and this hasn't been reported yet
  • [x] This is a single bug report (please file separate reports for different bugs)
  • [x] I am using the latest version of Claude Code

What's Wrong?

Description

In the session list sidebar, a session's status dot/tooltip showed "Running" even though the session itself had already finished — its own final message stated the work was complete and listed the completed items.

The two surfaces of the app disagree about session state: the sidebar's status indicator and the session's own last message.

Steps to reproduce

  1. Run a session to completion, where the final assistant message clearly states the session/task is done.
  2. Without navigating into that session, look at it in the sidebar session list while working in a different session.
  3. Observe the sidebar status indicator/tooltip still reads "Running."
  4. Open the session — its content confirms the work already finished.

Expected behavior

The sidebar status indicator should reflect the session's actual current state. Once a session's final turn completes, the sidebar should update to a non-running/idle state, not continue showing "Running."

Actual behavior

The sidebar continued to show "Running" for a session whose own transcript showed it had already completed all its work, causing confusion about whether the session still needed attention.

Additional context

This looks like the sidebar's running/idle indicator may be driven by a separate cached status signal that isn't reliably cleared when a session's last turn finishes, rather than being derived from the session's actual current state.

What Should Happen?

The sidebar status indicator should reflect the session's actual current state. Once a session's final turn completes, the sidebar should update to a non-running/idle state, not continue showing "Running."

Error Messages/Logs

Additional context

Log evidence from AppData\Roaming\Claude\logs\main.log for the affected session (internal id local_978eccc1-9eff-4e8b-9e0e-50a0c78ab749):

13:42:22 [info] [CCD] Warming session local_978eccc1-9eff-4e8b-9e0e-50a0c78ab749
13:42:23 [info] [CCD] Session local_978eccc1-9eff-4e8b-9e0e-50a0c78ab749 warmed successfully in 843ms
13:42:35 [info] [WarmLifecycle:session] Starting idle timeout for local_978eccc1-9eff-4e8b-9e0e-50a0c78ab749: 900s
13:57:35 [info] [WarmLifecycle:session] Idle timeout reached, disconnecting local_978eccc1-9eff-4e8b-9e0e-50a0c78ab749
13:57:35 [info] [CCD] Pausing session local_978eccc1-9eff-4e8b-9e0e-50a0c78ab749 (idle_timeout)
13:57:36 [info] Session local_978eccc1-9eff-4e8b-9e0e-50a0c78ab749 query iterator completed

No further log entries exist for this session after 13:57:36. The sidebar still showed "Running" as of ~14:54 (nearly an hour after the idle-timeout pause), suggesting the WarmLifecycle idle-timeout/pause path does not notify the sidebar's status indicator.

Steps to Reproduce

  1. Start a session and let it run to completion (its final message confirms the work is done).
  2. Leave the session open/idle without navigating away or interacting further.
  3. Wait roughly 15 minutes — the app auto-pauses the session on an idle timeout (confirmed in logs: "Starting idle timeout ... 900s" followed by "Idle timeout reached, disconnecting" and "Pausing session (idle_timeout)").
  4. Do not reopen that session — just observe it from the sidebar/session list while working elsewhere.
  5. The sidebar status indicator/tooltip still reads "Running," even 45-60+ minutes after the idle-timeout pause occurred, with no further log activity for that session.

Claude Model

Not sure / Multiple models

Is this a regression?

I don't know

Last Working Version

_No response_

Claude Code Version

Claude Code CLI: 2.1.209

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

PowerShell

Additional Information

Log evidence from AppData\Roaming\Claude\logs\main.log for the affected session (internal id local_978eccc1-9eff-4e8b-9e0e-50a0c78ab749):

13:42:22 [info] [CCD] Warming session local_978eccc1-9eff-4e8b-9e0e-50a0c78ab749
13:42:23 [info] [CCD] Session local_978eccc1-9eff-4e8b-9e0e-50a0c78ab749 warmed successfully in 843ms
13:42:35 [info] [WarmLifecycle:session] Starting idle timeout for local_978eccc1-9eff-4e8b-9e0e-50a0c78ab749: 900s
13:57:35 [info] [WarmLifecycle:session] Idle timeout reached, disconnecting local_978eccc1-9eff-4e8b-9e0e-50a0c78ab749
13:57:35 [info] [CCD] Pausing session local_978eccc1-9eff-4e8b-9e0e-50a0c78ab749 (idle_timeout)
13:57:36 [info] Session local_978eccc1-9eff-4e8b-9e0e-50a0c78ab749 query iterator completed

No further log entries exist for this session after 13:57:36. The sidebar still showed "Running" as of ~14:54, ~45+ minutes after the idle-timeout pause, suggesting the WarmLifecycle idle-timeout/pause path does not notify the sidebar's status indicator.

View original on GitHub ↗