[BUG] [BUG] Persistent ECONNRESET on v2.1.228 (post-fix) — all networks, all local causes eliminated incl. full AV uninstall; claude.ai chat works fine on same account

same issue here and the most bad part in the story is that no one from anthropic team is answering to the mails/here

Confirming this on Windows 10 Pro (19045), native installer, first-party API (not Bedrock/Vertex), no ANTHROPIC_BASE_URL and no proxy configured.

I was able to narrow down where this regression starts by scanning my local session transcripts (~/.claude/projects/**/*.jsonl), counting sessions that contain an isApiErrorMessage entry matching ECONNRESET / Connection lost mid-response / Connection closed mid-response / Connection to the API was lost. Benign entries such as No response requested. were excluded.

The regression appears to start at 2.1.221, not 2.1.228.

| Version | Sessions | Sessions with a connection error | Connection errors |
|---|---|---|---|
| 2.1.193 | 14 | 0 | 0 |
| 2.1.198 | 3 | 0 | 0 |
| 2.1.205 | 17 | 0 | 0 |
| 2.1.207 | 22 | 0 | 0 |
| 2.1.208 | 1 | 0 | 0 |
| 2.1.210 | 86 | 0 | 0 |
| 2.1.212 | 1 | 0 | 0 |
| 2.1.220 | 125 | 0 | 0 |
| 2.1.221 | 3 | 2 | 2 |
| 2.1.222 | 1 | 0 | 0 |
| 2.1.226 | 63 | 10 | 18 |
| 2.1.227 | 7 | 3 | 3 |
| 2.1.228 | 5 | 1 | 1 |

Everything at or below 2.1.220 is clean across 269 sessions with zero connection errors. The first connection error in my entire history is on 2026-08-04, on 2.1.221.

Ruling out a server-side or network-side cause

I still have 2.1.220 installed alongside the newer builds, so the affected and unaffected versions were run on the same machine and network on the same days:

| Date | 2.1.220 | 2.1.227 | 2.1.228 |
|---|---|---|---|
| 2026-08-11 | 5 sessions, 0 errors | 3 sessions, 2 errors | — |
| 2026-08-12 | 12 sessions, 0 errors | 5 sessions, 1 error | 6 sessions, 1 error |

2.1.220 ran 17 sessions across the same two days the newer builds were failing, without a single connection error. That makes a server-side change or a local network problem an unlikely explanation.

Error strings observed

The user-visible message changed wording across versions, but the failure looks identical:

2.1.221 / 2.1.226:  API Error: Connection to the API was lost (ECONNRESET). This is usually temporary — try again.
2.1.221 / 2.1.226:  API Error: Connection closed mid-response. The response above may be incomplete.
2.1.227 / 2.1.228:  API Error: Connection lost mid-response. The response above may be incomplete.

Debug trace (2.1.228)

The connection is established and the first chunk does arrive before the reset, so this is not a TLS handshake or DNS failure — the stream dies mid-flight:

[DEBUG] [API REQUEST] /v1/messages x-client-request-id=… source=sdk
[DEBUG] Stream started - received first chunk
[DEBUG] [API:timing] first byte after 2001ms
[WARN]  Stream connection error (ECONNRESET) — retrying streaming (4/10)
[DEBUG] [API:timing] dispatching to firstParty model=claude-haiku-4-5-20251001
[DEBUG] [API REQUEST] /v1/messages x-client-request-id=… source=generate_session_title
[DEBUG] Stream started - received first chunk
[DEBUG] [API:timing] first byte after 1003ms
[WARN]  Stream connection error (ECONNRESET) — retrying streaming (5/10)

That excerpt covers 9 ECONNRESETs in a 19-second window. It reproduces against both the sdk and generate_session_title request sources and across models (claude-opus-5[1m] and claude-haiku-4-5-20251001), so it does not appear to be model- or feature-specific.

Side effect worth noting

In headless mode (-p) the retry logic usually absorbs this and the command still exits 0, so it shows up as latency rather than failure. One identical single-turn request:

• 2.1.227 → 12.8s
• 2.1.228 → 205.1s

Both returned the correct output. This means CI or scripted -p usage on affected versions may be silently paying a large latency cost instead of erroring out visibly.

Caveats

• The per-version sample sizes for 2.1.221 (3 sessions), 2.1.227 (7) and 2.1.228 (5) are small, so I would not read much into the relative rates between those specific builds.
• The parts I consider solid are the two ends: 269 sessions at ≤2.1.220 with zero errors, and 63 sessions at 2.1.226 with 10 affected.
• I could not reproduce it on demand in a short scripted loop — it is intermittent, hitting roughly 20–40% of sessions on affected versions.

Happy to run a specific build or collect a fuller --debug trace if that would help bisect between 2.1.220 and 2.1.221.

