[BUG] [URGENT!!!] Claude Code is hanging / freezing / stuck on heaps of prompts for 5-20minutes or more.
Preflight Checklist
- [x] I have searched existing issues and this hasn't been reported yet
- [x] This is a single bug report (please file separate reports for different bugs)
- [x] I am using the latest version of Claude Code
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).
125 Comments
Found 3 possible duplicate issues:
This issue will be automatically closed as a duplicate in 3 days.
🤖 Generated with Claude Code
This is happening right now even without 4.6. Requests are just hanging.
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.
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.
Hi - Thank you for reporting this. Our team is actively investigating this and will update this thread when we know more.
happens about 50% of time kicking up things from mobile, almost impossible to do consistent work -- thank you for taking a look
Confirming 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.
Downgrading 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've tried 2.1.44 and 2.1.45 and still get hangs.
Any news on this error?
I'm surprised this isn't getting more attention; must only be hitting a small percentage of users? This is impacting my ability to do any sort of long-running task. Yesterday a plan hung for 45m.
I think it's a major outage at all levels
<img width="967" height="744" alt="Image" src="https://github.com/user-attachments/assets/9efe4105-247a-451c-a605-316c161368bf" />
Likely it is a subset of users, but also I think most people that are affected just assume it's normal behavior or an issue on their own end, and of the users that do believe it is an issue with Claude itself, only a subset of them would actually be posting about it on Github. So pretty small surface area I suppose - in terms of getting feedback.
Just happened to me, max subscription, opus 4.6.
i asked claude to create a dummy log file based on the code and it just sat there for a good 5 minute with 77 tokens. asked it to complete now as a follow up and it immediately jumped to completing it. Bizarre
It's happening every single time I try to do anything now.
<img width="651" height="198" alt="Image" src="https://github.com/user-attachments/assets/845217af-4f1a-4e4a-90b3-5fdfc5ba3b7e" />
I start using Claude Code last week and I have the same behaviour most of the time. It hangs very often between 5 and 20 minutes in thinking mode. Sometimes it resumes automatically. But it's frustrating. I'm using most of the time Pro plan, with Claude Sonnet 4.6 model.
Happening for me as well. It's been on the same "Planning" step for days now, across full system restarts. Pro plan, I did hit a limit at one point before it broke, not sure if that caused it at all.
happened to me too
very frustrating
it only happened since yesterday
degraded performance across all my claude code sessions
I found a workaround that got it unstuck, and might point to a fix? I typed something else, like "what's next," and then immediately Cmd-Tabbed away to another app. After a minute I got a notification along the lines of "Allow Claude to exit Plan Mode?" and hovered on it to click "Allow Once," and then it proceeded properly. I wasn't getting that prompt in the app though, so I think it was perpetually waiting for permission to end plan mode but not actually asking for it.
Still happening as of 2026-03-10 on Windows 11 + VS Code extension (Opus 4.6).
Same symptoms: Claude gets stuck in "Thinking"/"Spelunking" state, stop button is completely unresponsive, new messages are ignored. Only fix is killing the session. This has gotten noticeably worse after the latest extension update.
I am seeing this as well. Stuck in thinking with tokens constant. Eventually resumed working after ~10 minutes.
Also seeing the same issue. I try to interrupt the session and continue, but it just keeps hanging. I've tries opening a new session but that just spins too.
Experiencing the same issue constantly on Windows 10 + Git Bash, Claude Code 2.1.74, Opus 4.6.
Symptoms:
Frequency is increasing:
Ironic proof: While writing this very comment, Claude Code hung for 2+ minutes on "Orbiting..." with 0 tokens. Had to ESC and re-submit. The bug reproduced itself while reporting it.
Workaround: ESC → re-submit. Works 100% of the time, confirming the issue is a stale/dead API streaming connection, not a server-side problem.
This really needs a client-side streaming timeout + automatic retry.
This is also happening again here using 2.1.74. I tried rolling back to a version that I knew was working before 2.1.68, but no luck. Still hangs. Tokens get to a certain number stop and time continues.
I had the same issue when it's in plan mode.
What worked for me :
esc > 'continue from above' doesn't seem to work reliably. when it freezes the session, it seems to freeze the f'ing session.
CC in WSL, latest version
This oughta be a high priority issue given the duplicate issues open all addressing the same problem :/
We reverse-engineered
cli.jsacross 12 npm versions and analyzed 1,571 sessions (148,444 tool calls, 8,007 orphaned) to find the root causes of this and related hang/orphan issues.Full analysis with code offsets and fix proposals: #33949
Wow, legends! It's actually ridiculous that the community has to resort to reverse engineering their software because they don't fix high severity bugs... At least open-source it so we can patch things ourselves more easily. Their reasoning is because they think Claude Code is some sort of moat, but it actually is going to have the opposite effect: People will make alternatives out of sheer frustration, causing the market to become more competitive for them. The moat angle only makes sense if you can keep up, otherwise all it does is burn bridges.
Looking from the outside, one can only assume they're focused on building mountains upon mountains of tech debt instead of refactoring their existing codebase using sound SE principles, and putting attention into quality over quantity.
This is my perception of how Claude Code has been going since launch, based on using it every day all day and keeping a close watch on socials and GH issues:
<img width="824" height="918" alt="Image" src="https://github.com/user-attachments/assets/a441ab1f-24fa-4ad2-870d-866c40d087b9" />
Maybe I'm more pessimistic than others, because I'm constantly running into issues and it falls on deaf ears (other than others in the community who put in the work for them, like @kolkov).
Another thing worth pointing out, is that these seems to have coincided with the launch of 4.6 and "fast mode". I feel like infrastructure/dev-ops is part of the issue here. Why are so many connections hanging? No doubt they've introduced some queuing mechanism to give "fast mode" customers (aka themselves, in large part) priority. I'm wondering if that's got bugs in it. Or whatever infra setup they've got going now for 4.6 is causing issues.
While your fixes should exist to begin with, I think it's a bandaid masking the real root of the issue -- whatever is causing all these hangs to begin with. That is something on their end I believe.
Also:
"Important note on testing: We suspect Anthropic internally uses a private API endpoint or prioritized infrastructure that doesn't experience the same latency, timeouts, and stale connections that paying customers face on the public API."
I agree, very likely. Their attitude seems to be: _Well it doesn't affect us, so who cares about our customers. A bug affecting thousands of customers (maybe tens of thousands, maybe millions) and the reputation damage of that? Ah well, works for me. LLM go brrrrr_
When their reputation is trashed, it shouldn't come as a surprise why.
/end rant.
@nullbio Great points, especially about fast mode and infrastructure priorities. Your graph is painfully accurate.
We just checked v2.1.76 (released today) — downloaded from npm, extracted
cli.js, checked all 3 root causes:| Root Cause | v2.1.74 | v2.1.75 | v2.1.76 | Status |
|------------|---------|---------|---------|--------|
| No streaming timeout | ❌ | ❌ | ❌ | 3 releases, still broken |
| ESC queue auto-restart | ❌ | ❌ | ❌ | 3 releases, still broken |
| Non-atomic JSONL writes | ❌ | ❌ | ❌ | 3 releases, still broken |
The code in
insertMessageChain()is character-for-character identical across all three versions (only minified variable names differ). Zero effort on core reliability.Honestly, at this point I'm not even sure these are bugs — they might be features. Think about it:
Maybe we're naively giving free engineering advice to a company that has a business reason not to fix this. Every hung connection that forces a retry is another API call billed to the customer.
Meanwhile, instead of working on our actual projects — like GoGPU, a GPU computing ecosystem in Go — we're spending days reverse-engineering Anthropic's minified JavaScript and writing professional bug reports with fix proposals. For free. That they apparently don't need.
The irony: we're using Claude Code (and paying for it) to debug Claude Code, while Claude Code hangs every 10 minutes. That's some next-level dogfooding.
To add to that — the frustration with Claude Code's reliability actually pushed me to build my own AI development ecosystem: GOCO.AI (codename PUPSEEK).
Written in Go — which turns out to be the ideal choice for this kind of tool: fast startup, low memory footprint, single binary distribution, no
.nodefile leaks, no 12MB minified JavaScript bundles. It supports multiple AI models simultaneously — you can mix Claude, DeepSeek, Kimi, GPT, Gemini in the same conversation or use different models for different tasks (research vs coding vs review). And it doesn't hang, doesn't lose tool results, and ESC actually works.The ecosystem includes:
For everyday tasks we use DeepSeek, Kimi and other affordable models. Opus 4.6 is still the best for large complex projects — but through the raw API, not through Claude Code.
The only thing stopping wider API adoption is cost: Anthropic's API is significantly more expensive than the Max subscription. So we're stuck in a paradox — pay $100-200/month for a broken tool that hangs every 10 minutes, or pay 5-10x more for the raw API to build a tool that actually works.
Either way, Anthropic wins financially. Maybe that's the real business model.
Going on 12+ hours of not being able to get Claude Code (any model) working with Cloud Environment's attached to a Repo. Local environment projects work fine, but any cloud repo fails to get past the thinking stage. Follow up prompting doesn't seem to work and disconnecting/re-authorizing access to Github didn't work.
@legendarysuccess We had a similar issue today — one of our parallel agents got stuck in a 500/529 error loop for hours while two others worked perfectly. Turned out it was stuck on a specific backend instance (same
request_idacross retries = sticky routing).What helped:
/exit→ wait a few seconds →claudeagain. New TCP connection = new backend instanceAlso, Anthropic seems to be updating infrastructure right now — they launched a 2x usage promotion for off-peak hours through March 28, possibly testing new datacenter capacity. Things have been flying for us in the last few hours after weeks of constant stalls.
If fresh sessions don't help, try adding this to
~/.claude/settings.json:This enables a hidden streaming watchdog (30s warning, 60s abort + retry) that's been in the code since February but disabled by default. Details in #33949.
@kolkov Thanks - I'll try adding that - For more details I should clarify I've been having this issue through the Claude Code Desktop app on Windows and via Claude Code on the web. I'm not as savvy when it comes to using Claude Code in terminals.
@legendarysuccess Ah, for Desktop and web the
settings.jsonwatchdog trick won't work — that's for the CLI terminal version only. Desktop/web likely have their own streaming timeout handling (or lack thereof).For Desktop/web, try:
The infrastructure seems to be improving — things have been significantly faster for us in the last 12 hours. Hopefully whatever they're updating will help Desktop/web too.
@kolkov appreciate the help! Hopefully see a resolution here soon.
we run Claude Code agents on scheduled cron jobs and the hanging happens more frequently in long sessions with lots of tool calls. in our case the freeze usually correlates with the agent hitting context limits and the compaction process taking forever. the workaround that helped us most was setting --max-turns to cap how far a session can go, and breaking large tasks into smaller sessions with file-based state handoff. the 5-20 minute hangs specifically seem to happen when the model is trying to process a very large tool result (like a big file read or a long command output).
if it helps debug, we built a tool executor that handles hanging tool calls with timeouts and fallback - the pattern of wrapping each tool invocation with a deadline helped us catch similar freezes early: https://github.com/m13v/fazm/blob/main/Desktop/Sources/Providers/ChatToolExecutor.swift
Environment: Windows PowerShell, Opus 4.6 (1M context), large monorepo
Today: 42 minutes "Tempering..." in Plan Mode with only 2.8k tokens output and 96% context remaining. This is during European business hours (CET).
This is a recurring pattern - during US/EU business hours, Opus becomes practically unusable. Evenings and weekends are significantly faster with the same tasks and codebase.
At Max plan pricing, this latency is not acceptable for professional use. Looking forward to a fix.
As others have noted, it is hanging daily for me now. Symptoms are it's doing some task, the UI is frozen (eg, the time isn't ticking over), doesn't respond to the keyboard, ^C (interrupt), ^\ (quit), SIGTERM. The only way out is SIGKILL.
At the end you can see how strace says it responds to SIGTERM.
@rstuart This is incredibly valuable — first GDB/strace analysis of the hang I've seen. Thank you.
Your data confirms what we've been suspecting: all 6 Bun Pool threads deadlocked on a single futex (
0x6cab64c), with the HTTP Client thread stuck inepoll_pwait2(likely waiting for SSE data).This aligns with our root cause #1 from the source code analysis: the
messages.stream()call has no client-side timeout, and the SSE connection can die silently. Your HTTP Client thread (Thread 4) is likely waiting for IO on a stale SSE socket, and the Bun Pool threads appear to be deadlocked on a shared mutex — possibly related to the HTTP Client state.Workaround that helps
We found a hidden streaming watchdog in the code (exists since v2.1.50, disabled by default):
This enables a 45s warning / 90s abort watchdog (v2.1.79+) that kills dead SSE connections and retries. It significantly reduced our stalls — though it may not prevent this specific deadlock if the mutex contention happens before the watchdog can fire.
What your data reveals about the deadlock
Likely sequence (hypothesis — needs confirmation):
epoll_pwait2futex WAIT— cannot break deadlock, only SIGKILL worksWe also documented 6 Bun crashes + memory analysis
Beyond deadlocks, we've documented 6 mimalloc crashes on Windows (8-24 hour sessions, 10-26 GB committed memory). Full analysis including process memory breakdowns, cascade failures (IDE crashes, system-wide lag), and the hidden watchdog discovery: #33949, #36132.
Also worth noting: your
.nodefile in/tmpis better-sqlite3 native addon — it leaks ~7 MB per Bash tool call. Related: #23095.Can you dig deeper?
Your GDB/strace skills are exactly what this investigation needs. A few things that would be incredibly useful if you can reproduce the hang again:
0x6cab64c? —info proc mappingsin GDB might reveal if it's in mimalloc, JavaScriptCore, or Bun's own codethread apply all bt fullmight show which thread last acquired the mutex (though symbols are stripped)CLAUDE_ENABLE_STREAM_WATCHDOG=1and see if the deadlock still occurscat /proc/<pid>/status | grep Vmto see VmRSS/VmSize/VmSwap during the hang--bare? — v2.1.81 added--bareflag that skips hooks/LSP/plugins, might narrow down the triggerWe're also setting up a dedicated research agent to investigate Bun internals systematically. Your GDB data is the first real look at what happens inside a hung Claude Code process — incredibly valuable.
The elephant in the room: Bun/Ink architecture
After reverse-engineering cli.js across 16 npm versions, documenting 6 mimalloc crashes, and now seeing this deadlock — we believe the current architecture (Bun + Ink/React + mimalloc) is fundamentally unsuitable for a long-running interactive CLI tool:
pstreeshows the bloat clearlyThe fundamental problem isn't the language — it's the architecture. Every Claude Code session spawns a full 21-thread process with its own Bun runtime, mimalloc heap, React/Ink renderer, and HTTP client. Run 7 agents = 7 × 1-6 GB = system collapse. Your
pstreeshows it perfectly: 21 threads per process for what should be a lightweight terminal client.The correct approach is daemon + thin clients: one persistent service process manages LLM connections, sessions, and agent orchestration. Each terminal tab is just a lightweight client that connects to the daemon via IPC. If a client crashes — the daemon keeps working, session is preserved. No 12 GB virtual per tab, no 21-thread mutex deadlocks, no mimalloc accumulation across 7 independent processes.
This is the approach we're taking with our own tool (proprietary, Go-based) — daemon-based architecture where thin clients can work autonomously when the daemon is unavailable, but share resources (LLM pool, sessions, memory) when it's running. One daemon vs. seven 21-thread monsters fighting for the same pagefile.
Anthropic's models are brilliant — Opus 4.6 and Sonnet 4.6 are genuinely the best for coding. The architecture wrapping them needs a fundamental rethink.
According to the pstree and strace investigations that I was also doing since last night, I believe that the same issue (bun stuck on http download sortof) is also affecting the Linux installer (claude-2.1.81-linux-x64 install)
UPDATE: after being stuck for few hours, it actually exited with error:
@kolkov Seriously, can you stop shitting up this thread with your AI-generated analyses which are clearly just there to promote your own AI projects? You're not adding anything to the discussion by pasting unsolicited, AI-generated engineering advice to Anthropic here. Do you think Anthropic engineers don't have access to LLMs??
@rtb11111 Anthropic engineers certainly have access to LLMs. But as practice shows, having access and knowing how to use them properly are two different things.
This is evident from the choice of tech stack (Bun/mimalloc that crashes after 8 hours even in idle, Ink/React for a terminal app that causes the most popular issue in the entire repo with 694 thumbsups), to the implementation (streaming watchdog written in February but hidden behind an undocumented env var for months while 150+ users report hangs daily).
Plenty of new features every release — prompt bar colors, session names, voice mode. Meanwhile, bugs that affect everyone's daily workflow remain unfixed for months, or worse — the fix exists in the code but isn't enabled.
Our "AI-generated analyses" include:
CLAUDE_ENABLE_STREAM_WATCHDOGthat the community is now using as a workaroundIf this is "shitting up the thread" — what exactly have you contributed?
This is an incredibly frustrating issue, it makes Claude Code almost unusable since it began happening to me in the last few days.
Update: Switched from native (Bun) to npm (Node.js) — dramatic stability improvement
After 6 Bun crashes in 4 days, 26 GB commit from 7 processes, IDE crashes, and system deadlocks — we decided to switch back from the native installer (Bun 1.3.11) to the npm package (Node.js v22.17.0). Same cli.js, same settings, different runtime.
Results after first hours on Node.js
Memory — night and day:
| Metric | Bun (native) | Node.js (npm) |
|--------|-------------|--------------|
| Commit per process | 1-15 GB (grows forever) | 300-500 MB (stable) |
| Commit ≈ RSS ratio | Commit 10-15x larger than RSS | Commit ≈ RSS |
| 5 processes total | 26 GB commit | 1.6 GB commit |
| System RAM used | 70%+ (constantly swapping) | 47% (21 GB free) |
| Memory over time | Grows 0.6-5 GB/hour | Flat or decreasing |
Stability:
What still remains (cli.js / server-side):
insertMessageChain()for-loop still non-atomicWhat ALSO disappeared (we thought it was Ink, it was Bun):
Full reset (scrollback changes)) — 316 per session on Bun → 0 on Node.jsThe theory: Bun/mimalloc was THE root cause
We originally identified 3 separate root causes (#33949). But switching runtimes suggests many symptoms may have been one root cause — mimalloc memory corruption:
All of these disappear or dramatically reduce on Node.js/V8.
Recommendation
If you're experiencing crashes, memory bloat, or instability — try the npm install. You lose ~200ms startup time and auto-updates, but gain a runtime that's been stable for 15+ years. The native Bun installer is the default, but the npm package is still fully supported (v2.1.83).
Note: You'll see an "npm deprecated" banner on each launch — it's just a message, ignore it.
It seems to happen when my connection is inconsistent. Similar happens with all these AI chats that rely on SSE with a stable connection, just most of them can recover reasonably quickly when the connection is cut sporadically; Claude Code cannot recover like that for some reason.
Still occurring as of April 2026 (Claude Code in VS Code extension, Windows 11, Opus 4.6)
Experiencing the same hangs today — "Nebulizing" stalls for 4+ minutes with minimal token output. Tasks are not complex (e.g. fetching a build log and diffing it).
Key observation confirming the SSE stall theory: pressing Esc to cancel then typing "resume" causes Claude to respond instantly — proving the model isn't actually thinking, the connection is just stuck. Same finding as @khwerhahn's Feb 24 comment.
This started happening today (April 1, 2026) after not experiencing it previously. Happening intermittently across multiple conversations.
@negatedx Yes, after the source code leak, the scale of the problem was simply a revelation...
https://dev.to/kolkov/we-reverse-engineered-12-versions-of-claude-code-then-it-leaked-its-own-source-code-pij
I'm also being affected, small tasks are just too slow or just hangs indefinitely. I sometimes try
/btwand ask what's going on but the tool says it's about to finish but sometimes it does other it just gives me false statementsCan confirm after version v2.1.89 It is affecting me at reading stage. and even after say
continueit gets stuck there immidiatly.#35773
hello
This is happening also on enterprise environments with LiteLLM.
We are using AWS Bedrock trough LiteLLM and for some specific prompts (I can start the same conversation in different sessions with the same plan, and they all get stuck. But sessions on other repos work) it always gets stuck. LiteLLM doesn't get any request while CC is stuck.
I have been experiencing the same exact thing for over two weeks. The worst are bash tool calls but it gets stuck on just about every turn. It's almost completely useless.
Experiencing the same issue, not just during tool calls. It output some insight and then it gets stuck. I tried to prompt it again, to no avail.
✶ Contemplating… (4m 27s · ↓ 17 tokens)This is unrelated but claude chatbot on browser also completely hangs itself and the browser , and you cant interact with the website while it is hanged when you stop the website and refresh sometimes you can get it to complete the response but i cant get to complete a response using any Opus model , i havent tried using Haiku model but i did not have this problem until recently
Yeah, it is really bad since yesterday. REALLY BAD
Yes I have exact same problem since ~yesterday.
Same here
For the love of whatever the hell you believe in, please fix this s***. I am extremely tired of getting stuck 10 to 30 times a day!!!
I am seriously considering moving to openai codex. It is a vastly inferior product, but at least it is not stalling me 2 to 3 hours everyday.
Check google gemini cli. Turns out I had that thanks to company I work for. My team is using gemini cli exclusively at the moment. claude code is not usable currently.
2026-04-11T20:27:32.431Z [ERROR] API error (attempt 1/11): undefined Connection error.
2026-04-11T20:33:03.950Z [ERROR] API error (attempt 1/11): undefined Request was aborted.
I found more information while claude code debug. It looks like errors with connection to Anthropic API. Claude code also says:
I've switched to Codex until this issue is fixed because it's almost completely unusable. Codex is working really well. To demonstrate just how bad this problem is, here are some stats for one such request to Claude code. As you can see it took 5 hours to complete this request with only 215,000 token consumed. Stats pulled right from Claude.
✻ Brewed for 5h 3m 17s
Token Usage:
Lines of Code Written (new files):
┌─────────────────────────────────────────────┬
│ File │ Lines │
├─────────────────────────────────────────────┼
│ variable.py (backend model) │ 52 │
├─────────────────────────────────────────────┼
│ variables.py (backend API) │ 155 │
├─────────────────────────────────────────────┼
│ integration_config.py (backend API) │ 213 │
├─────────────────────────────────────────────┼
│ variable.ts (frontend types) │ 33 │
├─────────────────────────────────────────────┼
│ integration.ts (frontend types) │ 23 │
├─────────────────────────────────────────────┼
│ useVariables.ts (hook) │ 53 │
├─────────────────────────────────────────────┼
│ useIntegrationConfig.ts (hook) │ 36 │
├─────────────────────────────────────────────┼
│ variables-tab.tsx (settings UI) │ 260 │
├─────────────────────────────────────────────┼
│ integrations-tab.tsx (settings UI, rewrite) │ 200 │
├─────────────────────────────────────────────┼
│ ToolboxNode.tsx (rewrite) │ ~300 │
├─────────────────────────────────────────────┼
│ Total new/rewritten │ ~1,325 │
└─────────────────────────────────────────────┴
Lines of Code Modified (edits to existing files):
┌─────────────────────────────┬
├─────────────────────────────┼
│ AgentBuilder.types.ts │ ~30 lines changed │
├─────────────────────────────┼
│ constants.ts │ ~90 lines added │
├─────────────────────────────┼
│ AgentBuilder.tsx │ ~80 lines changed │
├─────────────────────────────┼
│ settings/page.tsx │ ~15 lines changed │
├─────────────────────────────┼
│ client.ts (API client) │ ~30 lines added │
├─────────────────────────────┼
│ app.py (route registration) │ 4 lines added │
├─────────────────────────────┼
│ models/__init__.py │ 3 lines added │
├─────────────────────────────┼
│ Total edits │ ~250 │
└─────────────────────────────┴
Lines of Code Read: ~2,500 across 25+ files (backend models, routes, runtime, builder, types,
components, settings tabs, constants, hooks, API client)
Files touched: 18 modified/created, 25+ read for context
@alfredxing @alii @chloeanT @cirospaciari @domdomegg @felixrieseberg @k6l3 @lovesegfault @Mic92 @natemcmaster @palcu @tengyifei
Anthropic is incompetent - I'm paying for the highest tier and they haven't been able to respond to my support ticket for two days. Their service is unusable, which is why I cancelled my subscription. Maybe that's the only thing that gets through to them. At least I'll try out the competing tools and maybe I won't go back.
See my comments above: https://github.com/anthropics/claude-code/issues/26224#issuecomment-4230146833
This has been happening constantly this weekend.
Please stop shipping new features we really don't need buddy integration or any of new things and fix your basic workflow first. I am on the MAX plan and due to this i am not even able to utilize my token at full potential.
<img width="1146" height="449" alt="Image" src="https://github.com/user-attachments/assets/987315bb-770d-4961-aa43-11fb731ed6e5" />
Just expressing my frustration too. I've been following this issue for nearly a month, I'm REALLY looking forward to a resolution to this.
I've finally cracked, while I'm sat here waiting for Claude to move for the umpteenth time in the last 3-4 hours, have some screenshots.
<img width="241" height="93" alt="Image" src="https://github.com/user-attachments/assets/5c7325c7-e260-4ab1-8fd1-1d6769515a3f" /><img width="323" height="25" alt="Image" src="https://github.com/user-attachments/assets/51d2efad-ff90-4d85-96d0-1d9f5d5cd79d" /><img width="300" height="41" alt="Image" src="https://github.com/user-attachments/assets/ee341a81-f4e3-4f8b-ac04-c0c2620c8b82" /><img width="239" height="25" alt="Image" src="https://github.com/user-attachments/assets/208d4ff5-3685-4703-9e0a-18a75ba61f85" /><img width="355" height="29" alt="Image" src="https://github.com/user-attachments/assets/bdc9ecec-7bb8-4f52-9301-3b68484ffc2f" />
I keep running into this problem in like half of my claude code sessions this week. I'll wait like 10-20 minutes where it'll be thinking with no change in the quantity of tokens generated, and then suddenly my Claude Pro usage rate limit is hit despite me getting no response from Claude. This hurts Anthropic's bottom line because I'm sure not going to waste extra usage spending on a prompt that has a high probability to just burning credits for half an hour without responding to me. Often restarting claude code makes zero difference on this behavior.
It appears that this is caused by the research or a tool call - The output from a file is too large that it either envelops the context window or overloads the model or something on the backend to cause this buffering/error on Anthropic’s side. I combat this by instructing in the prompt that the file is too large to read in one go, and that it should look at specific lines/sections of the file for changes. This does help in my experience.
So far the workarounds that have worked for me are that I noticed that when claude is provided by a third party like Bedrock, I have never gotten the unlimited thinking glitch in claude code cli. For my conventional claude subscription, it seems that the vscode claude code sidebar plugin hasn't seemed to run into the hanging issue for me yet.
So far we do not need to worry about AI taking over the World, when it can't even finish its thoughts :)
It seems an interim "solution" is to pull the wool over your eyes to try and make you think something is actually happening...
https://github.com/user-attachments/assets/1fc1d420-3c17-4034-b265-0444962179bf
*edit. 30 mins later... this is worst I've ever seen it!
... later today ...
https://github.com/user-attachments/assets/13fdaf40-0968-4ea4-b36b-2d0ffaab151c
🙄
Thank you for the video evidence! very helpful
i had this issue and just solved it (at least for me): https://github.com/anthropics/claude-code/issues/49563#issuecomment-4263801888
it's been two months and this is still happening. they need to use claude to fix it.
In my case the problem is that opus 4.7 and 4.7 1M are not yet recognized by github remote connection (at least according to claude itself) and it keeps giving API errors because of the model, I switched to sonnet and it works smoothly again.
can confirm that this happens on opus 4.7 via bedrock on my side , reverted back to opus 4.6 and iam not facing this problem , iam not familiar with how or if subscribers also have this issue , but it should be something with bedrock and how the api handles the new adaptive thinking for opus 4.7
Adding diagnostic data from a Hetzner dedicated server that may help narrow this down.
Setup: Max 5x, OAuth login, Hetzner dedicated server (AMD Ryzen 5 3600, 12 threads, 62GB RAM, Linux)
Key finding: non-interactive is fast, interactive is slow on the same machine.
claude -p "say hello" completes in 2.3 seconds — normal speed. But interactive sessions get ~0.7 tokens/sec, with simple ls commands taking 1-2+ minutes. The commands themselves never
execute — the API response streaming is what stalls.
The same account on my local macOS machine is fast.
Network is not the issue:
┌────────────────────────┬─────────┬────────────┐
│ Endpoint │ Connect │ First byte │
├────────────────────────┼─────────┼────────────┤
│ api.anthropic.com │ 0.021s │ 0.078s │
├────────────────────────┼─────────┼────────────┤
│ claude.ai │ 0.022s │ 0.087s │
├────────────────────────┼─────────┼────────────┤
│ ping api.anthropic.com │ 20.4ms │ — │
└────────────────────────┴─────────┴────────────┘
Server resources are not the issue:
Both Opus and Sonnet are equally slow.
This aligns with findings in #46652 and #44015 where switching from Max subscription to pay-per-token API on the same machine fixes performance. The issue appears to be in the Max/OAuth
serving path, with datacenter IPs possibly being deprioritized or routed to a slower capacity pool.
The non-interactive vs interactive distinction might be a useful clue — claude -p (single request-response) is fast, while multi-turn streaming sessions are severely throttled from the
same server.
---
You can also link to the related issues by mentioning #46652, #44015, and #47754 (the Cloudflare WAF blocking OAuth from server IPs, which suggests datacenter IP detection is already
happening on this path).
I've taken a video of my experience yesterday (been suffering with this issue for at least the last week - certainly before 4.7 came out).
In this instance, it seems to get stuck with 670 tokens used at about the 30 second mark of the video. At about 9:30 I ask it "Are you doing anything?". At about 10:30 it starts working again and then carries on with the changes.
When it's working ok it shows code changes are happening (because the changes being made scroll by).
I'm using a plain Max Subscription (not bedrock) and logged in using the "Claude account with subscription" option.
I've tried uninstalling Claude (I'm using the Native Install) as well as removing my ~/.claude directory.
https://github.com/user-attachments/assets/13082cd7-98c0-4699-b230-3ea9b0b09986
What has worked for me is to give it ssh access via a key so without a password from your local machine and execute what it needs from local, and that is nearly as fast as any other local project.
Below is the logs from a recent session. From this, it looks like the request is just timing out after 10 minutes and then retrying.
2026-04-22T09:54:37.108Z [DEBUG] [API REQUEST] /v1/messages x-client-request-id=841d7d4a-0321-4999-8a3f-f7d9fe8b3c61 source=repl_main_thread
2026-04-22T09:55:03.119Z [DEBUG] Fast mode unavailable: Fast mode requires extra usage billing · /extra-usage to enable
2026-04-22T09:55:07.107Z [WARN] Slow first byte: no stream chunk 30.0s after request sent (attempt 1)
2026-04-22T09:56:38.891Z [DEBUG] Restarting sleep inhibitor to maintain prevention
2026-04-22T09:56:38.895Z [DEBUG] Stopped sleep inhibitor, allowing sleep
2026-04-22T09:56:38.897Z [DEBUG] Started caffeinate to prevent sleep
2026-04-22T10:00:38.892Z [DEBUG] Restarting sleep inhibitor to maintain prevention
2026-04-22T10:00:38.894Z [DEBUG] Stopped sleep inhibitor, allowing sleep
2026-04-22T10:00:38.896Z [DEBUG] Started caffeinate to prevent sleep
2026-04-22T10:04:37.120Z [ERROR] API error (attempt 1/11): undefined Request timed out.
2026-04-22T10:04:37.154Z [DEBUG] Fast mode unavailable: Fast mode requires extra usage billing · /extra-usage to enable
2026-04-22T10:04:37.746Z [DEBUG] Fast mode unavailable: Fast mode requires extra usage billing · /extra-usage to enable
2026-04-22T10:04:37.760Z [DEBUG] [API REQUEST] /v1/messages x-client-request-id=caf62ecd-cb28-4823-abfe-a9675bd1110e source=repl_main_thread
Anyone have any findings to share on whether this could be VPN related?
<img width="688" height="41" alt="Image" src="https://github.com/user-attachments/assets/843565ad-1682-4c22-b581-4df8a0ff48b0" />
I'm seeing this when I'm not on a VPN.
This is also happening to me all the time now. This is causing real issues for my work. Do we know when this will be fixed?
Sometimes it just freezes for 8 minutes, and then it starts reading files. Now, whenever it thinks for more than 10 minute, I press ESC and resubmit the same prompt. Most of the time, it freezes again, so I have to repeat this several times until, by luck, one attempt finally starts responding.
However, those canceled prompts still count toward token usage. I now use low effort for all models because at least it produces output instead of thinking forever.
This bug is extremely painful. Please fix it, or at least provide a workaround.
I was having a good run with no hangs until just now.
<img width="314" height="134" alt="Image" src="https://github.com/user-attachments/assets/f07c43e0-dc6e-4462-a814-d44b52369929" />
I gave up waiting the first time and prompted it to continue, I still had to wait. It kicked in and completed the task in under 5 seconds after waiting a total of ~18 minutes.
I saw something like this issue was reported as a bugfix. It's not fixed :(
I wish it would not lie. "almost done thinking" just say "waiting for server" or "you're in a queue" or whatever is actually going on.
<img width="418" height="30" alt="Image" src="https://github.com/user-attachments/assets/57780e3a-9dee-4fd8-ab1b-f6407badc548" />
same issue here with new installation, deleting cached files and previous versions etc. nothing is helping.
After losing a lot of time debugging on Dev Mode, downgrading the npm package @anthropic-ai/claude-code, etc., the solution was simply restarting the OS and boom, my Claude Code was back to life.
Rebooting doesn't help for me. To me it seems to be a queue you are placed in when a certain amount of tokens are used for thinking. It always stalls when a round number of tokens are used 10.0k etc
Same issue here, using Sonnet 4.5 with
claude --model claude-sonnet-4-5-20250929does not exhibit this problem.It seems to be connected with "thinking".
I haven't manage to demonstrate this reliably yet, but it might be connected with having large files of readable numeric or non-code data in the working directory.
Same issue here for at least 1 month. I'm just considering using Codex and cancel my Claude subscription since this is simply unusable!
I think the only way to solve this problem is to unsubscribe from Claude and try other AI software.
I haven't run into the issue since I switched to the vscode Claude code sidebar extension. It's nice too because you can expand the thinking and see all the tokens generated in real time, so then you know if it's frozen or not. In the terminal version of Claude code, you really can't tell if it's frozen when it's been thinking for a while.
Something that might shed some more light on this.
I've just been planning a task, I've sent 5 messages discussing the implementation with no delays.
As soon as it came time to write code....
It took 7 minutes and 11 seconds to start using tokens
<img width="615" height="42" alt="Image" src="https://github.com/user-attachments/assets/41466756-f391-40f3-a2c7-86c1d3d3d5fc" />
Wait... now I'm just stunned!
It took 30.6k tokens to read one 24 line file!?
<img width="669" height="203" alt="Image" src="https://github.com/user-attachments/assets/4aff39df-bf59-46f9-b261-1e056e374307" />
Then 50k for two files before it starts writing code!? IconManifest is 14 lines! WTF!?
<img width="598" height="205" alt="Image" src="https://github.com/user-attachments/assets/bf7b70ac-d3ae-476a-b0b0-1a676b8e9b15" />
This was not a complicated task. It just blew roughly 25% of a session on this.
Any update from Anthropic on this delay issue?
To trouble shoot this issue, try to run this simple command in command line:
In my case it didn't work because of the
HTTPS_PROXYenvironment variable with a wrong value.SAME ISSUE HERE:
Environment:
Behavior:
Responses stall mid-stream indefinitely. Interrupting (Ctrl+C) and sending any message — even a single word — causes an
immediate response at normal speed. This is 100% reproducible and has been ongoing for several weeks.
What's been ruled out: network, Mac Mini load, context size, Claude Code version.
The interrupt-and-resend workaround confirms this is a stream stall, not slow inference.
In my case a constantly restarting Spring app was causing it. Claude Code stream stalls for minutes when a Docker container is restart-looping on the host
Environment:
Claude Code 2.1.150 (opus 4.7) on Linux (7.0.3-arch1-2). VLESS-Reality. Project uses Docker Compose with a bridge network. RAM 7 Gb available during repro.
Behavior:
Claude starts streaming a response, emits some tokens, then the stream stalls for several minutes. TCP stays open, no errors logged. Curl requests to api.anthropic.com from the same host stay fast throughout. Stops the moment the looping container is killed.
Claude's explanation:
_A container with restart: always was crashing every ~10 s. Each recreation rewrites iptables/nftables rules and briefly holds the kernel-wide netfilter write lock — stalling all packets, including those on the tunnel interface. Short requests don't notice (single RTT), but a long-lived SSE stream does: VLESS-Reality multiplexes all flows over one TCP connection, so a single retransmit on the tunnel TCP stream blocks every in-flight HTTP stream inside it (TCP head-of-line blocking). The next restart-burst hits before recovery, so the Claude stream stays starved._
+1, still experiencing this on the latest version (macOS, fish shell).
In addition to the general hanging described here, I also hit issue #60194 with 100% reproduction rate - Ctrl+O during a pending permission prompt causes the session to hang every single time.
But even without Ctrl+O, tool calls (Edit, Bash, Write) sometimes just hang with no response. The spinner keeps going but nothing happens. No error, no output. Have to Esc and retry.
This is happening frequently enough that it significantly impacts daily workflow. Would really appreciate a fix.
Adding a data point — same SSE/streaming stall, but on Opus 4.8 and even at low effort, which the existing reports (mostly 4.6/4.7) don't cover.
Environment
claude-opus-4-8Symptoms
test).Thinking… / still thinking with low effortfor 1–5+ minutes. Token count stops increasing during the hang — consistent with the client waiting on SSE events described here.The model's tool call could not be parsed (retry also failed).New data points beyond existing reports
/effort low— lowering effort does not avoid it.[1m]— so it's not specific to the 1M tier (cf. #59092).Ruled out locally
Bug is still here with Opus 4.8. This is getting to the point where it seriously hinders the product. Anthropic, take notice and treat this with the proper urgency
If this is some "hidden" throttling of Max subscription users to force them into going the API token route, that would be very disapointing behavior on Anthropic side
Same bug, sonnet-4.5 on windows.
<img width="671" height="421" alt="Image" src="https://github.com/user-attachments/assets/e00f23ca-bb75-4156-a6c6-dac6764995e7" />
Where the transcript shows "thought for 4s", this was 4 seconds of token usage increasing and output being seen in ctrl+o , followed by several minutes of nothing happening at all.
Since a few days now I have constant stalling on my side too. Tried to reload windows and doesn't seem to help, I need to restart VSC, it seems to work for a few prompts and then goes back to stalling. It's quite disruptive.
Confirming this on macOS with the VS Code extension, on the latest version (2.1.162) — still present in the newest build. Same signature: SSE hang, token counter never advances, intermittent, and the UI never recovers (Stop fails).
Environment: macOS (Darwin 23.6.0); extension builds seen failing: 2.1.159 and 2.1.162 (darwin-x64); CLAUDE_CODE_EFFORT_LEVEL=max, model claude-opus-4-8, permission defaultMode=auto; no MCP servers; no streaming hooks.
Extension log signature when it hangs:
Ruled out locally with measurements: network (0% packet loss; api.anthropic.com first byte ~215–268ms; sustained 60MB download stable at ~9.5MB/s); no VPN/proxy/AV; not conversation size (failing turns were short, no subagents); no MCP; no auto-compaction in one of the episodes.
The abort doesn't seem to be surfaced to the UI, which keeps showing "Thinking" forever while Stop fails with "Query closed before response received" — the query is already dead while the UI still thinks it's streaming. Client request IDs for the aborted /v1/messages calls are available if useful.
Still getting this too, been getting it for months. So frustrating having to kill the task and type "continue" over and over.
I have a similar issue on my end.
I have an i 9 14900 kf, 64GB of ddr5 6000 mhz ram, os this is not a bottleneck on my end. I type Hello claude, it will just sit there, the timer increases but no thinking message, or nothing shows for several minutes, then suddently it thinks and it hsows output. I have also observed this behaviour: Pollinating… (8m 11s · ↓ 31.1k tokens) and it has been stuck like this for 6 minutes.
EDIT: I am also experiencing this weird issue, it just hangs like this ✶ Whirring… (1m 46s) I have no idea on how to fix it. I have tried ctrl+c and saying continue, or just typing a message and deleting it, but nothing seems to solve this weird bug. I have completly reinstalled Claude Code, but it didn't resolve it.
Same here. The task just stuck after running two mcp method. I waited for 10 min but nothing happened🤔.
Same for me on wsl, dont know what to do
It's been happening to me all week. It works well without tool calls (just chatting), but tool calls make it terminate prematurely.
Tool calls (shell script) burned my tokens and left me with nada
Until this is fixed upstream, here's a drop-in
CLAUDE.mdworkaround that contains thedamage 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/85cf292f65697921b8b2f607c81844a2
Not 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.
Added 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 reproduction
Have 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_<id>
09:40:25 [info] [LocalSessionManager] drained 1 deferred send(s) for local_<id>
09:40:25 [info] [LocalSessionManager] isRunning held by unechoed input at result for local_<id>
09:50:03 [info] [LocalSessionManager] isRunning held by unechoed input at result for local_<id>
09:52:06 [info] [CCD CycleHealth] healthy cycle for local_<id> (123s, hadFirstResponse=false)
09:52:06 [info] [LocalSessionManager] isRunning held by unechoed input at result for local_<id>
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-impact
It 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 fixes
On 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.