[BUG] [2.1.92] Persistent "Connection error" on flaky networks; all MCP servers disconnect simultaneously; 2.1.85 works fine

Resolved 💬 3 comments Opened Apr 7, 2026 by Johannes-Krabbe Closed Apr 7, 2026

Preflight Checklist

  • [x] I have searched existing issues and this hasn't been reported yet
  • [x] This is a single bug report (please file separate reports for different bugs)
  • [x] I am using the latest version of Claude Code

What's Wrong?

On Claude Code 2.1.92 (native install), every API request fails immediately with:

Unable to connect to API (ECONNRESET)
Retrying in Xs… (attempt N/10)

The retry loop runs through all 10 attempts and never recovers. At the same time, every connected MCP server (Slack, Betterstack, Linear, GitHub, Notion, Context7) disconnects in parallel with AbortError: The operation was aborted after ~22–23 seconds of uptime, then fails to reconnect.
This happens consistently on a mobile/train network (DE, 5G). However, the network itself is fine for everything else:

claude.ai web chat works perfectly on the same connection.
curl -v https://api.anthropic.com succeeds (clean TLS handshake, HTTP/2, 404 from Cloudflare as expected).
curl -v -N https://api.anthropic.com/v1/messages -H "anthropic-version: 2023-06-01" -H "content-type: application/json" -d '{}' succeeds with the expected 401 x-api-key header is required response.
Hits Berlin Cloudflare edge (cf-ray: ...-TXL), low latency.

Tried before downgrading:

Restarted Mac
Forced IPv4 via NODE_OPTIONS="--dns-result-order=ipv4first" claude
Confirmed no proxy env vars set (env | grep -i proxy empty)
Confirmed on latest version

None of these fixed it. Downgrading to 2.1.85 (stable channel) via claude install stable immediately resolved the issue on the same network with no other changes.

What Should Happen?

Claude Code should either successfully connect (as 2.1.85 does on the exact same network), or surface a more descriptive error than undefined Connection error. so users can diagnose the underlying transport issue.
Ideally 2.1.92 should be at least as resilient as 2.1.85 on flaky/high-latency networks where short HTTP requests succeed but long-lived streaming connections may be more sensitive to NAT/middlebox behavior.

Error Messages/Logs

UI message:
⎿ Unable to connect to API (ECONNRESET)
  Retrying in 7 seconds… (attempt 5/10)
Relevant excerpt from ~/.claude/debug/<session>.txt:
2026-04-07T16:27:33.766Z [ERROR] API error (attempt 1/11): undefined Connection error.
2026-04-07T16:27:34.366Z [DEBUG] [API:request] Creating client, ANTHROPIC_CUSTOM_HEADERS present: false, has Authorization header: false
2026-04-07T16:27:34.367Z [DEBUG] [API:auth] OAuth token check starting
2026-04-07T16:27:34.368Z [DEBUG] [API:auth] OAuth token check complete
2026-04-07T16:27:34.372Z [DEBUG] [API REQUEST] /v1/messages x-client-request-id=b8c7aa51-dd19-4e1d-a9ba-164665e436a9 source=repl_main_thread
2026-04-07T16:27:35.131Z [ERROR] API error (attempt 2/11): undefined Connection error.
...
2026-04-07T16:27:44.199Z [ERROR] API error (attempt 5/11): undefined Connection error.
...
2026-04-07T16:27:48.659Z [DEBUG] MCP server "slack": HTTP transport closed/disconnected, attempting automatic reconnection
2026-04-07T16:27:48.660Z [DEBUG] MCP server "betterstack": HTTP transport closed/disconnected, attempting automatic reconnection
2026-04-07T16:27:48.660Z [DEBUG] MCP server "github": HTTP transport closed/disconnected, attempting automatic reconnection
2026-04-07T16:27:48.660Z [DEBUG] MCP server "linear": HTTP transport closed/disconnected, attempting automatic reconnection
2026-04-07T16:27:48.660Z [DEBUG] MCP server "claude.ai Notion": SSE transport closed/disconnected, attempting automatic reconnection
2026-04-07T16:27:48.667Z [DEBUG] MCP server "betterstack": HTTP connection dropped after 23s uptime
2026-04-07T16:27:48.667Z [DEBUG] MCP server "betterstack": Connection error: SSE stream disconnected: AbortError: The operation was aborted.
2026-04-07T16:27:48.667Z [DEBUG] MCP server "betterstack": Terminal connection error 1/3
2026-04-07T16:27:48.667Z [DEBUG] MCP server "claude.ai Notion": CLAUDEAI-PROXY connection dropped after 22s uptime
2026-04-07T16:27:48.667Z [DEBUG] MCP server "claude.ai Notion": Connection error: SSE stream disconnected: AbortError: The operation was aborted.
2026-04-07T16:27:48.693Z [DEBUG] MCP server "context7": UNKNOWN connection closed after 22s (cleanly)
Note that the underlying error is logged as undefined Connection error. — i.e. the caught error has no code or message, which is itself a bug in error reporting (the user-facing "ECONNRESET" appears to be a default fallback rather than a real ECONNRESET).

Steps to Reproduce

Install Claude Code 2.1.92 (native install).
Connect to a high-latency or flaky network (e.g. mobile carrier on a moving train, hotel WiFi behind aggressive NAT).
Launch claude and send any prompt.
Observe immediate "Unable to connect to API (ECONNRESET)" error and full retry loop failure.
In another terminal, confirm the network itself is fine: curl -v https://api.anthropic.com succeeds, and a POST to /v1/messages returns the expected 401.
Run claude install stable to downgrade to 2.1.85.
Relaunch claude on the same network — connection succeeds immediately.

I do not have a deterministic repro on a stable network; the issue only manifests on networks with the characteristics above. Both versions work fine on stable home WiFi.

Claude Model

None

Is this a regression?

Yes, this worked in a previous version

Last Working Version

2.1.85

Claude Code Version

2.1.92

Platform

Anthropic API

Operating System

macOS

Terminal/Shell

Other

Additional Information

  • CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC is set in my environment, which is why /bug and /feedback are unavailable in-app and I'm filing here directly.
  • 6 MCP servers configured (Slack, Betterstack, Linear, GitHub, Notion, Context7) — all disconnect simultaneously when the API fails, suggesting a common transport-layer issue rather than per-server problems.
  • The consistent ~22–23s connection lifetime before drop on the MCP side is suspicious — feels like an interaction between the Node HTTP client's connection handling and middlebox idle timeouts on the network path.
  • Plain curl (HTTP/2) to the same hostname works flawlessly on the same network at the same time, so DNS, TLS, routing, and basic HTTP/2 are all healthy from this machine.
  • Would be very helpful if the user-facing error surfaced the actual underlying error rather than a generic "ECONNRESET" — the debug log shows undefined Connection error. which suggests the SDK is catching an error object with no useful properties.

View original on GitHub ↗

This issue has 3 comments on GitHub. Read the full discussion on GitHub ↗