[BUG] Intermittent ECONNRESET on both desktop app and standalone CLI, no VPN/proxy

Confirming the same issue on macOS, with a very similar timeframe (15–18 Aug 2026).

Claude Code has recorded repeated API Error: Connection dropped (ECONNRESET) failures. I have also seen occasional API Error: 529 Overloaded responses.

Local checks look clean:

• No HTTP/SOCKS proxy configured
• No proxy environment variables
• No custom TLS/CA configuration
• No VPN in use
• Claude Code authentication refreshes succeed

curl -v https://api.anthropic.com/ succeeds from this Mac: DNS resolves, TLS 1.3 certificate verification passes, HTTP/2 is negotiated, the expected 404 is returned for GET /, and the connection remains intact.

I am now on Claude Code 2.1.235 (updated today). The errors occurred before and after the update. This appears consistent with an intermittent issue beyond basic local connectivity.

At 10:03 BST on 19 Aug 2026, I captured the failure at the TCP level while Claude Code was running.

The Mac received four TCP resets from the resolved api.anthropic.com endpoint:

160.79.104.10:443 → 172.16.10.135:<ephemeral-port>

The Mac did not initiate those resets.

For the final failed connection, the TCP handshake completed normally; the endpoint promptly acknowledged a substantial amount of client data, sent a response packet, and then sent RST about 1 ms later. The capture showed no retransmissions or other obvious packet-loss signals before the
resets.

This does not conclusively distinguish an Anthropic/Cloudflare edge reset from an inline network intermediary, but it is strong evidence against a Mac-side configuration fault. I can provide the timestamped, packet-length-truncated capture privately if useful.

Confirming this on macOS as well (2026-08-21), on Claude Code 2.1.238 (npm-global install, darwin-arm64).

Symptoms: recurring API Error: Connection dropped (ECONNRESET) when sending a message in an active interactive session.

Ruled out on my end before finding this thread:

• No HTTP/SOCKS proxy configured (env vars and macOS system proxy both empty)
• No VPN in use (verified no VPN client processes running, only standard macOS system utun interfaces)
• macOS Application Firewall disabled, no third-party firewall/security software installed
• curl -v https://api.anthropic.com/ succeeds immediately (TLS handshake, HTTP/2, 404 on GET / as expected)
• Reproduced on two different Wi-Fi networks, so not network/router-specific
• claude doctor reports no installation issues
• Re-authenticated (logout/login) and updated to latest CLI version — issue persisted through both

This matches @grahamduthie's report closely: local network/config checks are all clean, and the failure appears intermittent and session-specific rather than tied to any particular network path.

Same profile here (macOS, no configured VPN, curl to api.anthropic.com succeeding) and I tracked it down to iCloud Private Relay. Posting the full diagnostic in case it helps others landing on this thread.

Symptoms

API Error: Connection dropped (ECONNRESET) in the VS Code extension, on every message including a fresh session with a single "hi". The Claude desktop app worked fine at the same time on the same machine and network — only the extension/CLI failed.

Why the usual checks all looked clean

$ env | grep -i proxy
(empty)

$ curl -sS -o /dev/null -w '%{http_code} %{time_total}s\n' https://api.anthropic.com/v1/messages
405 0.081986s

A 3 MB POST also went through fine (401 in 0.32s), so payload size / MTU was ruled out.

The catch: plain curl does Happy Eyeballs and silently falls back to IPv4. Forcing IPv6 exposes it:

$ curl -6 -sS -o /dev/null -w 'v6: %{http_code}\n' https://api.anthropic.com/v1/messages
curl: (35) Recv failure: Connection reset by peer
v6: 000

Reset in ~8ms — local, not upstream.

The actual cause

Disabling IPv6 on the Wi-Fi service did not help, because the IPv6 default routes were not on the Wi-Fi interface:

$ netstat -rn -f inet6 | head
Internet6:
Destination        Gateway               Flags     Netif
default            fe80::%utun0          UGcIg     utun0
default            fe80::%utun1          UGcIg     utun1
default            fe80::%utun2          UGcIg     utun2
default            fe80::%utun3          UGcIg     utun3

Those utun interfaces belong to iCloud Private Relay. scutil --nc list is empty (no user-configured VPN), which is why VPN checks come back negative — the tunnels come from the system VPN.appex network extension.

Turning off iCloud Private Relay (System Settings → Apple ID → iCloud → iCloud+ Features → Private Relay) fixed it immediately. Re-enabling IPv6 on Wi-Fi afterwards kept working, so Private Relay was the sole cause.

Two workarounds — either one is enough

1. Global: System Settings → Apple ID → iCloud → iCloud+ Features → Private Relay → off.
2. Per network (preferred): leave Private Relay on and turn off Wi-Fi → Details → "Limit IP address tracking" for the offending network only.

I verified option 2: Private Relay re-enabled globally, disabled only for this Wi-Fi, and the extension works. So you don't have to give up Private Relay everywhere — just on the network that breaks it.

This is network-specific, not machine-specific

Worth stressing, because it makes the bug look intermittent and unreproducible: on my home Wi-Fi, Private Relay is on and Claude Code works perfectly. The failure only appears on one particular network. Same machine, same version, same account.

Private Relay tunnels over QUIC (UDP/443). The network where this happens is a managed 10.100.0.0/22 segment whose firewall appears to block QUIC. Private Relay then ends up half-broken: routes stay installed, traffic enters the tunnel, nothing comes back → RST.

So if you're chasing this: the relevant variable is which network you're on, not your machine's configuration. Anyone reproducing this should note the network alongside the OS and version.

Why the desktop app survives and Claude Code doesn't

The desktop app is Electron and uses Chromium's network stack, which does aggressive Happy Eyeballs and falls back to IPv4 within milliseconds. The Claude Code native binary (Running: native, v2.1.209) appears to take the IPv6 path, hit the RST, and surface it rather than retrying over IPv4.

Suggestion: an IPv4 fallback on ECONNRESET during connection setup would make this class of failure invisible, matching what Chromium and curl already do. Failing that, surfacing the resolved address family in the error message would make it far easier to diagnose.

Quick check for anyone hitting this

curl -6 -sS -o /dev/null -w 'v6: %{http_code}\n' https://api.anthropic.com/v1/messages
curl -4 -sS -o /dev/null -w 'v4: %{http_code}\n' https://api.anthropic.com/v1/messages

If v6 resets and v4 returns 405, check netstat -rn -f inet6 for utun default routes and try disabling Private Relay.

Thanks — this is a useful lead, but it does not explain my case. I tested from the affected Mac: forced IPv4 and forced IPv6 requests to
api.anthropic.com/v1/messages both return HTTP 405 successfully in ~40 ms, and there are no IPv6 default routes via utun interfaces.

My captured failure was also on IPv4: the connection to 160.79.104.10:443 completed its TCP handshake, acknowledged client data, sent a response packet, then reset about 1 ms later. So this appears to be a separate, post-connection reset path rather than the Private Relay/IPv6 issue.