### Preflight Checklist - [x] I have searched [existing issues](https://github.com/anthropics/claude-code/issues?q=is%3Aissue%20state%3Aopen%20label%3Abug) 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? <h1 id="streaming-v1messages-resets-with-econnreset-after-the-first-chunk-on-windows-system-nod

Streaming `/v1/messages` resets with ECONNRESET after the first chunk on Windows — system Node & undici stream fine, only Claude Code's bundled client fails

Status Closed — duplicate

Reported on v2.1.226

Maintainer reply None cached

Workaround ✓ Mentioned in description ↑

Activity 1 comment · opened Aug 10, 2026 · closed Aug 15, 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?

<html>
<body>
<html><head></head><body><h1 id="streaming-v1messages-resets-with-econnreset-after-the-first-chunk-on-windows-system-node-undici-stream-fine-only-claude-codes-bundled-client-fails">Streaming <code>/v1/messages</code> resets with ECONNRESET after the first chunk on Windows — system Node & undici stream fine, only Claude Code's bundled client fails</h1>
<h2 id="summary">Summary</h2>
<p>On a Windows machine, every model turn in Claude Code fails with <code>API Error: Connection closed mid-response</code>. The debug log shows the stream opens, the first chunk arrives (~1–3 s), then the socket is reset (<code>ECONNRESET</code>); all 10 streaming retries fail the same way. Non‑streaming requests to the same host (<code>api.anthropic.com</code>) succeed, and the same machine's <strong>system Node.js</strong> streams large responses over HTTPS without any problem. The failure is isolated to Claude Code's own bundled (Bun-based) HTTP/TLS client streaming the SSE response from <code>api.anthropic.com</code>. The identical account works with no issue in the Claude cloud.</p>
<h2 id="environment">Environment</h2>
<ul>
<li>OS: Windows 11 (Acer laptop)</li>
<li>Claude Code: <code>2.1.226</code> (npm-global; per docs this installs the same self-contained native binary as the native installer, and does not use system Node at runtime — debug shows <code>bun:ffi loaded</code>)</li>
<li>System Node.js: <code>v24.17.0</code> (used only for the isolation tests below, not by Claude Code)</li>
<li>Auth: Claude subscription (claude.ai)</li>
<li>Model: reproduced with both <code>claude-opus-5</code> and <code>claude-opus-5[1m]</code></li>
</ul>
<h2 id="reproduced-independently">Reproduced independently</h2>
<ul>
<li>The identical symptom reproduces on a <strong>second, separate machine on a different network and internet connection</strong> (different location/ISP). This rules out a single-machine misconfiguration and points to the client — or an account/region-level factor — rather than any local environment.</li>
<li><strong>A workaround that confirms the diagnosis:</strong> routing Claude Code through a local proxy (<code>mitmproxy</code> via <code>HTTPS_PROXY</code>), so the proxy terminates Claude Code's connection on <code>localhost</code> and re-originates the upstream TLS to <code>api.anthropic.com</code> with its own (Python) network stack, <strong>eliminates the resets entirely</strong> — Claude Code then streams normally. This further isolates the fault to Claude Code's bundled client establishing/holding the <em>direct</em> streaming connection to <code>api.anthropic.com</code>, not the network path or the endpoint itself.</li>
</ul>
<h2 id="symptom">Symptom</h2>
<pre><code>API Error: Connection closed mid-response. The response above may be incomplete.
</code></pre>
<p>Representative debug excerpt (repeats identically for retries 1–10):</p>
<pre><code>[API REQUEST] /v1/messages ... source=repl_main_thread
Stream started - received first chunk
[API:timing] first byte after 1016ms
[WARN] Stream connection error (ECONNRESET) — retrying streaming (1/10)
...
[WARN] Stream connection closed (ECONNRESET) after 1 block(s) yielded — finalizing partial response
[ERROR] [engine] turn ended in error: API Error: Connection closed mid-response.
</code></pre>
<p>Startup <strong>non-streaming</strong> requests on the same host/connection (<code>source=quota_check</code>, <code>[Bootstrap] Fetch ok</code>, <code>mcp_servers</code>) all succeed in the same session.</p>
<h2 id="what-works-vs-what-fails-same-machine-same-network">What works vs. what fails (same machine, same network)</h2>

Test | Result
-- | --
curl https://api.anthropic.com/v1/messages | OK (405, as expected)
curl streaming 30 MB from speed.cloudflare.com | OK
Node https.get streaming 30 MB from Cloudflare | OK (30,000,000 bytes)
Node global fetch (undici) streaming 30 MB from Cloudflare | OK (30,000,000 bytes)
Claude Code non-streaming requests to api.anthropic.com | OK
Claude Code streaming model response from api.anthropic.com | ECONNRESET after first chunk (100% reproducible)
Same account/session in Claude cloud (Cowork) | OK

