Stop button unresponsive — UI stuck in "working" state even when Claude is idle, cannot interrupt in-flight actions
Resolved 💬 5 comments Opened Apr 19, 2026 by PlayoffBlitzDev Closed Jun 11, 2026
What happens
The Claude Code UI gets stuck in "working" state. Two symptoms:
- UI shows working when Claude is idle. The spinner/timer keeps running and the text input shows a stop button even after Claude has finished and is waiting for user input. The only way to send a message is to either (a) click the stop button (which doesn't actually stop anything — see #2) or (b) type while in "working" mode.
- Stop button does nothing. While Claude is actually executing tool calls, clicking stop has no effect. Claude continues through the full sequence until it naturally yields, only responding to the user after the chain completes.
Why this matters
- UX annoyance: user is never clearly in an "idle, ready to type" state
- Safety issue: if Claude starts going down the wrong path (e.g., about to delete/overwrite/deploy to the wrong place), there's no way to interrupt. User has to wait for the whole chain to complete and then correct after the fact.
Reproduction
Consistent in the current session. Happens across a mix of tool calls (Bash, Edit, MCP).
What was tried
- Fully closing Claude Code
- Force-stopping the process
- Relaunching
Bug persists after restart.
Environment
- Claude Code (Windows 11)
- Platform: win32
This issue has 5 comments on GitHub. Read the full discussion on GitHub ↗