Can confirm the regression window reported above: downgrading the native CLI to 2.1.220 (with DISABLE_AUTOUPDATER=1) completely eliminates the resets on my machine — Windows 11, same account and networks where 2.1.221 / 2.1.223 / 2.1.226–2.1.228 failed on most requests. Working perfectly now, including resuming long sessions.

Timeline matches the bisect too: my errors began in early August, right when my Desktop app's bundled engine moved to 2.1.221. Full local elimination is documented in the issue body (AV fully uninstalled, FortiClient disabled, 3 networks, winsock reset, etc.) — none of it mattered; only the version downgrade fixed it.

Note: the Desktop app's Code tab (bundled engine 2.1.221+) is still affected since it can't be pinned to 2.1.220.

FINALLY I MANAGED TO FIX IT!
CLAUDE CLI/DESKTOP VERSIONS!
FINALLY I MANAGED TO FIX IT!
Workaround that fixes the Desktop app (not just the CLI) — Windows

Downgrading the native CLI to 2.1.220 fixes the terminal, but as noted above, the Desktop app's bundled engine can't be pinned — it keeps re-downloading the affected 2.1.22x version. Here's a workaround that makes the Desktop app run 2.1.220 as well.

The idea: replace the claude.exe inside the Desktop's bundled version folder with a clean 2.1.220 binary, mark it read-only, and disable the background watcher that restores it.

1. First install 2.1.220 to the native location (this gives us a clean binary to copy from):

powershell
& "$env:USERPROFILE\.local\bin\claude.exe" install 2.1.220

1. Disable the background watcher (it re-downloads the affected version otherwise):

powershell
Stop-ScheduledTask -TaskName "ClaudeRtlPatchWatcher"
Disable-ScheduledTask -TaskName "ClaudeRtlPatchWatcher"

1. Fully close Claude:

powershell
Get-Process claude -ErrorAction SilentlyContinue | Stop-Process -Force
Get-Process chrome-native-host -ErrorAction SilentlyContinue | Stop-Process -Force
Start-Sleep 3
Get-Process claude -ErrorAction SilentlyContinue # should return empty

1. Overwrite the bundled engine's exe with the clean 2.1.220 binary and lock it read-only (replace 2.1.227 with whatever version folder exists under %APPDATA%\Claude\claude-code):

powershell
Copy-Item "$env:USERPROFILE\.local\bin\claude.exe" "$env:APPDATA\Claude\claude-code\2.1.227\claude.exe" -Force
Set-ItemProperty "$env:APPDATA\Claude\claude-code\2.1.227\claude.exe" -Name IsReadOnly -Value $true

1. Verify the bundled exe now reports 2.1.220:

powershell
& "$env:APPDATA\Claude\claude-code\2.1.227\claude.exe" --version

should print: 2.1.220 (Claude Code)

1. Also disable CLI auto-update in %USERPROFILE%\.claude\settings.json:

json
"env": { "DISABLE_AUTOUPDATER": "1" },
"autoUpdates": false

After this, open the Desktop app and it runs the 2.1.220 engine while still appearing as the newer version. In my testing, ECONNRESET / "Request failed – retrying" is completely gone, including long tool-heavy sessions (45s+ requests that previously always failed now complete cleanly).

Environment: Windows, Desktop app 1.28929, Max plan. Same signature everyone else reports — claude.ai browser fine, curl to api.anthropic.com clean (401, no resets), no proxy/VPN.

Caveat: if the Desktop app later self-updates and creates a new engine folder, you may need to repeat step 4 for the new folder. A real fix from Anthropic (fresh TCP connection on retry / not reusing dead sockets from the HTTP/2 pool) is still needed.

Can confirm the Desktop app engine-swap workaround works on my side too — both CLI and Desktop app are now fully functional. Thank you!

A few notes for others on the MSIX/Store-packaged Desktop app (mine: 1.28929, Windows 11, Max plan):

• The ClaudeRtlPatchWatcher scheduled task did not exist on my machine — the binary swap + read-only flag alone was sufficient.
• Due to MSIX filesystem virtualization, %APPDATA%\Claude\claude-code does not exist from an external shell (the engine process reports that path, but Test-Path fails). The real location is:

%LOCALAPPDATA%\Packages\Claude_pzs8sxrjxfjjc\LocalCache\Roaming\Claude\claude-code\<version>\claude.exe

• Working procedure: keep the Desktop app open (so the engine folder exists), kill only the engine process (Get-Process claude | Where-Object { $_.Path -like "*claude-code*" } | Stop-Process -Force), copy the clean 2.1.220 binary over the bundled exe in the LocalCache path above, set it read-only, verify with --version → 2.1.220 (Claude Code).

After the swap, the Code tab is completely stable — no more ECONNRESET / "Request failed – retrying", including resuming long sessions. This machine previously failed on 2.1.221 / 2.1.223 / 2.1.226–2.1.228 across 3 networks with all local security software eliminated (full details in the issue body).

A proper upstream fix is still needed — this workaround has to be repeated whenever the app ships a new engine folder.