Preflight Checklist
What's Wrong?
Claude Code intermittently stalls during a session — it stops producing output and appears hung. The status line may show "Thinking..." or a tool status indefinitely. No error is shown. No timeout fires.
The workaround: send another message (either via BTW or just typing something new in the input). This "kick" causes Claude to immediately resume, as if it was waiting on something that the new user input resolved.
This strongly suggests a race condition or dropped event in the message/streaming pipeline. The response was ready (or nearly ready) but the client wasn't processing it until a new user input triggered a re-check or re-poll.
What Should Happen?
Claude should never silently stall. If a response is ready, it should be delivered. If the connection dropped, the client should detect it and retry. If processing is taking unusually long, the status line should update (see #40453). Under no circumstances should user input be required to "unstick" a response.
Steps to Reproduce
This is intermittent and hard to reproduce on demand, but the pattern is consistent:
- Start a Claude Code session (VS Code extension or CLI)
- Give Claude a moderately complex task (multi-step, multiple tool calls)
- At some point mid-session, Claude stops producing output
- Status shows "Thinking..." or last tool status — no progress
- Wait 30-60+ seconds — nothing happens
- Send any message (BTW "are you there?" or just "hello")
- Claude immediately resumes as if nothing was wrong
This happens multiple times per day across sessions of varying length and complexity.
Error Messages/Logs
No errors shown. That's part of the problem — there's no indication anything went wrong.
Environment
| Detail |
Value |
| Claude Code Version |
2.1.87 |
| Claude Model |
Opus 4.6 (1M context) |
| Platform |
Max plan |
| Operating System |
macOS 26.3.1 (Tahoe) |
| Terminal/Shell |
VS Code integrated terminal + standalone terminal |
| Machine |
MacBook Pro, Apple M2 Pro, 16 GB |
| VS Code |
1.113.0 |
| Claude Code Extension |
2.1.86 |
Is this a regression?
Don't know — it's been present for as long as I can remember, across multiple versions. It may have gotten more or less frequent over time but has never been fully absent.
Additional Information
The fact that sending a message immediately unsticks it is the key diagnostic clue. This isn't a slow response or a complex task taking time — it's a stall that resolves the instant the client sends new input. That points to:
- A client-side event loop issue (UI thread not processing incoming stream data until user interaction)
- A dropped SSE/streaming event with no reconnection logic
- A polling mechanism that stops checking until new user activity occurs
- A keep-alive or heartbeat that's missing or not being monitored
Related: #40453 (feature request for more descriptive status lines) would make this bug more visible when it occurs, but this is a separate issue — the stall itself needs to be fixed, not just surfaced better.
Preflight Checklist
What's Wrong?
Claude Code intermittently stalls during a session — it stops producing output and appears hung. The status line may show "Thinking..." or a tool status indefinitely. No error is shown. No timeout fires.
The workaround: send another message (either via BTW or just typing something new in the input). This "kick" causes Claude to immediately resume, as if it was waiting on something that the new user input resolved.
This strongly suggests a race condition or dropped event in the message/streaming pipeline. The response was ready (or nearly ready) but the client wasn't processing it until a new user input triggered a re-check or re-poll.
What Should Happen?
Claude should never silently stall. If a response is ready, it should be delivered. If the connection dropped, the client should detect it and retry. If processing is taking unusually long, the status line should update (see #40453). Under no circumstances should user input be required to "unstick" a response.
Steps to Reproduce
This is intermittent and hard to reproduce on demand, but the pattern is consistent:
This happens multiple times per day across sessions of varying length and complexity.
Error Messages/Logs
No errors shown. That's part of the problem — there's no indication anything went wrong.
Environment
Is this a regression?
Don't know — it's been present for as long as I can remember, across multiple versions. It may have gotten more or less frequent over time but has never been fully absent.
Additional Information
The fact that sending a message immediately unsticks it is the key diagnostic clue. This isn't a slow response or a complex task taking time — it's a stall that resolves the instant the client sends new input. That points to:
Related: #40453 (feature request for more descriptive status lines) would make this bug more visible when it occurs, but this is a separate issue — the stall itself needs to be fixed, not just surfaced better.