[BUG] Claude Code sustained ~80% ECONNRESET failure rate — March 30, 2026 specifically from Boston Area

Found 3 possible duplicate issues:

1. https://github.com/anthropics/claude-code/issues/35768
2. https://github.com/anthropics/claude-code/issues/13657
3. https://github.com/anthropics/claude-code/issues/39406

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

C:\Users\akhil>ping -f -l 1472 api.anthropic.com

Pinging api.anthropic.com [160.79.104.10] with 1472 bytes of data:
Reply from 160.79.104.10: bytes=1472 time=26ms TTL=57
Reply from 160.79.104.10: bytes=1472 time=15ms TTL=57

Ping statistics for 160.79.104.10:
Packets: Sent = 2, Received = 2, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 15ms, Maximum = 26ms, Average = 20ms
Control-C
^C
C:\Users\akhil>ping -f -l 1473 api.anthropic.com

Pinging api.anthropic.com [160.79.104.10] with 1473 bytes of data:
Packet needs to be fragmented but DF set.
Packet needs to be fragmented but DF set.
Packet needs to be fragmented but DF set.
Packet needs to be fragmented but DF set.

Ping statistics for 160.79.104.10:
Packets: Sent = 4, Received = 0, Lost = 4 (100% loss),

---

Your MTU is exactly 1500 (1472 payload + 20 IP header + 8 ICMP header = 1500). That's perfectly standard Ethernet — no tunnel, no encapsulation overhead, no ISP shenanigans.
So your network is completely clean:

MTU: standard 1500 ✓
Latency: 15-20ms to Anthropic ✓
Packet loss: 0% ✓
DNS/TLS/TCP: all working ✓
Chat streaming: works fine ✓

Your network is definitively ruled out. Add this MTU test to the bug report as the final nail — it proves there's no path fragmentation issue either.
The upload size threshold (28KB pass / 70KB fail) is therefore also server-side — likely their upload service rejecting or timing out on larger multipart bodies under load, not anything in your network path.
You've been more thorough debugging this than most SREs would be. File it and go get some rest.

Every Claude client surface — CLI interactive, CLI -p, VS Code terminal, VS Code extension panel, and Claude Desktop — exhibits ECONNRESET on March 30, 2026. Only the frequency varies. This is a server-side infrastructure issue, not a client bug.

| Channel | ECONNRESET Frequency | Notes |
|---|---|---|
| CLI interactive mode | >80% | Effectively unusable |
| VS Code terminal mode (CLI inside VS Code) | >80% | Same CLI binary, same behavior |
| Claude Desktop chat | ~20% | Intermittent, correlates with longer responses |
| VS Code extension panel (graphical) | Rare but present | Showed up after extended use |
| CLI -p (print mode) | Rare but present | Most resilient, but not immune |
| Claude Desktop file uploads >50KB | ~100% | Size-dependent — 28KB passes, 70KB fails |

Regional Finding: BOS (Boston) Cloudflare Edge Degraded — BLR (Bangalore) Unaffected

We have two offices actively using Claude Code CLI. One in New Hampshire, USA and one in Bangalore, India. The NH office has been experiencing ~80% ECONNRESET failure rate all day (March 30, 2026). The Bangalore office has had zero ECONNRESET failures in the same timeframe, using the same Claude Code version and API key authentication.

Cloudflare Edge Traces

Londonderry, NH, USA — ~80% ECONNRESET rate:

h=api.anthropic.com
ip=<redacted>
visit_scheme=https
colo=BOS
sliver=none
http=http/1.1
loc=US
tls=TLSv1.3
sni=plaintext
warp=off
gateway=off
rbi=off
kex=X25519

Bangalore, India — 0% ECONNRESET rate:

h=api.anthropic.com
ip=<redacted>
visit_scheme=https
colo=BLR
sliver=010-tier3
http=http/1.1
loc=IN
tls=TLSv1.2
sni=plaintext
warp=off
gateway=off
rbi=off
kex=X25519

Key Differences

| Field | BOS (Boston, failing) | BLR (Bangalore, working) |
|---|---|---|
| colo | BOS | BLR |
| sliver | none | 010-tier3 |
| tls | TLSv1.3 | TLSv1.2 |
| ECONNRESET rate | ~80% | 0% |

The sliver=none on BOS vs sliver=010-tier3 on BLR suggests the two edges are on different traffic routing paths or backend pools.

Even though the bot tagged this as a windows specific bug it does not seem limited to windows. It is an infra issue

The ECONNRESET error occurance is reduced by night of 31-March-2026 but it is still there at an HIGH annoyance level.

Still continue to be a very very ugly issue

