[BUG] Regression 2.1.220 → 2.1.221 (Windows native): direct API connections die with ECONNRESET after first chunk when a Winsock LSP (Proxifier v3) is registered

Summary

Claude Code 2.1.221 (native Windows binary) fails almost every API request with
API Error: Connection to the API was lost (ECONNRESET) on a host where
Proxifier Standard Edition v3 has its Winsock LSP/NSP providers
registered — even though Proxifier's rules proxy nothing (default rule =
Direct) and the Proxifier application is not running. 2.1.220 is clean on the
same host with the same LSP registered, so something in 2.1.221's direct
socket handling changed and now trips the (deprecated, 2016-era) LSP shim.

Three discriminating experiments, all on the same host/account/prompt:

| Configuration | Result |
|---|---|
| 2.1.220 direct, LSP registered | 3/3 clean, 5.8–6.7 s, 0 resets |
| 2.1.221 direct, LSP registered | 0/3 clean, 8.8–20.1 s, 2–4 resets each; two runs died mid-response |
| 2.1.221 via localhost HTTP CONNECT proxy, LSP registered | clean, 8.0 s, 0 resets |
| 2.1.221 direct, LSP unregistered (SysSettings64.exe silent-uninstall) | clean, 7.3 s, 0 resets |

The localhost CONNECT proxy keeps TLS + HTTP/2 inside Claude Code and only
changes which process owns the remote TCP socket (node.exe instead of
claude.exe), so the failure is specific to direct sockets owned by the
claude.exe process — i.e., the code path the LSP wraps in-process.

I'm reporting it because (a) it's a behavior change between two consecutive
releases that isn't explained by the public changelog, (b) LSPs, while
deprecated, are still installed system-wide by older proxy/AV/VPN products, and
(c) the failure mode is brutal to diagnose from the outside — every other
client on the machine works.

Environment

• Windows 10 Pro 19045 (22H2), 20-core desktop, Realtek RTL 8125 NIC, no system proxy, no proxy env vars
• Claude Code 2.1.221, native installer (%USERPROFILE%\.local\bin\claude.exe); byte-identical to the VS Code extension's native binary
• 2.1.220 SHA256 AF5BF1F1B2AADFFC768ECCD787084C6FDF9BA81624CBE96C1C6D9AC1A1550231
• 2.1.221 SHA256 0F73196359A07F9AD435A8C83CA7C741B9F2ADBC0AD9B05F71A0C2F4AABE906A
• both carry valid Anthropic Authenticode signatures (same cert) — not a corrupt-binary issue
• Auth: Claude subscription (OAuth)
• Proxifier Standard Edition 3.31.0.1 (2016), Winsock providers registered system-wide:

``
Provider Path: %SystemRoot%\system32\PrxerDrv.dll
Description: PROXIFIER MSAFD Tcpip [TCP/IP]
Description: PROXIFIER MSAFD Tcpip [TCP/IPv6]
Description: PROXIFIER LSP
Description: Proxifier NSP
`
PrxerDrv.dll / PrxerNsp.dll are loaded by Windows into **every** process
that creates a TCP socket, including every claude.exe — the Proxifier app
itself was never running. Its profile's default rule is **Direct**; no rule
matches claude.exe`. The LSP is purely passing traffic through.

Failure signature

From claude --debug --debug-file (timestamps trimmed):

[API REQUEST] /v1/messages  source=repl_main_thread  model=claude-opus-5[1m]
Stream started - received first chunk          (first byte after 783 ms)
Stream connection error (ECONNRESET) — retrying streaming (1/10)   ← 7 ms later
Stream started - received first chunk          (first byte after 938 ms)
Stream connection error (ECONNRESET) — retrying streaming (2/10)   ← 1 ms later
...
[ERROR] Error streaming, falling back to non-streaming mode: The socket
        connection was closed unexpectedly. For more information, pass
        `verbose: true` in the second argument to fetch()
[ERROR] Connection error details: code=ECONNRESET
[DEBUG] turn 1 end (usage in=7640 out=56 cost=$0.5342 api=201082ms stop=stop_sequence)

Key properties:

• TLS completes, the request is sent, the server responds, **the first chunk

