[BUG] Claude Code 2.1.228 repeatedly fails with ECONNRESET on Windows 11, while 2.1.220 works normally

Status Open
Reported on v2.1.228
Maintainer reply None cached
Activity 7 comments · opened Aug 12, 2026

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?

Claude Code 2.1.228 repeatedly fails with ECONNRESET on Windows 11, while 2.1.220 works normally

Summary

Claude Code 2.1.228 repeatedly encounters streaming connection errors on Windows 11:

API error · Retrying in 0s · attempt 2/10

The debug log shows:

[WARN] Stream connection error (ECONNRESET) — retrying streaming (1/10)
[WARN] Stream connection error (ECONNRESET) — retrying streaming (2/10)
[ERROR] Error in API request: Request was aborted.
[DEBUG] [engine] turn ended in error: [ede_diagnostic] turn aborted (aborted_streaming) stop_reason=null

Downgrading Claude Code from 2.1.228 to 2.1.220 immediately fixes the problem without changing any Windows, VPN, network, or Claude configuration.

This looks like a regression or Windows-specific networking/streaming compatibility issue introduced in newer Claude Code versions.

Environment

  • OS: Windows 11
  • Architecture: x64
  • Claude Code installation: Native
  • Problematic version: 2.1.228
  • Working version: 2.1.220
  • Claude Code path:
C:\Users\caohu\.local\bin\claude.exe

Claude Code doctor output on the problematic version:

Running: native (2.1.228)

Commit: 4a2077e9c396

Platform: win32-x64

Path: C:\Users\caohu\.local\bin\claude.exe

Config install method: native

Search: OK (bundled)

Auto-updates: enabled

Auto-update channel: latest

Last update attempt: success → 2.1.228 (2026-08-12)

No installation issues found.

Network Environment

I am using Astrill VPN on Windows 11.

However, basic HTTPS connectivity to the Anthropic API appears stable.

I ran the following test 20 consecutive times:

1..20 | ForEach-Object {
    curl.exe -sS -o NUL `
      -w "HTTP=%{http_code} connect=%{time_connect}s total=%{time_total}s`n" `
      https://api.anthropic.com/v1/messages

    Start-Sleep -Seconds 1
}

All 20 requests successfully reached the Anthropic API:

HTTP=405 connect=0.436015s total=1.183623s
HTTP=405 connect=0.173342s total=0.574326s
HTTP=405 connect=0.221761s total=0.842569s
HTTP=405 connect=0.265723s total=1.348796s
HTTP=405 connect=0.175318s total=0.779701s
HTTP=405 connect=0.222816s total=1.441775s
HTTP=405 connect=0.361877s total=1.204618s
HTTP=405 connect=0.218957s total=0.570133s
HTTP=405 connect=0.188847s total=0.792700s
HTTP=405 connect=0.173845s total=0.567013s
HTTP=405 connect=0.219641s total=0.610635s
HTTP=405 connect=0.295764s total=1.513616s
HTTP=405 connect=0.417071s total=1.016410s
HTTP=405 connect=0.446210s total=1.053381s
HTTP=405 connect=0.289422s total=1.087488s
HTTP=405 connect=0.337751s total=0.930619s
HTTP=405 connect=0.271860s total=1.271368s
HTTP=405 connect=0.420393s total=1.726494s
HTTP=405 connect=0.308999s total=0.985947s
HTTP=405 connect=0.177791s total=0.951895s

The 405 responses are expected because this test sends a GET request to /v1/messages.

The important point is that there were:

  • no connection resets
  • no TLS failures
  • no DNS failures
  • no timeouts
  • no curl network errors

Debug Log

Claude Code debug logging shows that the failure specifically occurs during streaming:

2026-08-12T08:27:14.415Z [WARN] Stream connection error (ECONNRESET) — retrying streaming (1/10)

2026-08-12T08:27:17.938Z [WARN] Stream connection error (ECONNRESET) — retrying streaming (2/10)

2026-08-12T08:27:21.891Z [ERROR] Error in API request: Request was aborted.

2026-08-12T08:27:21.893Z [DEBUG] [engine] turn ended in error: [ede_diagnostic] turn aborted (aborted_streaming) stop_reason=null

2026-08-12T08:27:24.882Z [ERROR] Error in API request: Request was aborted.

2026-08-12T08:27:24.883Z [DEBUG] [engine] turn ended in error: [ede_diagnostic] turn aborted (aborted_streaming) stop_reason=null

There are also unrelated startup log messages such as:

MCP server "ide" Connection failed: WebSocket is not open. Cannot start transport.

But the actual Claude API failure consistently corresponds to:

Stream connection error (ECONNRESET)

Steps to Reproduce

  1. Use Windows 11 x64.
  2. Install/run Claude Code 2.1.228 using the native installer.
  3. Start Claude Code:
claude
  1. Send a normal prompt that requires a streamed response.
  2. Claude Code starts retrying:
API error · Retrying in 0s · attempt 2/10
  1. Debug logs show:
