[Bug] Claude Code Desktop bundled CLI connection failures (ECONNRESET) — npm CLI unaffected
Bug Description
Bug Report: Persistent ECONNRESET in Claude Code Desktop (Windows) — CLI on same machine unaffected
Summary
Since the Claude desktop app updated to 1.25927.0.0 on 2026-08-05, Claude Code sessions
launched from the desktop app fail with repeated ECONNRESET errors, retrying with exponential
backoff until they exhaust and give up. The update to 1.26832.0.0 on 2026-08-07 did not
fix it.
The key signal: the npm-installed Claude Code CLI v2.1.224 runs flawlessly on the same machine,
same network, same account, at the same time. Only the desktop app's bundled Claude Code
(2.1.221, then 2.1.222) fails. This isolates the fault to the desktop app build rather than the
local environment or network.
User-visible symptoms:
- Banner: "Connection problem — Check your internet connection, VPN, or proxy and try again."
- Inline:
API Error: Connection to the API was lost (ECONNRESET). This is usually temporary — try again.
Environment
| Item | Value |
|---|---|
| OS | Windows 11 Home Single Language, 10.0.26200 |
| RAM | 13.94 GB (5.5 GB free during failures) |
| Desktop app | Claude 1.26832.0.0 (MSIX, C:\Program Files\WindowsApps) |
| App's bundled Claude Code | 2.1.221, then 2.1.222 — fails |
| npm CLI Claude Code | 2.1.224 (AppData\Roaming\npm), Node v24.11.1 — works |
| Network | Wi-Fi, Realtek 8821CE, 5 GHz 802.11ac, signal 100% |
| Proxy / VPN | None configured |
Version timeline vs. onset
From the Windows AppX deployment log:
| Date/time (local) | App version | Behavior |
|---|---|---|
| 2026-08-03 22:16 | 1.24012.11.0 | Working normally |
| 2026-08-05 21:07 | 1.25927.0.0 | Failures begin |
| 2026-08-06 19:42–19:59 | 1.25927.0.0 | 20 ECONNRESETs in ~6 min |
| 2026-08-07 15:28 | 1.26832.0.0 | Update applied — not fixed |
| 2026-08-07 15:37 | 1.26832.0.0 | ECONNRESET still occurring |
Error detail
Raw record from the session transcript:
{"type":"system","subtype":"api_error","level":"error",
"error":{"message":"Connection error.",
"formatted":"Unable to connect to API (ECONNRESET)",
"connection":{"code":"ECONNRESET",
"message":"The socket connection was closed unexpectedly.",
"isSSLError":false}}}
Note isSSLError: false — this is not a TLS negotiation failure.
Reproduction pattern
Two consecutive bursts on 2026-08-06, each retrying with exponential backoff until exhausted
(times UTC; local = UTC+3):
Burst 1: 16:52:30, :32, :34, :38, :44, :55, 16:53:15, 16:53:54, 16:54:35, 16:55:15
Burst 2: 16:56:26, :28, :30, :34, :40, :49, 16:57:08, 16:57:41, 16:58:16, 16:58:56
Backoff intervals: 2s, 2s, 4s, 6s, 11s, 20s, 39s, 41s, 40s. Every retry failed. This
retry-to-exhaustion behavior is what makes the app unusable, not the individual resets.
Logging gap worth flagging: %APPDATA%\Claude\logs\main.log recorded only 5 of these
20 errors. Anyone diagnosing from main.log alone will badly underestimate severity. The
complete record is only in the session transcript at~/.claude/projects/<project>/<session-id>.jsonl.
Local causes systematically ruled out
Each was tested directly, not assumed:
| Hypothesis | Test | Result |
|---|---|---|
| Proxy / VPN | Env vars + WinINET registry | None configured |
| DNS | Resolve-DnsName api.anthropic.com | Resolves correctly |
| TCP reachability | Test-NetConnection :443 | Succeeds |
| Connection stability | 10 consecutive HTTPS requests | 10/10 succeeded |
| Path MTU blackholing | DF-bit ping sweep 1372–1472 | Full 1500 passes, no fragmentation |
| Sustained throughput | 25 MB HTTPS download | Completed, 21.1 s |
| Upload throughput | 8 MB HTTPS POST | Completed, 6.5 s (9.89 Mbps) |
| Latency / packet loss | 20 pings to API IP | 0% loss, avg 48 ms |
| IPv6 misrouting | Interface + route inspection | No global IPv6, no default route — never attempted |
| Wi-Fi driver drops | WLAN event log correlation | 6 drops in 3 days, zero correlate with errors |
| Memory pressure | RAM + page file during failure | 5.5 GB free, page file idle (0.32/11 GB) |
| Electron event-loop stalls | Stall log vs. error timestamps | No correlation (nearest 3 min apart) |
| TLS failure | isSSLError flag | false |
| Context / payload size | Token usage in transcript | ~60K tokens — normal |
| Third-party TLS inspection | AV enumeration | Windows Defender only |
Expected vs. actual
Expected: Claude Code launched …
Note: Content was truncated.
3 Comments
i have this problem too
windows 10, native .exe claude code
``
✻ Unable to connect to API (ECONNRESET) · Retrying in 13s · attempt 9/10``Solution:
claude.exe v2.1.220 works stably.
Replace exe in the folder:
C:\Users\John\.local\bin\claude.exeDisable updates:
Config file:
C:\Users\John\.claude.json```
"autoUpdates": false,
"autoUpdatesProtectedForNative": false
```
HI,
I had the same symptoms (repeated ECONNRESET) on Windows and couldn't get any work done in August. It's resolved now, so I'll leave what I found here.
In my case, the cause was interference from corporate endpoint security / monitoring software . Clues that pointed to it: it happened only on Windows (Mac on the same network was fine), it affected every Claude Code version and distribution (desktop bundled, native exe, including pinned older versions), while the browser version of Claude worked normally. The software intercepts HTTPS traffic from non-browser apps via a local proxy on Windows.
We contacted the security software vendor, they provided a patch, and Claude Code now works without any problems. If you see the same pattern, it might be worth checking with the vendor or administrator of any security or monitoring software installed on your machine.
[Bug] Desktop-app bundled Claude Code dies on transient ECONNRESET (does not retry); standalone CLI on the same machine recovers
Summary
The Claude Code that ships inside the Claude desktop app on Windows fails hard with
API Error: Connection dropped (ECONNRESET)after roughly 1–2 hours of normal use, on every model I tried (Claude Opus 4.8 and Claude Fable 5.1). A single transient connection reset terminates the session and it does not recover; I have to restart to continue.The standalone npm CLI (
@anthropic-ai/claude-code) on the same machine, same network, same account hits the same underlying resets but retries through them and keeps working. That isolates the fault to the desktop app's bundled build, not my environment. This looks like the same class of problem as #84818 and #77733.Environment
@anthropic-ai/claude-codelatest via npm (Node.js LTS)Steps to reproduce
ECONNRESEToccurs; the desktop app surfacesAPI Error: Connection dropped (ECONNRESET)and the request/session stops.Expected behavior
On a transient
ECONNRESET, the desktop app's Claude Code should retry/reconnect and continue the session — the way the standalone CLI does — rather than terminating the request.Actual behavior
A single
ECONNRESETends the request withAPI Error: Connection dropped (ECONNRESET)and does not recover. The standalone CLI on the same machine, at the same time, recovers from the identical resets and keeps working.What I have already ruled out (extensive)
This was diagnosed over a long session; the environment is healthy and every user-side cause has been eliminated:
ECONNRESET, Chrome and all other applications have no connectivity issues.curl https://api.anthropic.comsucceeds with a valid certificate. No Cloudflare WARP / Zero Trust and no antivirus HTTPS inspection is in the path (only an unrelated outboundcloudflaredtunnel for a self-hosted site; NETGEAR Armor is off).0x80073CF6AppX registration error withDISM /Online /Cleanup-Image /RestoreHealth+sfc /scannow) did not resolve it.Impact
The desktop app's built-in Claude Code is effectively unusable for any session longer than an hour or two, because it cannot survive a routine transient reset. The standalone CLI is the only working option, which defeats the point of the GUI for users who don't want to work in a terminal.
Likely root cause
The bundled Claude Code build in the desktop app appears to lack the
ECONNRESETretry/reconnect logic present in the current standalone CLI. Bringing the desktop app's bundled version up to a build that includes those retries should resolve it.Related
Happy to provide logs (
%APPDATA%\Claude\logs, session transcript.jsonl), the network capture, or run any diagnostic you'd like.