Claude Code 2.1.221+ on Windows: `Unable to connect to API (ECONNRESET)` on every request, 2.1.220 works (leftover Winsock LSP)

Context

Source(s): https://www.v2ex.com/t/1232198 (fix confirmed by the original poster in the last reply); related upstream report: https://github.com/anthropics/claude-code/issues/84211 Status: reported working by source, not reproduced by us.

Problem

After upgrading Claude Code on Windows from 2.1.220 to 2.1.221 or 2.1.222, almost every request fails with ECONNRESET, even a one-word prompt. The original poster used a third-party Anthropic-compatible provider configured through a config switcher, and it failed both with and without a proxy. Rolling back to 2.1.220 worked. Other users on the same versions had no problem, which made it look like a provider or network issue.

Error (redacted / normalized)

✻ Unable to connect to API (ECONNRESET)
API Error

Unable to connect to API (ECONNRESET) · Retrying in 0s · attempt x/10

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

Applies when

Windows (the upstream report used Windows 11 Pro), Claude Code 2.1.221 and later (the upstream thread reports it still failing on 2.1.235 and 2.1.245), native or npm install, CLI and VS Code extension. Machines that have (or once had) a network accelerator, VPN client, remote-desktop tool, or packet-capture tool that installed a Winsock LSP.

Confirm it is this problem

1. Same machine, same network: npx -y @anthropic-ai/claude-code@2.1.220 works, 2.1.221+ fails → expect: the failure follows the version, not the network. A test the original poster ran with an AI assistant reported 4/4 resets on 2.1.222 within about 11 ms of the first streamed chunk, 0/6 on 2.1.220, and 0 resets from plain Python and Node HTTP clients.
2. In an admin terminal run netsh winsock show catalog → expect: entries that are not Microsoft's built-in providers (per the upstream report, anything outside MSAFD, RSVP, AF_UNIX, Bluetooth and NTDS entries is third-party). The original poster found a third-party DLL (PrxerDrv.dll) on a machine that also had remote-desktop and proxy tools installed (they did not say which tool installed it); the upstream reporter found 22 entries left by an uninstalled network accelerator.

Not this when / boundary

Resets only now and then on long sessions (on any version) are usually provider-side or network instability, not this (our inference). If a plain Python or Node client to the same endpoint also gets reset, the problem is the network or the provider. Turning extended thinking off was suggested in the thread and did not help the original poster; a request-body override in a provider switcher was also suggested, but the original poster did not report trying it.

Root cause

Starting in 2.1.221 Claude Code sends API requests through a different network transport (an AI-generated analysis the original poster posted points to the 2.1.222 changelog note about a new proxy-aware transport; the replier who found the fix described it as the Bun runtime's socket implementation). A third-party Winsock Layered Service Provider sits under every socket on the machine and resets this connection when the first SSE (streamed response) packet arrives (explanation from the replier and the upstream reporter; the upstream issue is still open and no maintainer has confirmed it.) Older versions and plain HTTP clients are not affected. LSPs often stay registered after the program that installed them is uninstalled.

Fix

1. Confirm with the two checks above that it is this problem.
2. Note which VPN, accelerator, remote-desktop, or packet-capture tools you rely on; the next step can disconnect them from the network stack.
3. In an administrator terminal run netsh winsock reset. → expect: a message that the Winsock catalog was reset and a reboot is required.
4. Reboot Windows.
5. Install or update to the latest Claude Code. → expect: requests stream normally. The original poster confirmed it worked after this, and said their remote-desktop and proxy tools still worked afterwards.

How to verify

Start Claude Code and send a short prompt → expect: a normal reply with no ECONNRESET retry lines.

What did not work

Disabling extended thinking (alwaysThinkingEnabled: false) did not help. In the upstream report, disabling IPv6, stopping VPN/proxy services, and lowering the MTU to 1400 had no effect, because the LSP sits below all of them.

Rollback

Reinstall the VPN, accelerator, or remote tool if it stops working after the reset; this re-registers its provider (our inference). Staying on Claude Code 2.1.220 is a stopgap if you can't reset Winsock yet.

Risks

netsh winsock reset needs admin rights and a reboot, and it removes every third-party layered provider, so some VPN, accelerator, security, or remote-access tools may need to be reinstalled or repaired (our inference). Do this on a work machine only if your IT policy allows it; one upstream commenter's layered provider belonged to a centrally managed corporate agent that end users cannot remove. Do not disable your antivirus or security software wholesale to try to fix this (our inference).

Verified scope

Claude Code 2.1.221 to at least 2.1.245 on Windows, Aug–Oct 2026.

Becomes obsolete when

Claude Code's transport works with layered providers present, or claude doctor detects and explains them (both requested in the upstream issue, which was still open when checked).