[Bug] ECONNRESET on Windows during API stream after first chunk received

Status Open

Maintainer reply None cached

Activity 3 comments · opened Aug 5, 2026

Bug Description
Title: Persistent ECONNRESET during Claude Code streaming responses on Windows — first chunk arrives, then stream resets Environment: - Windows 10/11 - Claude Code v2.1.222 - npm global installation - Reproduced in both the VS Code extension and Claude Code terminal - Claude.ai authentication with an active Max subscription Symptom: Most prompts, including trivial prompts such as “hi”, “what is AI”, and “Say only: OK”, initially fail with: “Unable to connect to API (ECONNRESET)” or: “API error · Retrying in 0s · attempt X/10” Claude Code repeatedly retries. Some requests eventually succeed after multiple retries, but even trivial prompts can take several minutes. One simple response took approximately 3 minutes 39 seconds. The issue began after a Claude Code session was interrupted during a project and a new session was started. Initially, the VS Code extension was affected while the terminal still worked, but the terminal later developed the same problem. Debug evidence: Claude Code was started with: claude --safe-mode --debug api The debug log repeatedly shows this sequence: 1. /v1/messages request is dispatched successfully 2. The API response begins 3. “Stream started - received first chunk” 4. First byte arrives in approximately 1–4 seconds 5. “Stream connection error (ECONNRESET) — retrying streaming” 6. The same behavior repeats across multiple retries This indicates that: - DNS resolution succeeds - HTTPS/TLS connectivity succeeds - Authentication succeeds - The request reaches the Anthropic API - The server begins sending a response - The response stream is then reset shortly after it begins The reset occurs shortly after the first response chunk, rather than after a long idle period. Troubleshooting already performed: - claude doctor reports no installation issues - Claude Code was updated to v2.1.222 - claude auth status confirms that the user is logged in - WinHTTP proxy is set to direct access - No HTTP_PROXY, HTTPS_PROXY, or related proxy environment variables were found - Tested in a clean empty folder - Tested with claude --safe-mode - Safe Mode disabled MCP, plugins, hooks, CLAUDE.md, skills, agents, and other customizations, but the issue persisted - Therefore, MCP, Context7, plugins, hooks, project configuration, and CLAUDE.md are unlikely to be the cause - Tested on both the normal home connection and a mobile hotspot - Fully terminated existing Claude processes and relaunched Claude Code - The issue persisted after restarting Claude Code - Basic curl.exe -v https://api.anthropic.com connectivity succeeds: - DNS resolves - HTTPS connects - Anthropic responds normally with HTTP 404 because GET / is not the API endpoint - This confirms that basic connectivity to the Anthropic API host is available, although it does not fully test Claude Code’s authenticated streaming path Important: The current Claude.ai login belongs to an organization account, and logging out may prevent the user from signing back in immediately. Therefore, the authentication session has intentionally not been deleted or reset. Request: Please investigate whether this may be caused by: 1. A Claude Code v2.1.222 Windows-specific streaming issue 2. A regression in the Claude Code networking client 3. An issue involving the authenticated streaming connection 4. HTTP streaming behavior or connection resets after the first response chunk 5. An account, organization, regional routing, or service-side issue The key diagnostic pattern is: “Stream started - received first chunk” followed almost immediately by: “Stream connection error (ECONNRESET) — retrying streaming” Debug log session ID: 624fcb16-162c-4b27-a111-7b4f664ece4cTitle: Persistent ECONNRESET during Claude Code streaming responses on Windows — first chunk arrives, then stream resets Environment: - Windows 10/11 - Claude Code v2.1.222 - npm global installation - Reproduced in both the VS Code extension and Claude Code terminal - Claude.ai authentication with an active Max subscription Symptom: Most prompts, including trivial prompts such as “hi”, “what is AI”, and “Say only: OK”, initially fail with: “Unable to connect to API (ECONNRESET)” or: “API error · Retrying in 0s · attempt X/10” Claude Code repeatedly retries. Some requests eventually succeed after multiple retries, but even trivial prompts can take several minutes. One simple response took approximately 3 minutes 39 seconds. The issue began after a Claude Code session was interrupted during a project and a new session was started. Initially, the VS Code extension was affected while the terminal still worked, but the terminal later developed the same problem. Debug evidence: Claude Code was started with: claude --safe-mode --debug api The debug log repeatedly shows this sequence: 1. /v1/messages request is dispatched successfully 2. The API…
Note: Content was truncated.

View original on GitHub ↗

3 Comments

toyuvalo · 25 days ago

Corroborating on the same version: v2.1.222 (native install, auto-updated 2026-08-04), Windows 10 Enterprise 10.0.19045, direct Anthropic API over subscription OAuth, no proxy — mid-stream resets after the stream is established, on a connection where DNS/TLS/ping are verifiably clean throughout.

