Conversation stuck showing RUNNING while idle, blocking other conversations

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)._