claude-code - 💡(How to fix) Fix [BUG] ECONNRESET on long-lived requests after upgrade to 2.1.139 — downgrade to 2.1.138 fixes it

Summary

After auto-update to 2.1.139 on 2026-05-12 (JST evening), Claude Code started failing almost every long-running request with API Error: Unable to connect to API (ECONNRESET). Manually downgrading the symlink back to 2.1.138 completely resolved the issue. Network conditions are unchanged.

Reproduced the regression by allowing the auto-updater to silently re-install 2.1.139 — the failures came back immediately and stopped again after another manual downgrade to 2.1.138.

Environment

• Claude Code: 2.1.139 (broken) → 2.1.138 (works)
• macOS: Darwin 25.2.0 (arm64)
• Shell: zsh
• Network: Wi-Fi (residential), no proxy
• Account: Max ($100/month)

Repro

1. On 2.1.139, send any moderately large request (e.g., normal coding task with accumulated context, or /compact).
2. After a few seconds of "processing", request fails with:

   API Error: Unable to connect to API (ECONNRESET)
   Retrying in 0s · attempt 7/10

3. /compact itself fails with the same error:

   Error: Error during compaction: API Error: Unable to connect to API (ECONNRESET)

4. /clear does not help — fresh sessions still fail on subsequent multi-turn use.

Workaround (confirmed working)

ln -sf ~/.local/share/claude/versions/2.1.138 ~/.local/bin/claude

After restart, claude --version reports 2.1.138 and ECONNRESET stops occurring.

Also recommend setting DISABLE_AUTOUPDATER=1 to prevent the auto-updater from silently reverting to 2.1.139.

Diagnostics (ruled out)

• curl -I https://api.anthropic.com/v1/messages → HTTP 405, TLS handshake 59ms, no errors
• ping api.anthropic.com -c 20 → 0% packet loss
• 10 consecutive TCP connects → 10/10 success in ~100ms each
• traceroute → clean route, final RTT ~27ms via Cloudflare → Anthropic
• nslookup → resolves to Anthropic's public IPv4/IPv6 endpoints
• status.claude.com → no incidents reported for 2026-05-12 / 13
• No HTTP/HTTPS proxy env vars set
• Tried NODE_OPTIONS=--dns-result-order=ipv4first → marginal improvement only, did not eliminate the failures
• Tried /clear after each failure → no effect

Suspected scope

The failure correlates strictly with long-lived streaming requests (typical model responses, /compact). Short requests succeed (which is why basic connectivity tests pass). This suggests a regression in 2.1.139's HTTP client / streaming layer rather than a server-side or network-level issue.