Local transcript evidence (methodology and full numbers in #82028 comment and #84272): ECONNRESET in 68 session files, The socket connection was closed unexpectedly recorded as an API error 15 times, and reset events that hit multiple independent concurrent sessions within seconds of each other — which points at the server/edge side rather than the client machine.

Also flagging for maintainers: this issue currently has no labels — platform:windows + area:core would help it get routed, and given the duplicate-bot's 3-day auto-close policy, it would be a shame for a report this precise (--safe-mode --debug api sequence, first-chunk-then-reset signature) to get folded away before a human reads it. The debug sequence here is the best minimal repro I've seen for this class.

k-furuyama · 25 days ago

Confirming this regression with a different Winsock LSP product, which suggests the problem is not specific to Proxifier.

Environment

Windows 11 x64 (corporate managed PC)
Claude Code 2.1.223, native installer, latest channel — fails 100% of the time
Claude Code, stable channel — works normally
Claude Desktop app 1.25927.0 (003700), build 2026-08-04 — also fails, and Check for Updates offers nothing newer, so the bundled version cannot be changed
Auth: claude.ai sign-in, Team plan
No proxy configured (ProxyEnable = 0, no PAC file, netsh winhttp set to direct)

Third-party Winsock LSP present

netsh winsock show catalog shows two LSPs from MaLion (Intercom Inc.), an IT asset management and PC activity logging product that is widely deployed on managed PCs in Japan. They are layered directly over the TCP/IP stack:

MaLion.FtpLsp.IWat over [MaLion.IWat over [MSAFD Tcpip [TCP/IP]]]
MaLion.IWat over [MSAFD Tcpip [TCP/IP]]

C:\Program Files (x86)\Intercom\MaLion\Isvp\bin\x64\pmilsp.dll
C:\Program Files (x86)\Intercom\MaLion\Isvp\bin\x64\MarFtpLsp.dll

So this reproduces with a second, unrelated LSP vendor.

Symptom

Every prompt, including a bare "hello", fails:

Unable to connect to API (ECONNRESET) · Retrying in 5s · attempt 4/10

Unlike some other reports, retries never succeed here — all 10 attempts fail.

Debug log shows the reset landing in the same millisecond as the first chunk:

[DEBUG] [API REQUEST] /v1/messages x-client-request-id=2c28b144-3238-4632-adbc-ad28d21ac695
[DEBUG] Stream started - received first chunk
[DEBUG] [API:timing] first byte after 1229ms
[WARN]  Stream connection error (ECONNRESET) - retrying streaming (2/10)

Identical across all retries. Request IDs from one session (2026-08-06T02:09Z):

98613bdb-6243-4d76-91a1-b50119c84e84
2c28b144-3238-4632-adbc-ad28d21ac695
86995d7d-8b3c-4ecd-bf39-f6cae907f109
ef89e4ef-12bf-4298-8f43-7a9fbf1768fc

Ruled out

Network path: curl.exe POST to https://api.anthropic.com/v1/messages returns HTTP 401 as expected. TLS handshake succeeds, no certificate errors on any Anthropic domain.
Network environment: a colleague on the same corporate LAN with the same organization account runs the Desktop app normally.
Model: reproduced on both Opus and Sonnet.
Auth / install: re-authentication did not help; claude doctor reports no issues.

Notes

The version boundary matches this issue exactly: 2.1.223 fails, stable works. That is consistent with a regression introduced at 2.1.221.

This is a native (Bun) install, which may connect this to #84194 (bundled Bun HTTP client fails where Node.js and curl succeed).

pjdai · 23 days ago

Adding my own repro, since it matches this issue closely.

Environment
Windows 10/11
Claude Code v2.1.223
npm global installation
VS Code integrated terminal and the standalone Claude Code CLI, both affected

Symptom
Even trivial prompts like hi fail on first attempt with Unable to connect to API (ECONNRESET). Claude Code retries automatically and sometimes succeeds after several attempts, sometimes exhausts all 10 retries. claude doctor hits the same API error when run. The /ide command also intermittently fails with Failed to connect to Visual Studio Code, though this may be a separate local IDE bridge issue rather than the same root cause.

Troubleshooting already performed
curl.exe I https://api.anthropic.com consistently succeeds
A 100MB POST upload test to https://speed.cloudflare.com/__up completed in full with no reset (up=104857600)
Bufferbloat test at waveform.com showed clean results, upload active latency only +4ms
Uninstalled McAfee WebAdvisor entirely and restarted the machine
Added Windows Defender exclusions for the npm global folder and the Node.js install folder
Confirmed GlobalProtect VPN adapter present but disconnected at time of testing
Disabled power management on the wireless adapter
Ran claude auth logout followed by claude auth login, no change
Fresh reinstall of the npm package after a corrupted update left the CLI binaries missing, no change once reinstalled

None of the above affected the failure rate. Given that curl and even a large raw upload to a different host complete without issue, this looks consistent with the client side streaming connection handling described here rather than anything in my local network or security software.

Happy to run claude safe mode debug api and share the log if that would help narrow it down.