Recurring ECONNRESET connection drops, not tied to compaction

Description

Claude Code repeatedly hits Unable to connect to API (ECONNRESET) across multiple sessions over several days. The built-in retry logic (exponential backoff, ~500ms up to a ~35s cap) does eventually reconnect and the turn completes, but bursts can stall the response for anywhere from several seconds to ~5 minutes.

Environment

• Claude Code version: 2.1.220
• OS: macOS 26.3.1 (build 25D771280a)

What I found

Grepping local session transcripts under ~/.claude/projects/<project>/*.jsonl for ECONNRESET turned up a clear recurring pattern:

• One session had 35 ECONNRESET system/api_error events across 4 distinct bursts in a single day (~17:14–17:19, ~17:22–17:26, ~17:52, ~18:47–18:52, plus a lone one at 21:43, all times UTC).
• Another session had 2 occurrences on an earlier date.
• A third (current) session had 4 occurrences, one of which happened during a context-compaction turn.

Each burst follows the same shape: repeated system/api_error entries with error.connection.code == "ECONNRESET" and error.connection.message == "The socket connection was closed unexpectedly.", with retryInMs backing off geometrically (≈500ms → 1.2s → 2.3s → 4.3s → 8s → ~17-37s), followed by a successful assistant message once the retry succeeds.

I initially suspected this was specific to context compaction (it happened once during compaction in the current session), but checking the transcript with the most occurrences showed only a single compact_boundary event in that entire session, and it does not overlap with any of the ECONNRESET bursts — the resets also occur during ordinary turns. So this looks like an intermittent network-level connection reset (TCP RST) between the client and the API, not something specific to the compaction/compression code path.

Impact

• Response stalls ranging from a few seconds up to several minutes per burst while retries back off.
• No data loss observed (retry logic recovers), but it's a noticeably degraded experience, especially on longer sessions.

Request

• Any guidance on what's causing the resets (client-side keep-alive/timeout handling vs. something environmental) would help.
• If this is expected to be silently recovered from, it might be worth surfacing a more visible/user-facing indicator when a burst exceeds some duration (e.g., >30s), since right now it just looks like Claude Code is hanging.