[BUG] Claude Code hangs with Unable to connect to API (ECONNRESET) on every prompt — both CLI and in-app, persists across networks and clean reinstall

[empty1990-sys]

Preflight Checklist

• I have searched existing issues and this hasn't been reported yet
• This is a single bug report (please file separate reports for different bugs)
• I am using the latest version of Claude Code

What's Wrong?

Environment:

Claude Code CLI version: 2.1.131 (latest as of report)
Also reproduces in Claude Code inside the Claude Mac desktop app
macOS (Apple Silicon, Homebrew at /opt/homebrew)
Node 22 (Homebrew)

Symptom:
Every prompt — even a single hi — immediately fails with:
Unable to connect to API (ECONNRESET)
Claude Code retries automatically and keeps failing. OAuth login completes in the browser, but the post-auth token exchange returns:
OAuth error: The socket connection was closed unexpectedly. For more information, pass verbose: true in the second argument to fetch()
Network is verified healthy:

curl -v https://api.anthropic.com/v1/messages → HTTP/2 405 (TLS clean, edge: YUL/Montreal)
curl -v https://console.anthropic.com/v1/oauth/token → HTTP/2 405 (TLS clean)
DNS: router (192.168.1.1), no oddities
No proxy env vars (HTTP_PROXY, HTTPS_PROXY, ALL_PROXY all unset)
No VPN, no security software (Little Snitch / LULU / CrowdStrike / etc.)
Reproduces on home Wi-Fi and iPhone cellular hotspot — rules out ISP/router

Other Anthropic services work fine on the same machine and same network:

Regular Claude chat in the Mac app works perfectly
claude.ai in browser works
Direct API requests via curl work

Things tried (none fixed it):

Full app quit + relaunch
Full Mac restart
Sign out / sign in within the Mac app
rm -rf ~/.claude and re-auth from scratch
rm -rf ~/Library/Application Support/Claude/claude-code
Clean reinstall: removed stale /usr/local/bin/claude symlink (Intel-era install from Feb), reinstalled via npm i -g @anthropic-ai/claude-code to /opt/homebrew
Verified which claude → /opt/homebrew/bin/claude, claude --version → 2.1.131
NODE_OPTIONS="--dns-result-order=ipv4first" (no change)
Switched networks (Wi-Fi → cellular hotspot)

Repro steps:

Launch claude in terminal (or open Claude Code in the Mac app)
Send any prompt
Immediately fails with Unable to connect to API (ECONNRESET) and enters retry loop

Note: symptoms match open issues #13657, #27789, and #35094, which describe ECONNRESET in Claude Code while the network and curl are healthy. Adding another reproducer here.

What Should Happen?

I should be able to use Claude Code.

Error Messages/Logs

Steps to Reproduce

Just using Claude Code.

Claude Model

None

Is this a regression?

Yes, this worked in a previous version

Last Working Version

No response

Claude Code Version

2.1.131

Platform

Anthropic API

Operating System

macOS

Terminal/Shell

Terminal.app (macOS)

Additional Information

No response

[github-actions]

Found 3 possible duplicate issues:

1. [BUG] ECONNRESET on every API call — macOS 26 Tahoe, Darwin 25.4.0, ARM64 #56059
2. [BUG] ECONNRESET errors - Unable to connect to API despite healthy network #13657
3. Persistent ECONNRESET (errno=0) on api.anthropic.com/v1/messages?beta=true — fails through all 10 retries #56140

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

[wony0402]

hi I'm a Korean high school student.. Same issue on Mac, Korea
just want to login with my pro claude account.. but something is wrong.
I try lots of thing but claude Al said "The cause of some of the cleanup is a bug in Claude Code v2.1.133. It is an internal code issue that Claude Code has ECONNESET enabled only because curl is reliably connected to api.anthropic.com."
So could you help me?😭😭 I don't know what to do..

this image is repeated..

[seanbonner]

Same issue here.

[AlakbarAbdullayev]

Same pattern — Windows 11
I'm experiencing the exact same ECONNRESET pattern described in this issue. Sharing detailed evidence in case it helps narrow down the root cause.
Environment

OS: Windows 11 Enterprise (build 22631.3085)
Claude Code: Tested on 2.1.78, 2.1.129, 2.1.137, and 2.1.138 — identical failure on all versions
VS Code extension: 2.1.138 (also tested earlier versions, same issue)
Runtime: Bun (native binary), Node.js 22.21.0 for subprocesses
Network: Home WiFi (Keenetic Ultra router, KeeneticOS 4.3.6.3)
No VPN, no proxy, no corporate firewall
Started: Approximately 2 weeks ago (~end of April 2026)

Symptoms

ECONNRESET errors occur mid-session during HTTP/2 streaming responses
Pattern is intermittent: works for 5–30 minutes, then errors begin
After a short pause (1–2 minutes), Claude Code recovers and runs a few requests successfully, then fails again
Even short prompts (e.g. "test") fail once the session enters this degraded state
Fresh sessions in parallel windows work while another session fails — confirms it's session-state related, not a network outage
Frequency during active use: ~12 ECONNRESETs per hour when working continuously