<h2 id="ruled-out-each-tested-and-reproduced">Ruled out (each tested and reproduced)</h2>
<ul>
<li><strong>Network path:</strong> fails identically on home Wi‑Fi, mobile hotspot, and NordVPN (different country).</li>
<li><strong>Cloudflare edge / Node TLS fingerprint:</strong> Node and undici both stream through Cloudflare fine; changing egress via VPN has no effect.</li>
<li><strong>MTU / packet size:</strong> 30 MB streams complete via Node/undici/curl.</li>
<li><strong>Third-party network software:</strong> removed Killer Networking suite; stopped ІІТ "Захист з'єднань" (<code>SC2ClientRegistrar</code>); removed/disabled NordVPN incl. Threat Protection. <code>Get-NetAdapterBinding</code> shows only <code>ms_*</code> filters (no third-party LWF bound to the adapter).</li>
<li><strong>Antivirus:</strong> Windows Defender real-time protection off; Defender Network Protection off.</li>
<li><strong>Network stack:</strong> <code>netsh winsock reset</code> + <code>netsh int ip reset</code> + reboot — no change.</li>
<li><strong>Versions:</strong> latest client (<code>2.1.226</code>) and Node (<code>24.17.0</code>).</li>
<li><strong>1M context:</strong> reproduced with and without (<code>claude-opus-5[1m]</code> and <code>claude-opus-5</code>).</li>
<li><strong>Certificate store:</strong> reproduced with <code>CLAUDE_CODE_CERT_STORE=bundled</code> (debug confirms <code>stores=bundled</code>), so it is not the Windows system cert store / smart‑card (КЕП) client certificates.</li>
</ul>
<h2 id="hypothesis">Hypothesis</h2>
<p>The failure is confined to Claude Code's <strong>bundled HTTP/TLS client</strong> (Bun) streaming the SSE response from <code>api.anthropic.com</code>. On the same machine, system Node's legacy <code>https</code> and undici <code>fetch</code> both stream large responses through Cloudflare without a reset, and Claude Code's own non-streaming requests to <code>api.anthropic.com</code> succeed — so it is not the OS network stack, certificates, third-party software, or the network path. A <code>curl</code> trace to <code>api.anthropic.com</code> showed the server requesting a <strong>TLS renegotiation mid-connection</strong> (<code>schannel: remote party requests renegotiation</code>), which <code>speed.cloudflare.com</code> did not — possibly relevant to why bulk downloads survive but the SSE stream is reset shortly after the first chunk.</p>
<h2 id="reproduction">Reproduction</h2>
<p>Any prompt in an interactive session fails 100% of the time, immediately after the first streamed chunk.</p>
<h2 id="related-issues">Related issues</h2>
<p>#62045, #56711, #51164, #48008, #35094, #67091 (all describe mid-stream <code>ECONNRESET</code> / "Connection closed mid-response").</p>
</body></html>
</body>
</html>

What Should Happen?

No errors like:

API Error: Connection closed mid-response. The response above may be incomplete.

Error Messages/Logs

[API REQUEST] /v1/messages ... source=repl_main_thread
Stream started - received first chunk
[API:timing] first byte after 1016ms
[WARN] Stream connection error (ECONNRESET) — retrying streaming (1/10)
...
[WARN] Stream connection closed (ECONNRESET) after 1 block(s) yielded — finalizing partial response
[ERROR] [engine] turn ended in error: API Error: Connection closed mid-response.

Steps to Reproduce

Any prompt in an interactive session fails 100% of the time, immediately after the first streamed chunk.

Claude Model

Opus

Is this a regression?

I don't know

Last Working Version

_No response_

Claude Code Version

2.1.226

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

Windows Terminal

Additional Information

Environment {#environment}

OS: Windows 11 (Acer laptop)
Claude Code: 2.1.226 (npm\-global; per docs this installs the same self\-contained native binary as the native installer, and does not use system Node at runtime — debug shows bun:ffi loaded)
System Node.js: v24.17.0 (used only for the isolation tests below, not by Claude Code)
Auth: Claude subscription (claude.ai)
Model: reproduced with both claude-opus-5 and claude-opus-5[1m]

Reproduced independently {#reproduced-independently}

The identical symptom reproduces on a second, separate machine on a different network and internet connection (different location/ISP). This rules out a single\-machine misconfiguration and points to the client — or an account/region\-level factor — rather than any local environment.
A workaround that confirms the diagnosis: routing Claude Code through a local proxy (mitmproxy via HTTPS_PROXY), so the proxy terminates Claude Code's connection on localhost and re\-originates the upstream TLS to api.anthropic.com with its own (Python) network stack, eliminates the resets entirely — Claude Code then streams normally. This further isolates the fault to Claude Code's bundled client establishing/holding the direct streaming connection to api.anthropic.com, not the network path or the endpoint itself.

View original on GitHub ↗

This issue has 1 comment on GitHub. Read the full discussion on GitHub ↗