Stream connection error (ECONNRESET)
  1. Downgrade Claude Code to 2.1.220:
& ([scriptblock]::Create((irm https://claude.ai/install.ps1))) 2.1.220
  1. Run the same Claude Code session/network environment again.

The issue disappears immediately.

Expected Behavior

Claude Code should maintain the streaming connection and return responses normally.

Actual Behavior

On Claude Code 2.1.228, streaming connections are intermittently or repeatedly reset with:

ECONNRESET

Claude Code then retries until the request eventually fails or is aborted.

Regression

This appears to be a version regression.

Claude Code 2.1.228

Stream connection error (ECONNRESET)
API error · Retrying...

Claude Code 2.1.220

Works normally on the same:

  • Windows 11 machine
  • network connection
  • VPN node
  • Anthropic account
  • project
  • terminal
  • Claude configuration

No network or operating system configuration was changed between the failing and working tests.

The only change was downgrading:

2.1.228 → 2.1.220

After downgrade, Claude Code immediately started working normally again.

Additional Context

I had previously experienced similar ECONNRESET behavior on newer Claude Code versions. Downgrading to the stable/older version resolved the issue.

Claude Code later auto-updated to 2.1.228, and the same problem returned.

After manually downgrading again to 2.1.220, the issue disappeared again.

This makes the Claude Code version itself a strong variable in reproducing the problem.

It may be related to the HTTP/streaming implementation used by newer Claude Code builds on Windows, potentially exposed more easily when using a VPN/tunnel network interface.

Please let me know if additional debug logs, packet captures, or network diagnostics would help investigate this regression.

What Should Happen?

Claude Code should maintain the streaming connection and return responses normally.

Error Messages/Logs

Steps to Reproduce

Use Windows 11 x64.
Install/run Claude Code 2.1.228 using the native installer.
Start Claude Code:
claude
Send a normal prompt that requires a streamed response.
Claude Code starts retrying:
API error · Retrying in 0s · attempt 2/10
Debug logs show:
Stream connection error (ECONNRESET)
Downgrade Claude Code to 2.1.220:
& ([scriptblock]::Create((irm https://claude.ai/install.ps1))) 2.1.220
Run the same Claude Code session/network environment again.

The issue disappears immediately.

Claude Model

None

Is this a regression?

Yes, this worked in a previous version

Last Working Version

_No response_

Claude Code Version

Claude Code 2.1.228

Platform

Anthropic API

Operating System

macOS

Terminal/Shell

Terminal.app (macOS)

Additional Information

_No response_

View original on GitHub ↗

3 Comments

lenny-eng · 18 days ago

Same issue. since last thursday the 6th. worked fine until last Thursday, ECONNRESET on every request, reinstalled clean, restarted PC, disabled Malwarebytes, no support ticket reply yet

lenny-eng · 18 days ago

Claude code finally responded. it does that intermittently.

I pulled the real error out of the log. This is the specific thing that's failing, in plain terms:

[ERROR] Connection error details: code=ECONNRESET
[ERROR] API error x-client-request-id=345308ee-7497-4232-b558-a673f5af7075
(give this to the API team for server-log lookup)
ECONNRESET = the connection is opening fine, then getting forcibly killed mid-request. Notice what it is not: there's no 401/403 (that would be auth/login), no 429 (rate limit), no 500/529 (server overload). The socket just gets reset. The client tries token-counting, fails, streams, gets reset, retries 10 times, falls back to non-streaming, and still gets reset. That's why re-logging-in didn't help — it was never an auth problem.

Two things come out of this, and both are actionable:

  1. You now have real leverage for support

Your tickets have been "it doesn't work." Now you can give them something an engineer can look up directly. Send this, exactly:

Claude Code fails on every request with code=ECONNRESET ("socket connection closed unexpectedly"). Reproduced on two separate networks (home ethernet + cellular hotspot), on a fresh session with a plain "hi", clock accurate, re-authenticated. Please look up server logs for x-client-request-id 345308ee-7497-4232-b558-a673f5af7075 (2026-08-11 20:25 UTC). The client log explicitly flags this ID "for the API team for server-log lookup."

lenny-eng · 18 days ago

OMG... I think this worked. ...

  1. One machine-side fix we haven't tried — and it fits the symptom

Here's the puzzle: ECONNRESET that survives a network change (home and hotspot both failed) points at the Windows TCP/IP + Winsock stack itself — that's the one component that travels with the machine regardless of which network you're on, and a corrupted stack produces exactly this intermittent reset. We've reset your token and your router but never the OS network stack.

Open PowerShell as Administrator (right-click Start → "Terminal (Admin)" or "Windows PowerShell (Admin)"), run these, then reboot:

netsh winsock reset
netsh int ip reset
ipconfig /flushdns
netsh winsock reset rebuilds the Winsock catalog (the most likely culprit — it's where a corrupted or leftover layered-service entry silently kills sockets).
The reboot is required for it to take effect.
Then reopen Claude Code and send "hi."

Showing cached comments. Read the full discussion on GitHub ↗