Repository navigation
[BUG] [URGENT!!!] Claude Code is hanging / freezing / stuck on heaps of prompts for 5-20minutes or more. #26224
Description
Activity
Found 3 possible duplicate issues:
- [BUG] Claude Code hangs indefinitely when API streaming connection stalls (no read timeout) #25979
- Claude Code freezes: static spinner, unresponsive input, ignores SIGTERM #20572
- Sessions hang indefinitely in Metamorphosing state with 0 tokens #26157
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
Reacted by nullbio, Adam Rahwane, mimiron01, Guillaume Rybak, Sean Wu, Matej Komel, Alexander Rudaev, Harry Bullough, Konstantin Zolotarev, Kijun Seo and 33 moreThis is happening right now even without 4.6. Requests are just hanging.
Reacted by amengus87, mimiron01, Tomáš Filip, Zhanat Abylkassym, Roman Potapov, Harry Bullough, Konstantin Zolotarev, Matej Komel, Kijun Seo, AbdulMalik Bello and 29 moreI encountered the same issue. I noticed that it gets stuck when executing any Bash tool call.
I found a related discussion here: https://www.reddit.com/r/ClaudeAI/comments/1qm1fb5/claude_code_stuck_for_minutes_before_asking_for/
Setting the ANTHROPIC_DEFAULT_HAIKU_MODEL environment variable to a valid Haiku model resolved the problem for me.I encountered the same issue. I noticed that it gets stuck when executing any Bash tool call. I found a related discussion here: https://www.reddit.com/r/ClaudeAI/comments/1qm1fb5/claude_code_stuck_for_minutes_before_asking_for/ Setting the ANTHROPIC_DEFAULT_HAIKU_MODEL environment variable to a valid Haiku model resolved the problem for me.
What did you set it to? How do I know what a valid Haiku model is? I'm just using the max subscription. Shouldn't that be all Haiku models?
I encountered the same issue. I noticed that it gets stuck when executing any Bash tool call. I found a related discussion here: https://www.reddit.com/r/ClaudeAI/comments/1qm1fb5/claude_code_stuck_for_minutes_before_asking_for/ Setting the ANTHROPIC_DEFAULT_HAIKU_MODEL environment variable to a valid Haiku model resolved the problem for me.
What did you set it to? How do I know what a valid Haiku model is? I'm just using the max subscription. Shouldn't that be all Haiku models?
I just set it to ANTHROPIC_DEFAULT_HAIKU_MODEL=claude-haiku-4-5.
In my case I'm not on a Claude subscription — I'm using a custom model with a third-party LLM API with ANTHROPIC_BASE_URL set, so there's no default Haiku model, which caused the hang.
If you're on an official Claude plan, I think it should automatically pick the latest Haiku version unless there's a bug.
Not sure if the missing Haiku model is what's causing your issue though, just sharing what worked for me!I encountered the same issue. I noticed that it gets stuck when executing any Bash tool call. I found a related discussion here: https://www.reddit.com/r/ClaudeAI/comments/1qm1fb5/claude_code_stuck_for_minutes_before_asking_for/ Setting the ANTHROPIC_DEFAULT_HAIKU_MODEL environment variable to a valid Haiku model resolved the problem for me.
What did you set it to? How do I know what a valid Haiku model is? I'm just using the max subscription. Shouldn't that be all Haiku models?
I just set it to ANTHROPIC_DEFAULT_HAIKU_MODEL=claude-haiku-4-5. In my case I'm not on a Claude subscription — I'm using a custom model with a third-party LLM API with ANTHROPIC_BASE_URL set, so there's no default Haiku model, which caused the hang. If you're on an official Claude plan, I think it should automatically pick the latest Haiku version unless there's a bug. Not sure if the missing Haiku model is what's causing your issue though, just sharing what worked for me!
Okay, I'll give it a go regardless. It's intermittent, so who knows, but fingers crossed, thank you.
I encountered the same issue. I noticed that it gets stuck when executing any Bash tool call. I found a related discussion here: https://www.reddit.com/r/ClaudeAI/comments/1qm1fb5/claude_code_stuck_for_minutes_before_asking_for/ Setting the ANTHROPIC_DEFAULT_HAIKU_MODEL environment variable to a valid Haiku model resolved the problem for me.
What did you set it to? How do I know what a valid Haiku model is? I'm just using the max subscription. Shouldn't that be all Haiku models?
I just set it to ANTHROPIC_DEFAULT_HAIKU_MODEL=claude-haiku-4-5. In my case I'm not on a Claude subscription — I'm using a custom model with a third-party LLM API with ANTHROPIC_BASE_URL set, so there's no default Haiku model, which caused the hang. If you're on an official Claude plan, I think it should automatically pick the latest Haiku version unless there's a bug. Not sure if the missing Haiku model is what's causing your issue though, just sharing what worked for me!
No luck unfortunately.
Crazy that Anthropic doesn't seem to care about this. They're happy to pump out useless features but can't be bothered to actually make the service usable. I'm sure I'm not the only one getting absolutely fed up with their radio silence.
Reacted by Andrey Kolkov, Abdullah Alfaraj, Benjamin Hodgens, Luis Antonio Spader Simon, damifan and Adrian GaburaHi - Thank you for reporting this. Our team is actively investigating this and will update this thread when we know more.
Reacted by Evgheni DjumacReacted by LukeSheppardSDReacted by Adrian GaburaReacted by nullbio, Pär Thernström, Konstantin, Bouke van der Bijl, jeremy-can-code, Daniel Jurma, Hervé Guillon, bmistrapau, Simon, narner90 and 3 morehappens about 50% of time kicking up things from mobile, almost impossible to do consistent work -- thank you for taking a look
Reacted by bmistrapau and Andrey KolkovConfirming the same behavior on macOS (Apple Silicon, 16 GB RAM), Claude Code v2.1.52, Max subscription, Opus 4.6.
Symptom: Tool calls (Bash, Read, Edit) complete but Claude hangs indefinitely — the spinner keeps spinning, no tokens are consumed, and no progress is made. Pressing Escape and re-prompting immediately unsticks it and the same tool call executes fine on retry. Happens intermittently, roughly 1 in 5 tool calls.
Relevant context — memory pressure may be a factor:
I typically run 3-4 concurrent Claude Code sessions. Each session spawns its own set of MCP servers (Docker gateway, excalidraw, etc.). Before trimming, I had duplicate MCP servers across global config (~/.claude.json) and per-project configs (.mcp.json), resulting in 14+ MCP server processes consuming ~570 MB. System was at 85% memory usage, 65% memory pressure, 3.9 GB swap on 16 GB.After deduplicating MCP servers (removing ~400 MB of redundant npx-based processes), the hangs seem less frequent but still occur. This suggests memory pressure may exacerbate the issue but isn't the root cause — consistent with the SSE streaming stall theory others have reported.
Single Max subscription, no custom API setup.
Reacted by nullbio, Daniel Jurma, Andrey Kolkov and starsandheightsDowngrading to previous version of claude code helped. Installed Stable version: 2.1.44.
I have the same problem as @khwerhahn, I downgraded to v2.1.44 but it still hangs with 0 tokens used
I have the same problem as @khwerhahn, I downgraded to v2.1.44 but it still hangs with 0 tokens used
I've tried 2.1.44 and 2.1.45 and still get hangs.
Hi - Thank you for reporting this. Our team is actively investigating this and will update this thread when we know more.
Any news on this error?
102 remaining items
Until this is fixed upstream, here's a drop-in
CLAUDE.mdworkaround that contains the
damage instead of trying to prevent it. It won't stop the stall / leak / fabrication —
nothing user-side can — but it turns "model barrels ahead on corrupted context" into
"model stops and flags it," which is the failure mode you actually want.The idea: a non-coercive instruction telling the model that, when an expected tool
result or user turn is missing, it should emit a rare sentinel token of your choosing
and stop, instead of guessing. It passes normal retries through, doesn't pressure the
model (pressure plausibly contributes to the fabrication), and is a single block you
delete when the bug is fixed.It catches the model at its response boundary, so it won't stop an action already
mid-flight, a silent hang, or plain hallucination — the full list of gaps, plus the
exact snippet, is in the writeup: https://gist.github.com/TJ11000/85cf292f65697921b8b2f607c81844a2Not a fix — just a seatbelt.
Last days claude code is unusable. I got stuck almost on every request and chat. When it works, it works very long on simple tasks. currently stuck in "starting session" for the last 20 minutes.
Follow-up to the seatbelt CLAUDE.md workaround I posted earlier — same "can't fix it upstream, so make it cheaper to deal with" idea, but from the other end.
Where the seatbelt tries to contain the stall while it's happening, this is a tiny after-the-fact detector: a dependency-free Python script that scans your Claude Code
.jsonltranscripts and prints where the stall fingerprints show up — dead-air gaps (model went quiet on its own, no user input in between), near-empty "phantom" turns after a gap, and thecould not be parsedretry markers.It won't catch silent death or plain hallucination, and a long gap can be a healthy slow turn — so it's a tripwire, not proof. It just makes "did this session actually stall, and where?" a one-command question instead of scrolling. Limits are spelled out in the README.
Free, CC BY, no install beyond
python3 stall_scan.py your.jsonl: https://github.com/TJ11000/claude-stall-toolsDetector + seatbelt = measure it / contain it. Still not a fix — just better instruments.
A follow-up on the handling side, in case it's useful to others in this thread.
After a stall, the natural next step is to ask a fresh agent to "continue from where it stopped." I kept finding that reading the stalled transcript to pick up context could wreck the agent that read it — the corruption sits at the end of the transcript (often as a confident "your actual question was X" that isn't what was asked), so reading backward toward it adopts it as truth.
What worked for me: don't read the wreck in the main agent; delegate; read forward (oldest→newest) so the genuine user turns anchor first; and cross-check a backward "find the spot" pass against a forward "judge it" pass — they fail in opposite directions, so agreement is a signal.
Wrote it up (method only, no script this time, honest limits section): https://github.com/TJ11000/claude-stall-tools —
SAFE_READING.md.Companion to the
stall_scan.pydetector in the same repo. Not a fix — just a way to handle the wreckage without spreading it. Defensive handling only.Another handling-side note, in case it's useful here.
Separate from the stall itself, there's a quieter failure I kept hitting in long, otherwise-healthy sessions: the model floats a guess (a number, a name), states it flatly, and a few turns later — when asked to back it up — it defends the guess by inventing a source rather than walking it back. One soft guess snowballs into fabricated support, and every individual turn still reads as confident.
What helped me: have the model wrap unverified values in brackets with a "guess, no source" label, e.g.
[~30% — unverified]. A flat number is a stake the model keeps defending; a bracketed one is already flagged as not-load-bearing, so a later turn has a clean lever to retract instead of fabricating.Wrote it up (convention + a CLAUDE.md snippet, honest limits — it's a hypothesis, not a measured fix): https://github.com/TJ11000/claude-stall-tools —
BRACKET_VALVE.md.Companion to the seatbelt snippet in the same repo. Not a fix — like a vaccine, it won't prevent fabrication, it may reduce how bad it gets. Defensive use only.
Reacted by Andrey KolkovAdded another small companion to the repo —
PRESSURE_LAYERING.md.Same family as the seatbelt and the bracket valve, but a step back: it's about where you put the hard rules in your instructions. Short version — keep the always-loaded base low-pressure (norms the model already knows, stated as understood, not commands it's ordered to obey at every step) and push strict, checkable constraints down to the per-task layer that can actually enforce them.
In a small, informal run on a single non-Claude (fabrication-prone) model, a heavy command-and-prohibition framing was what drove fabricated sources — and the bracket convention only held on top of a low-pressure base. Under a heavy-handed setup the bracket peeled off on the follow-up turn and gave false safety.
Not a fix and not proof — a convention with a small, single-model observation behind it; the limits (incl. not reproduced on a frontier model) are in the file. Sharing in case the framing helps anyone fighting the same fabrication-under-pressure pattern.
https://github.com/TJ11000/claude-stall-tools/blob/main/PRESSURE_LAYERING.md
(Not an engineer — I just tinker with my bikes. Got here by feel from using the thing, and the research turned out to be standing nearby.)
I chased one flavor of this "stuck on thinking" freeze with decrypted packet captures, and on my connection it traced to the IPv6 path to Anthropic, not Claude. On a hung turn the request uploads fine, the server sends
HTTP 200+message_start, then 0 bytes come back until the client times out. Same machine and account, large (>100 KB) requests: over IPv6 no response 15 of 28 (54%); over IPv4, 0 of 20. Forcing traffic onto IPv4 makes it go away.I can't see past the TLS endpoint, so I can't say whether it's Anthropic, Cloudflare, or my ISP — and this only covers the network-path version of the freeze (if your IPv6 is clean, it's something else).
I packaged the fix into a small CLI I wrote: claude-unstuck (MIT).
claude-unstuck doctorruns a couple of real turns over each path and prints your numbers without changing anything;sudo claude-unstuck onforces IPv4 and is reversible. Happy to share raw captures if useful.Deterministic repro for the "stuck generating / queued-but-never-sent" cluster: laptop sleep + network change → the agent session never recovers (isRunning stays held, hadFirstResponse=false)
TL;DR — Close the lid, move to a different network, reopen, let the session resume/compact → the turn spins forever, then the timer/spinner vanish and the turn dies producing no output and no error. After that, the input field only queues messages; nothing is ever dispatched until a full app restart. The renderer stays responsive at ~0 % CPU, so this is a state desync, not a crash or busy-loop. Reproduced 3×, with the app's own logs naming the failure.
Environment
OS: Windows 11 (ARM64 / Snapdragon)
Claude Desktop: MSIX 1.15962.1.0 (arm64), local agent mode (Cowork)
Regression: rock-solid on 1.15200.0; began immediately after the silent auto-update to 1.15962.x on 2026‑06‑28.
Deterministic reproductionHave an active agent-mode conversation.
Sleep the laptop (close the lid).
Move to a different network and wake / log back in.
Resume the conversation (or let the on-resume auto-compaction fire).
→ spinner runs with no streamed tokens → timer & spinner disappear → no response, no error → every subsequent message only queues. Restart required to recover.
Root cause — straight from the app's own main.log (one occurrence, timestamps unedited):09:39:50 [error] [sessions-bridge] Poll error, backing off: net::ERR_INTERNET_DISCONNECTED
09:40:25 [info] Interrupting session local_
09:40:25 [info] [LocalSessionManager] drained 1 deferred send(s) for local_
09:40:25 [info] [LocalSessionManager] isRunning held by unechoed input at result for local_
09:50:03 [info] [LocalSessionManager] isRunning held by unechoed input at result for local_
09:52:06 [info] [CCD CycleHealth] healthy cycle for local_ (123s, hadFirstResponse=false)
09:52:06 [info] [LocalSessionManager] isRunning held by unechoed input at result for local_
What these three signatures mean, in order:net::ERR_INTERNET_DISCONNECTED — the network transition kills the bridge connection. The bridge only "backs off"; it never recovers the in-flight query.
hadFirstResponse=false — the query cycle completes having never received the first streamed response. (This is the user-visible "spinner then nothing.")
isRunning held by unechoed input at result — and this is the actual bug: isRunning is never cleared, even after connectivity returns. The session is permanently pinned to isRunning = true, so the UI shows an eternal spinner and the send pipeline can only queue new input. Note drained deferred send(s) runs — but the flag is immediately re-held, so the queue never actually dispatches.
Why this is high-impactIt silently destroys the in-progress turn (no error surfaced) and forces a full restart.
The trigger — close the lid / change Wi‑Fi — is something virtually every laptop user does daily, so the blast radius is large.
This looks like the root cause, with a deterministic repro, for a cluster of reports that were previously closed as not planned / cannot reproduce specifically because they had no trigger: #11106, #66310, #57497, #61718, and the SSE‑hang #26224. The missing ingredient in all of them is network change during sleep/resume.
Suggested fixesOn a lost stream / network transition, reset isRunning instead of leaving it "held by unechoed input."
Re-establish the stream and drain the send queue once connectivity returns (the drained deferred send(s) path already exists — it just runs while the flag is still pinned).
Surface the dead connection in the UI (a "connection lost / reconnecting" state + retry) rather than an infinite silent spinner with a vanishing timer.
Make Stop/Esc reliably clear isRunning so users can recover without a full restart.
I can share full main.log / claude.ai-web.log and exact timestamps from all three occurrences on request.Workaround that fixed it for me most times: turn on a vpn connection, hit esc in claude code, send the message again and he is back working on things. I don't know why this works. Maybe he's using another API route.
Still happening as of July 2026 (Claude Code CLI + VSC etension, Windows)
Connection is silently killed (probably by idle NAT timeout), CC has no retry on stream stalls. Workaround that fixed it for me: installed Cloudflare's 1.1.1.1 WARP client -> https://1.1.1.1/ -> use the no-login option -> Connect. It tunnels traffic so the connection never appears idle to the router/NAT, so it never gets killed mid-stream.
This is fully fixed for me, seems to have been exclusive to the 4.6 models
I also have not experienced this in some time
Cross-linking for anyone hitting this: I consolidated measurements and a root-cause analysis in #88178.
- 15 stalls in 5 days measured from session jsonl (~4h of dead wall time, one single 51-minute hang)
- Dead pooled connections are never detected — no watchdog on the byte stream
- The desktop app injects
API_TIMEOUT_MS=900000, overriding the only user-side mitigation CLAUDE_BYTE_STREAM_IDLE_TIMEOUT_MS=60000does not mitigate (negative test documented there on 2026-08-22)
Raw gap logs available if useful to the team.
Claude Code has become completely useless due to this issue. I just updated to
2.1.263and it's constantly freezing. No workaround has worked for me ion MacOS X.@kolkov I have new Desktop measurements for comparison with your streaming investigation, consolidated in the September 8 update to #88178.
On September 8, bundled CLI 2.1.260 produced 12 measured waits of 899.012–899.094 seconds ending in
StreamNoResponse. The installed first-response timeout logic accounts for the 899s deadline with Desktop'sAPI_TIMEOUT_MS=900000.The cause of the stalled requests remains unproven. I'm specifically asking for bounded recovery and visible feedback inside Desktop. The update includes an anonymized timestamp CSV and narrows some claims in my earlier report.
Does this look like a remaining first-response deadline case in the class you investigated, or should it be tracked separately?
Preflight Checklist
What's Wrong?
Ever since the release of Opus 4.6 at least, and maybe slightly before (I can't remember exactly when it started), Claude gets stuck "thinking" for ~5-20 minutes, and sometimes even longer. Token usage does not go up during this time, and packet inspection shows it hanging on waiting for SSE events from Anthropic end for the given prompt.
Sometimes this can be fixed by sending a follow up prompt (doesn't matter what it contains), that kicks it back into action and allows the "thinking" prompt to start flowing again. Other times that doesn't work either.
This isn't Claude doing things behind the scenes, it's literally just stuck / blocking, and doing nothing at all.
In most cases, EVENTUALLY, it seems to unfreeze itself, somehow. But it tends to take over 5 minutes, sometimes beyond 20 mins.
Theres a lot of other people complaining of similar problems, and I'm sure it is affecting a very large amount of users, but I haven't seen any evidence to see Anthropic is aware of it.
What Should Happen?
Not freeze.
Error Messages/Logs
Steps to Reproduce
I'm not sure how to trigger it deterministically.
Claude Model
Opus
Is this a regression?
Yes, this worked in a previous version
Last Working Version
No response
Claude Code Version
2.1.38
Platform
Anthropic API
Operating System
Other Linux
Terminal/Shell
Windows Terminal
Additional Information
I'm using WSL2 Ubuntu through Windows terminal.
I've tried deleting my entire Claude Code installation and starting with completely fresh config with no MCPs, skills, etc. Still same problem.
I'm not using a VPN or anything. It was working fine until either the release of Opus 4.6, or just prior to it. That's when I first started having this problem.
I'm using High thinking mode (but again, this is NOT stuck on actually thinking, token and tool usage is not going up at all).
Hi - Thank you for reporting this. Our team is actively investigating this and will update this thread when we know more.