Packet capture evidence (Windows pktmon)
Captured a 3-minute window with pktmon filtered to TCP destination 160.79.104.10:443:

11 inbound packets with [R.] (RST) flag from 160.79.104.10:443 → my client
All 11 RSTs were on different local source ports — meaning 11 separate TCP connections terminated by server side
Each RST followed by 100+ subsequent inbound packets dropped with DropReason: INET: transport endpoint was not found (server continued sending data after RST — classic server-initiated mid-stream termination signature)
Drop totals: 11 RSTs received, 1760 "transport endpoint not found", 880 "Arbitration unhandled"
DropLocation 0xE0004516 / 0xE0004500 — Windows TCPIP stack RST handling (these are acknowledgements of inbound RSTs, not local rejections)

Sample packet:
Direction: Rx
Source: 160.79.104.10:443
Dest: 192.168.1.118:63389
Flags: [R.]
Seq: 539349735
Ack: 413328752
DropReason: INET: received RST
This confirms RSTs originate from Anthropic's IP, not from my machine, router, or any middlebox.
Network is otherwise healthy

ICMP ping to 160.79.104.10: 11092 sent, 11090 received, 0% loss over 2 hours (2 timeouts only)
ICMP ping to 8.8.8.8 (same period): 7.5% loss — but pathping shows loss originates at Google's AS edge (hop 9), not local
TLS handshake: completes in 24–313ms (depending on PoP), real Anthropic cert (issuer: Google Trust Services)
TCP path: 9 hops via NetIX peering to Cloudflare edge, no anomalies in tracert or pathping
curl https://api.anthropic.com/v1/messages works fine, returns expected 401
MTU: 1500 end-to-end clean (DF flag tests at 1472, 1464, 1452, 1424 all pass with 0% loss)

Cloudflare PoP analysis (this might be the key)
Via curl -s https://api.anthropic.com/cdn-cgi/trace, I get different PoPs from different networks:

Home network: PoP = SOF (Sofia), TLS handshake 313ms — ECONNRESET frequent
Different location, same ISP: PoP = SOF (Sofia), similar TLS — no ECONNRESET
Different ISP, same city: PoP = GYD (Baku), TLS 24ms — no ECONNRESET

Same IP (160.79.104.10) reached via different PoPs depending on routing. Only my home connection (routed to SOF) reliably reproduces the failure. Same machine, same Claude Code install — different routing path = different failure rate.
What I've already ruled out (with evidence, not guesses)

TLS MITM: openssl s_client confirms real Anthropic cert, issuer Google Trust Services
Firewall: Windows Defender Firewall is OFF (verified), no third-party AV with active services (sc query shows no Kaspersky/ESET/Bitdefender services running), WFP filters checked — no filters targeting Anthropic
Hosts file: forced IPv4 only for api.anthropic.com, console.anthropic.com, statsig.anthropic.com, claude.ai
TCP keepalive: registry tuned (KeepAliveTime=60000, KeepAliveInterval=1000) + reboot — no effect
MTU: verified clean 1500 end-to-end
HTTP/2 force: NODE_OPTIONS preload of undici Agent with allowH2:true applied for Node subprocesses (per workaround in #5674) — reduced frequency but did not eliminate
Connection pool exhaustion: netstat shows healthy state (2–3 ESTABLISHED, 0 TIME_WAIT accumulation)
WiFi driver: Updated Intel Killer AX1650i from 22.40.0.7 (2021) to 24.40.0.4 (April 2026) — no effect
Router HWNAT (hardware NAT): toggled OFF on Keenetic Ultra — no effect (session lasted slightly longer, then failures returned)
CLI version downgrade: tested 2.1.78, 2.1.137, 2.1.138 — all fail with identical pattern
VS Code extension regression: ruled out — issue persists across multiple extension versions
DNS configuration: dual-stack (IPv4 + IPv6), resolves correctly, hosts file enforced
Bandwidth/saturation: tested with Roblox + YouTube + Claude Code simultaneously vs Claude Code alone — no correlation

What partially helped
HTTP/2 force for Node subprocesses (NODE_OPTIONS preload of undici Agent with allowH2:true) — sessions last noticeably longer before failures begin, but the failures still recur after extended use. Matches the burst pattern described in #41242.
Open questions for the team

Is there a known issue with Cloudflare SOF (Sofia) PoP serving api.anthropic.com that causes long-lived HTTP/2 streams to receive server-initiated RSTs after ~5–30 minutes of activity?
Is there a way to pin or hint traffic to a different/healthier Cloudflare edge for affected regions, even as a temporary workaround?
The fix in 2.1.87 ("fresh TCP connection on retry") does not resolve this for me — once a session degrades, even fresh TCP connections receive RSTs within minutes. Is there a deeper connection-pool/session-state fix being considered?
Could the team confirm whether requests with x-client-request-id from my failed sessions can be looked up server-side to see what the edge logged at the moment of RST? I can provide request IDs if useful.