[BUG] 2.1.221+ fails with ECONNRESET / "Connection closed mid-response" when a third-party Winsock LSP is present; no diagnostic points to the cause

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?

Summary

On a machine with an orphaned third-party Winsock LSP in the socket path,
Claude Code 2.1.220 worked normally while 2.1.221 and 2.1.222 failed on
essentially every request. Removing the LSP fixed 2.1.222 completely.

The client is not at fault for the reset itself. The problem is that the
failure is silent and misdirecting: the only signal is a generic connection
error, which points users at their network, their ISP, or Anthropic's API —
none of which were involved.

Environment

• Claude Code 2.1.220 (working) vs 2.1.221 / 2.1.222 (failing)
• Install method: native, Windows 11 Pro 26200
• Root cause: leftover Winsock LSP from an uninstalled network accelerator

(22 catalog entries, 32-bit + 64-bit chains, DLL injected into every process)

Symptoms

• Unable to connect to API (ECONNRESET) · Retrying in 0s · attempt x/10
• API Error: Connection closed mid-response. The response above may be incomplete.
• Most sessions produced zero assistant messages before dying.

Evidence that isolated it

| Test | Result |
|------|--------|
| 2.1.220 vs 2.1.221/2.1.222, same machine & network | 220 fine (694 assistant msgs, 0 errors) / 221+ ~100% failure |
| Second Windows PC, same Wi-Fi, 2.1.222 | No problem at all (no LSP installed) |
| Disable IPv6 on the adapter | No effect |
| Stop VPN / proxy services | No effect |
| Lower MTU to 1400 | No effect |
| Remove the Winsock LSP (netsh winsock reset) + reboot | Fixed |

The LSP operates below all of the above, which is why every other mitigation failed.

Requests

1. Have claude doctor detect and warn about non-Microsoft Winsock LSP

entries. On Windows this is one command:
netsh winsock show catalog
Anything outside MSAFD / RSVP / AF_UNIX / Bluetooth / NTDS is third-party
and sits in the path of every socket.

1. Make the connection error distinguish "reset mid-stream" from "cannot

connect", and hint that local network filtering (LSP, VPN, TLS-inspecting
AV) is a possible cause. The current message sends users chasing their ISP.

1. Note in the changelog when networking behaviour changes between versions —

the 2.1.220 -> 2.1.221 change was invisible, so there was no reason to
suspect the client at all.

Note

LSPs are deprecated by Microsoft but remain common on Windows machines that
have ever had a game accelerator, VPN client, or packet-capture tool
installed — including ones that were uninstalled, since LSP deregistration
is a separate API call that many uninstallers skip.

What Should Happen?

Two things.

1. Claude Code should not fail silently in this environment. If it cannot

maintain a connection because something local is sitting in the socket
path, the error should say so. The current messages — "ECONNRESET" and
"Connection closed mid-response" — are indistinguishable from an ISP
problem or an API outage, so the user has no reason to suspect their own
machine, let alone a DLL left behind by software they uninstalled months
ago.

1. claude doctor should detect and warn about non-Microsoft Winsock LSP

entries on Windows. This is a single command:

netsh winsock show catalog

Anything outside MSAFD / RSVP / AF_UNIX / Bluetooth / NTDS is a
third-party layered provider that sits in the path of every socket in
every process. Surfacing that during diagnosis would have turned a
multi-day investigation into a one-line answer.

Ideally the client would also tolerate a legacy LSP the way 2.1.220 did,
but I recognise that may not be practical, and diagnosability matters more.

Error Messages/Logs

- `Unable to connect to API (ECONNRESET) · Retrying in 0s · attempt x/10`
- `API Error: Connection closed mid-response. The response above may be incomplete.`
- Most sessions produced zero assistant messages before dying.

Steps to Reproduce

Environment: Windows 11 Pro 26200, native install, no proxy, direct Wi-Fi.

1. Have a third-party Winsock LSP registered on the machine. Verify with:

netsh winsock show catalog | findstr /i description
In my case: 22 entries (32-bit and 64-bit chains) from a NetEase UU game
accelerator that had been uninstalled long ago. Its uninstaller never
deregistered the LSP, so C:\Windows\Netease\Booster\lsp64.dll was still
being injected into every process, confirmed via:
Get-Process | ForEach-Object { $_.Modules } | Where-Object { $_.FileName -match 'Netease' }
It was the only non-system module loaded into the claude process.

1. Run Claude Code 2.1.220. Works normally.

Measured across 9 sessions: 694 assistant messages, 0 API errors.

1. Update to 2.1.221 or 2.1.222. Nearly every request now fails.

Measured across 5 sessions: 5 assistant messages total; 3 sessions
produced zero assistant messages before dying. Ask for a long response —
short replies sometimes slip through, long streaming responses reliably
get cut mid-stream.

1. Remove the LSP and reboot:

netsh winsock reset

1. 2.1.222 now works normally, with no other changes.

Controls that ruled out everything else:

• Second Windows PC, same Wi-Fi, same 2.1.222 build: no problem at all.

That machine has no LSP installed.

• Disabling IPv6 on the adapter: no effect.
• Stopping VPN and proxy services (Tailscale, Clash): no effect.
• Lowering MTU to 1400: no effect.

(An LSP operates below all of these, which is why none of them helped.)

Note: reproducing this requires a machine with an LSP present, so it is
environment-dependent rather than a clean repro. Happy to run any diagnostic
you want on the affected machine — I still have the 2.1.220/221/222 binaries
and the captured Winsock catalog from before the reset.

Claude Model

Opus

Is this a regression?

I don't know

Last Working Version

_No response_

Claude Code Version

2.1.221

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

Windows Terminal

Additional Information

_No response_