[Bug] Claude Code Desktop bundled CLI connection failures (ECONNRESET) — npm CLI unaffected

Status Open
Reported on v2.1.221
Maintainer reply None cached
Activity 3 comments · opened Aug 7, 2026

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.

View original on GitHub ↗

3 Comments

bro34674 · 2 months ago

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.exe

Disable updates:
Config file:
C:\Users\John\.claude.json

```
"autoUpdates": false,
"autoUpdatesProtectedForNative": false

```

akira-doke0coly-info · 1 month ago

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.

nickpeterson91-dev · 1 month ago

[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

  • OS: Windows 10 Home 22H2 (build 19045), x64
  • Claude desktop app version: 1.46388.4 (please confirm via Help/About)
  • Bundled Claude Code version: _[fill in — desktop app → about, or the version shown when the built-in Claude Code starts]_
  • Standalone CLI version (works): @anthropic-ai/claude-code latest via npm (Node.js LTS)
  • Models affected: Claude Opus 4.8 and Claude Fable 5.1 (both)

Steps to reproduce

  1. Use Claude Code inside the Claude desktop app on Windows.
  2. Work normally for ~1–2 hours.
  3. A transient ECONNRESET occurs; the desktop app surfaces API Error: Connection dropped (ECONNRESET) and the request/session stops.
  4. It does not reconnect on its own — a restart is required to continue.

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 ECONNRESET ends the request with API 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:

  • Not the network. A 60-minute continuous capture showed 0% packet loss to both the router and the internet, no Wi-Fi disconnects, and low latency. The connection to Anthropic was reset only ~twice in the hour with the network otherwise perfectly clean — i.e., occasional edge/NAT recycling that a retry-capable client should absorb.
  • Not a general outage / not other apps. At the exact moment the desktop app throws ECONNRESET, Chrome and all other applications have no connectivity issues.
  • Not TLS interception or cert trust. curl https://api.anthropic.com succeeds with a valid certificate. No Cloudflare WARP / Zero Trust and no antivirus HTTPS inspection is in the path (only an unrelated outbound cloudflared tunnel for a self-hosted site; NETGEAR Armor is off).
  • Not the system clock. Verified correct (matches phone) at time of failure, so it is not a TLS date-validation issue.
  • Not a stale install. Full uninstall/reinstall of the desktop app (after clearing a 0x80073CF6 AppX registration error with DISM /Online /Cleanup-Image /RestoreHealth + sfc /scannow) did not resolve it.
  • Not the account or model. Same account works fine via the standalone CLI; occurs on both Opus 4.8 and Fable 5.1.

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 ECONNRESET retry/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

  • #84818 (desktop bundled CLI ECONNRESET, npm CLI unaffected)
  • #77733 (ECONNRESET in desktop in-app Claude Code, standalone CLI works)

Happy to provide logs (%APPDATA%\Claude\logs, session transcript .jsonl), the network capture, or run any diagnostic you'd like.