This seriously burning tokens for me every other call fails half way throught conversation... this is the first time in months that I have seen 20x plan runout of usage by Thursday

API Error: Unable to connect to API (ECONNRESET)
Is there a good solution to this problem? It's seriously impacting progress and wasting tokens.

Finally some hope to see someone else facing this... I have been sending emails to support@anthropic.com as well but no replies.
Some claude interactions claim that this is a NH specific problem. I amnot asking you @daoge88 to reveal your location, but curious if you are in the general area.

As of 4th April I see 1 in 8 prompts face the issue... and te recovery almost always happens if I hit esc and send the same prompt again... TBH I have never seen their built in retry work. I see it drop to 5-6 attempt and out of desparation I hit esc and up arrow and enter and bam it works

I am also facing this issue while trying to use claude-code extension on VS code. I am completely blocked on this and can't use code agent at all (CLI or vs code nothing works).

same problem

For me the issue of ECONNRESET continues to randomly occur through the day...
I have approached the problem from many different angles, consulting different references:

• Analyzed MTUs,
• Sustained pings,
• Disabled IPV6.
• Tried different OS (windows, mac, linux)
• Tried wired vs wifi,
• even tried 5G Hoping my ISP is the problem

In the end I feel it is only Anthropic end point's issue that it abandons some connections with ECONNRESET. Their support is 100% MIA. all I ever got was a bot response telling me that it mat be my firewall issue, which I 100% know is not the case.

Very frustrating as this on issue kills the momentum on otherwise excting projects

Not sure if it helps someone but I found that on one macbook... switching from wifi to wired LAN redused the occurance of this issue significantly... this macbook started producing the ECONNRESET error for extneded durations and it was impossible to do anything for 30 mins and I tried everything including restarting claude CLI, rebooting, turning off IPv6, diabling/enabling network stack. but nothing helped and then I turnd off Wifi and used a USB to LAN dongle and I could at least work... I still get 2-3 drops in every 8 prompts on that machine... I have no exlanations but I felt that other's can try similar tricks and benefit.

I had the same issue today. You can use netsh interface ipv4 show interfaces, and then netsh interface ipv4 set subinterface "index" mtu=1492 store=persistent, replace the "index" with the Idx of the WLAN network. For me it's this PMTUD black hole issue. Hope this helps!

started hitting the issue two days ago (macOS 26.0.1 + CC 2.1.143). The session consistently failed with ECONNRESET on large message. The session worked fine for first few conversations and then got stuck retrying with ECONNRESET error. eventually figured out it was a general upload issue with my mac. A reboot fixed it.

I used https://www.waveform.com/tools/bufferbloat to test download and upload (a simple speed test in google would also work). Before rebooting the bufferbloat upload test got stuck at “warming up"

I was able to majorly reduce my ECONNRESET by swithcing to wired LAN.
I had buy a few USB C to LAN type dongles from Pluggable but all my devices now very very rarely show this issue... it is more like a couple of times in a day.
The difference between WLAN and WIRED is night and day.
HTH

I was able to majorly reduce my ECONNRESET by swithcing to wired LAN. I had buy a few USB C to LAN type dongles from Pluggable but all my devices now very very rarely show this issue... it is more like a couple of times in a day. The difference between WLAN and WIRED is night and day. HTH

Network environment definitely matters here. I still don't understand what triggered the initial upload problem. Funny enough, I tried using Claude Code to help debug it, but as the payload got bigger I quickly ran into ECONNRESET errors.

I have same issue

ECONNRESET on the interactive session-worker SSE stream (/v1/code/sessions/{id}/worker/events/stream). ~90% of requests on home WiFi, ~20% on phone hotspot.
Error is undefined Connection error with no HTTP status, then 11 retries over ~9 min before failing with code=ECONNRESET. Telemetry/OTEL export fails at the same moment (ECONNABORTED) — same edge layer.
I'm on 2.1.153, well past the 2.1.87 fresh-TCP-on-retry fix, so this isn't the stale-client-pool variant — consistent with the server/edge-side theory in this issue.
Request ID for server-log lookup: 4f5a18a2-d834-4f4b-9779-2126076afd65
Direct curl to api.anthropic.com is 100% clean (small, 60KB, and streaming stream:true requests all succeed) — local network is provably healthy, FTTP not CGNAT. Reset only happens inside interactive sessions on the long-lived SSE stream. TCP keepalives reduce frequency but don't eliminate; pkill + --resume recovers.
Environment: Claude Code 2.1.153 (Homebrew), macOS, Opus 4.7 / xhigh, Claude Max (OAuth).

Closing for now — inactive for too long. Please open a new issue if this is still relevant.