Conversation stuck showing RUNNING while idle, blocking other conversations

Status Fixed / completed

Maintainer reply None cached

Activity 3 comments · opened Jul 1, 2026 · closed Aug 25, 2026

Summary

A conversation keeps showing RUNNING status in the UI even when it is idle and nothing is actually executing. The stuck-RUNNING session appears to hold a concurrency slot and affects/crowds out other conversations, which then cannot run.

Environment

Claude Code desktop app, Windows 11
Model: Claude Opus 4.8

Symptoms

A conversation displays RUNNING even though it is idle / awaiting user input — no generation and no tool call is in progress.
While a session is stuck in this state, other conversations are affected: they appear blocked or crowded out and won't start.
Recovering requires archiving the stuck conversation.

Additional context (possibly related root cause)

During the affected session there was a prolonged (~40 minute) backend outage in which every Bash tool call returned:

claude-opus-4-8 is temporarily unavailable, so auto mode cannot determine the safety of Bash right now. Wait briefly and then try this action again.

i.e. the tool-safety classifier was unavailable. Read-only commands were exempt and still ran; write commands were blocked the whole time, and it also flickered (a read would succeed, the next write would fail). To wait out the outage the agent used scheduled wake-ups / retries.

It is plausible that scheduled wake-ups, or a tool call left in-flight during the classifier outage, leaves the session in a RUNNING state that never clears — and that this stuck state is what consumes the slot affecting other conversations.

Expected behavior

An idle conversation (awaiting user input, no active generation or tool call) should not show RUNNING.
A stuck/idle session must not consume resources that block or crowd out other conversations.

Impact

User is blocked from running other conversations and must archive the stuck one to recover.

---
_Reported on behalf of a Claude Code user (via the agent, at the user's request)._

View original on GitHub ↗

3 Comments

github-actions[bot] · 2 months ago

Found 2 possible duplicate issues:

This issue will be automatically closed as a duplicate in 3 days.

If your issue is a duplicate, please close it and 👍 the existing issue instead
To prevent auto-closure, add a comment or 👎 this comment

🤖 Generated with Claude Code

Kenji0322 · 1 month ago

Same symptom here on Windows 11 desktop app.

Additional data point that may help narrow down the root cause:

Queried the session-management API directly (list_sessions) and confirmed the backend already reports isRunning: false for the affected sessions.
Despite that, the sidebar still shows the "Running" status indicator for those sessions.
A full app restart does NOT clear the stale indicator — the mismatch persists across restarts.
The only session correctly shown as running was one genuinely in-progress task; other idle/completed sessions were the ones stuck.

This suggests the stale indicator is a pure client-side rendering/cache issue, decoupled from the actual session state the backend already has correct — restart doesn't invalidate whatever cache the sidebar is reading from.

Recovery: had to archive the affected sessions to clear them from the active view.

wshallwshall · 23 days ago

Filed #84868, which appears to be the inverse symptom of this one — cross-referencing since together they suggest the state tracking is unreliable in both directions rather than biased one way.

This issue: stuck showing RUNNING while idle.
#84868: reported not running while demonstrably alive — measured as isRunning: false on a session with lastActivityAt two minutes prior, which answered a message immediately afterward.

The asymmetry in consequences is worth noting. A false RUNNING is loud: it blocks work and gets noticed and reported, as here. A false not-running is silent — it reads as an all-clear, so callers act on it and never learn they were wrong. In a multi-session setup it caused a session to skip announcing its work to every peer, and it is one inference away from reclaiming another session's lock on the belief that the holder had exited.

If both are the same underlying state tracker, the fix worth prioritising is probably representing "unknown" explicitly, since neither direction is currently distinguishable from a confident answer.