arrives** — then the socket dies 1–7 ms later. Retries escalate to 7/10;
turns take 200+ s when they complete at all.

• Not streaming-specific: the non-streaming fallback also fails on a

~7,600-token request, while a small generate_session_title request
succeeds on fallback — size-correlated.

• Reproduces with --safe-mode-equivalent isolation: no user settings, no

plugins, no hooks, no MCP; and with a forced Haiku model.

• One captured request id, if useful for server-side lookup:

x-client-request-id=44b9a0a6-1863-4a8a-a245-2fbfa137a51b (2026-08-04 UTC).

Wire evidence: the client closes first

Two pktmon captures (~110 s each, filtered to the Anthropic edge IP):

• 0 retransmissions either direction, 0 inbound RST ever, **0

zero-window** advertisements (min advertised window 261 KB) — the network
path and the server are faultless.

• All resets are outbound, and the teardown is the app closing mid-body:

``
23:51:34.955 IN [P.] len 1391 server streaming the response
23:51:34.956 OUT [.] len 0 ACK
23:51:34.956 OUT [F.] len 0 ← client closes the socket mid-response
23:51:34.959 IN [P.] len 84 server keeps sending
23:51:34.959 OUT [R.] len 0 ← stack RSTs data arriving on closed socket
``

So from the runtime's perspective a read fails / the connection "hangs up"
(Bun's ECONNRESET fetch error above), the app closes the socket, and the
visible RSTs are just the stack discarding the rest of the response. Since the
LSP sits in-process above the capture point, a wire-clean capture is fully
consistent with the LSP corrupting or misdelivering completions to the app.

Ruled out by measurement

• Anthropic-side resets (0 inbound RST in any capture), network path/MTU/loss

(0 retransmissions, 1472-byte DF ping clean), TLS interception, system/env
proxies (none), IPv6 (control host has identically dead IPv6 and works)

• Claude config, plugins, hooks, MCP, statusline (reproduced with all removed),

model choice, streaming vs non-streaming, install method

• Other filter drivers on the host (an AV WFP driver, an IDM WFP driver): the

failure resolved with only the Proxifier Winsock change; nothing else was
touched

• Per-host generality: on the same machine, Codex CLI, browsers, and a

60/60 synthetic Node HTTPS probe (300 KB POSTs to the same endpoint) are all
clean through the same registered LSP — Node/Chromium socket patterns
pass through it fine; whatever 2.1.221 does differently does not

• A Hyper-V Ubuntu guest behind the same physical NIC running the same

2.1.221 (ELF) is flawless — guest traffic bypasses host Winsock entirely

Timeline corroboration: 2.1.221 was published 2026-08-03T22:16Z; failures
began within hours via auto-update. Already-running sessions (older version,
established sockets) kept working until restarted, which made onset look
random.

How affected users can check / work around

Check for a registered LSP (any vendor, not just Proxifier):

netsh winsock show catalog | findstr /i "proxifier prxer lsp"

Workarounds verified here, in increasing order of permanence:

1. Route Claude Code through any localhost HTTP CONNECT proxy

(HTTPS_PROXY=http://127.0.0.1:<port>) — clean even with the LSP installed.

1. Unregister the LSP: Proxifier's SysSettings64.exe silent-uninstall +

SysSettings32.exe silent-uninstall (elevated), or netsh winsock reset
for the generic case. New Claude Code processes are immediately clean.

1. Upgrade Proxifier to v4, whose engine is a WFP callout driver instead of an

LSP — removes the in-process shim entirely.

Ask

1. What changed in 2.1.221's Windows networking (runtime bump? socket-layer

change?) — it isn't identifiable from the public changelog, and knowing it
would tell you whether other LSP-class interceptors will hit this too.

1. Consider whether the client can detect a registered third-party LSP wrapping

its sockets and surface a hint in the ECONNRESET error path. This failure
mode looks identical to "bad network" and cost ~2 days to isolate; the
evidence shape in #62045 (2.1.150: "client fails while curl, Node, and the
network all succeed") looks like the same class.

Full diagnostic logs (bisect runs, pktmon extracts, debug logs) are available —
happy to attach any of them.