claude-code - 💡(How to fix) Fix [BUG] Persistent mid-stream ECONNRESET on large-context sessions (v1/messages?beta=true)

Preflight Checklist

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

What's Wrong?

Claude Code CLI consistently fails with API Error: Unable to connect to API (ECONNRESET) against https://api.anthropic.com/v1/messages?beta=true after exhausting its 10-retry budget, specifically on long-running turns in sessions with large accumulated context (>=6MB JSONL). These are mid-stream resets — the server has already accepted the request and begun streaming the response when the socket is RST'd. ~345 ECONNRESETs across 20+ sessions, 11 projects, 13 Claude Code versions, over 5 weeks. Ongoing as of 2026-04-20.

What Should Happen?

Long-running streaming responses on large-context sessions should complete without the connection being killed mid-stream. If the server-side has a wall-clock or stream budget that the request exceeds, Claude Code should (a) receive a clean HTTP error rather than a raw TCP RST, (b) offer to compact the session after repeated failures on the same turn rather than burning all 10 retries on a request that will never succeed, and (c) log enough detail (request-id, cf-ray, HTTP/2 stream close reason) for users to correlate with server-side logs.

Error Messages/Logs

{
    "subtype": "api_error",
    "cause": {"code":"ECONNRESET","path":"https://api.anthropic.com/v1/messages?beta=true","errno":0},
    "retryInMs": 503.10,
    "retryAttempt": 1,
    "maxRetries": 10,
    "timestamp": "2026-04-14T03:07:30.074Z",
    "sessionId": "fab7edcc-b849-41a9-8fd0-e7b667fef8d3",
    "version": "2.1.104"
  }

  Retry decay: retry-1 recovers 64%, retry-2 recovers 23%, retry-3+ near 0%. Once a large request fails 3x, retries 4–10 are wasted.

62 separate HTTP 529 overloaded_error responses (with clean headers including request-id, cf-ray) show that Anthropic's backend can return proper HTTP errors — the ECONNRESET path is a different, ungraceful failure mode (likely worker killed or LB timeout with no response).

Steps to Reproduce

1. Start a Claude Code session and work it for multiple hours with heavy tool use (file reads, grep, bash, subagents) until the session JSONL exceeds ~6MB.
2. Issue a prompt that requires a long generation or many tool-call round-trips in a single turn.
3. Observe API Error: Unable to connect to API (ECONNRESET) after retries are exhausted (~10–20 minutes of retrying).

Key data: sessions >= 6MB are 1.8% of all sessions but carry 74.6% of ECONNRESETs. Full 41KB diagnostic report with network probes, temporal analysis, hypothesis ranking, and anonymized session data is attached below.

Claude Model

Opus

Is this a regression?

I don't know

Last Working Version

No response

Claude Code Version

2.1.72, 2.1.76, 2.1.77, 2.1.86, 2.1.87, 2.1.92, 2.1.104, 2.1.105, 2.1.107, 2.1.108, 2.1.110, 2.1.112, 2.1.114

Platform

Anthropic API

Operating System

macOS

Terminal/Shell

iTerm2

Additional Information

De-identified diagnostic report prepared from ~/.claude/projects/ session logs, OS diagnostics, and live probes. Machine: macOS 26.3 on Apple Silicon iMac, ~600 Claude Code sessions logged since 2026-02, Claude Code versions 2.1.39 through 2.1.114.

1. Summary

• What: API Error: Unable to connect to API (ECONNRESET) against https://api.anthropic.com/v1/messages?beta=true, after Claude Code exhausts its 10-retry budget. Session dies mid-turn with a synthetic assistant message.
• Scale: ~345 ECONNRESET api_error records across at least 20 Claude Code sessions spanning 11 distinct projects over roughly five weeks (first: 2026-03-17, last: 2026-04-20 — see §1.1 for incremental 24 h refresh). At least 30 turns died with a synthetic <synthetic> "API Error" message (i.e., retries did not recover). 8+ sessions hit maxRetries=10. Failures are ongoing, not historical.
• Severity: Real work loss. Every synthetic error is a turn that had to be re-issued, losing partial tool-call state and burning time.
• Connect-path is healthy at rest — TCP handshake 22–29 ms, TLS 1.3 handshake 51–54 ms, handshake success rate 100% on three separate probe rounds (including a second round run at the end of this investigation). These are mid-stream resets, not connect-time failures: the server has already accepted the request and begun writing the response when the socket is RST'd.
• Top suspected cause (ranked #1): a large-context × long-running-turn failure mode. 129 of 173 errors attributable to file size (~75%) occurred on sessions >= 6 MB of accumulated context (which represent only ~1.8% of all sessions on disk). The single longest failing turn ran 20.7 minutes across 66 messages. This is exactly the shape of request that is vulnerable to (a) intermediate CGNAT/NAT conntrack eviction and (b) CDN/LB idle-stream timeouts.
• Strong secondary signal (ranked #2): system-wide network disruption in the home-ISP path is responsible for a subset of the errors — the Claude desktop app's main.log recorded net::ERR_INTERNET_DISCONNECTED on exactly the same local-hour buckets where the CLI saw its biggest error bursts (e.g., 64 disconnects / 71 CLI resets in the same local hour of 2026-04-16 07:00). That tells us some resets are not an Anthropic-side problem, but mode #1 (the large-context pattern) accounts for most errors.
• Important correction to the baseline prompt: api.anthropic.com is Cloudflare-fronted (response headers server: cloudflare, cf-ray: ...-ORD, cf-cache-status: DYNAMIC present on successful requests; Envoy upstream header present too). The edge IP (160.79.104.10 / ASN-owned 160.79.104.0/24) is Anthropic-allocated but Cloudflare announces it. Any Cloudflare-specific reset hypothesis is therefore back on the table.

1.1 Refresh — 2026-04-20 (24 h after initial report)

Report was rescanned against ~/.claude/projects/*/*.jsonl 24 hours after the initial data pull. Failure pattern is continuing, not resolved.

New activity since the initial cutoff (~2026-04-19 08:10 UTC):

New sessions added to the affected list since initial cutoff:

• 0 new projects affected (all three sessions are in projects already in the original 11-project list).
• 100% of new sessions are >= 6 MB. The 11 MB session is the largest on record — all 10 of its ECONNRESETs occurred on sessions that had already exceeded the size threshold H1 predicts.
• The new bursts show the same shape as the historical ones: tight 5–50 minute clusters on one session, ending in retry exhaustion and a synthetic error turn.
• Retry-decay curve continues to match H1: burst 2 produced 7 errors in 9 minutes (one retry attempt per error, none recovering). Burst 3 produced 13 errors in 51 minutes. Consistent with "budget won't admit this request" rather than intermittent transport flaps.

Implication: Every new data point since the report was written is consistent with H1 (large-context × long-generation mid-stream reset) and weighs further against any hypothesis that implicates a transient / one-off cause. This is a persistent, reproducible failure mode on this account, and it is continuing to happen as of the most recent data point (2026-04-20 04:29 UTC).

Live occurrence during this refresh. While rescanning the session logs and drafting this update, the live Claude Code session drafting the report itself experienced a ~5+ minute unresponsive period with no user-visible output before recovering — consistent with the same mid-stream-stall symptom described in H1. The session's ID is available on request for correlation with server-side logs.

2. Environment (de-identified)

3. Error inventory

3.1 Error codes (all api_error events across all sessions)

Other HTTP status-code errors captured in session data but not classified as api_error:

3.2 By Claude Code version (errors divided by observed session count on that version)

No clean pre/post-version cliff. Errors appear across 13 versions spanning roughly 3 months of client releases. The per-session error rate does appear higher on 2.1.87 and later (2.33 and above) than on earlier versions (0.08–0.18), but that's confounded with a change in usage pattern (user moved to larger, longer-running sessions in the same period). Not a strong regression signal; included for completeness so Anthropic can compare against release diffs.

3.3 By model

Of the 17 sessions where ECONNRESETs were actually stored:

No [1m] (1M-context) variant appeared in any error-containing session. The long-running 1M-context usage on this machine is isolated to subagent jsonl files that did not ECONNRESET. So the 1M-context model is not implicated; the Opus 4-6 and 4-7 standard-context variants fail at roughly the same rate. The outlier is the one session that spanned a 4-6 → 4-7 version change, which also happens to be the largest session on disk.

3.4 By project (enumerated as project-A .. project-K in first-seen order)

11 distinct project directories had at least one ECONNRESET. Most errors concentrate in a handful of large ongoing projects:

Errors do not cluster by project; they cluster by project size on disk, which covaries with how much active work I did in that project.

3.5 By session size bucket (the most important cut)

Bucketing the 17 sessions that actually contain ECONNRESET records against the 1,582 total sessions on disk:

Reading: 1.8% of sessions (the >= 6 MB bucket) carry 74.6% of the ECONNRESETs. That is a huge selection signal. Large accumulated context → large request body on every subsequent turn → more wire time per turn → more exposure to whatever is resetting the stream.

3.6 Retry behavior

maxRetries is always 10. Per-retry counts and recovery rates:

Retry-1 cures ~64% of cases; retry-2 drops sharply to 22.5%; after retry 2 the retries are nearly useless. Once the large request has failed three times in a row, it almost never succeeds on subsequent retries. This is strongly consistent with "the request itself is too large / too slow to ever fit in whatever idle-or-duration budget is killing the stream" — not with "transient packet loss that retries would cure."

3.7 Time-gap to preceding event

For every failing request, measured wall-clock gap between the preceding session event and the error:

Median 46 s; 90th percentile 98 s. Zero errors where the session had been idle more than 30 minutes. This falsifies the "stale overnight socket first-request fails" hypothesis — the affected sessions were all actively in use when the reset happened.

4. Temporal patterns

4.1 Per UTC day (top ten)

 2026-04-16 ██████████████████████████████████████████████████  99
 2026-04-17 ████████████████████████████████████████████████    93
 2026-04-14 ███████████████████████                              49
 2026-03-27 ██████████████                                       30
 2026-03-17 █████████████                                        28
 2026-04-18 █████                                                11
 2026-04-15 ████                                                  8
 2026-04-09 ██                                                    4
 2026-03-28 ▏                                                     1
 2026-03-30 ▏                                                     1

Roughly the whole error mass lands on a handful of days (April 14, 16, 17). This is burst behavior: 55% of errors fall within 60 seconds of another error (181 / 325). 36 distinct "bursts" (>= 2 events within 60 s).

4.2 Per local hour-of-day (Central, UTC−5)

 00 ████████████████                                16
 02 ▏                                                1
 07 ████████████████████████████████████████████████████████████████████████████████████████████████████████ 103
 08 █████████████████████████                       25
 09 ████                                             4
 10 ██████████                                      10
 11 ██████████████████████                          22
 12 ████████████                                    12
 13 ██                                               2
 14 ████████                                         8
 15 ███                                              3
 16 ████████████████████████████                    28
 18 ▏                                                1
 20 █████████████████████████                       25
 21 ███████████                                     11
 22 █████████████████████████████████████           37
 23 █████████████████                               17

Errors span the whole day. 07:00 Central dominates because one bad morning (2026-04-16) had a large burst. Removing that one day flattens the distribution, meaning there is no consistent time-of-day pattern — it's not "morning only" or "evening only."

4.3 Per weekday (UTC)

Thu (103), Fri (123), Tue (77), Sat (12), Wed (8), Sun (1), Mon (1). This tracks my actual working pattern rather than any network pattern.

4.4 Burst structure

36 bursts, 181 errors inside bursts (55%). The typical burst shape is: one turn fails, gets retried, retry fails, retry-of-retry fails — so a single underlying "bad request" can contribute 5–10 events rapid-fire. That inflates the raw count and means the unique-turn failure rate is closer to 36 bursts + ~144 singletons = on the order of 180 distinct turn failures across the period.

5. Network diagnostic results

5.1 Baseline (from prompt, ~07:50 UTC)

GET https://status.anthropic.com/api/v2/status.json
→ {"status":{"indicator":"none","description":"All Systems Operational"}}
Unresolved incidents: 0 (2026-04-19T06:27:55Z)

5.2 Mid-investigation probe

5.3 Second-round probe (end of Phase 2)

All 11 handshake attempts succeeded; remote IP was 160.79.104.10 on every attempt. No drift, no reset at handshake.

5.4 Long-lived POST probe (60 seconds of slow upload)

POST /v1/messages HTTP/2 (body written 1 byte/second for 60s)
< HTTP/2 401
< request-id: req_011CaCnTouozV24ACN1UypoT
< server: cloudflare
< cf-ray: 9eea680afe7cbd1f-ORD
< x-envoy-upstream-service-time: 77
{"type":"error","error":{"type":"authentication_error","message":"invalid x-api-key"}}

The server stayed on the line for the full 60 seconds and returned a clean 401. Confirms that idle-during-upload does not trigger a mid-stream reset on this endpoint. The reset mechanism is specific to streaming response bodies, not slow uploads. Confirms Cloudflare + Envoy upstream in the serving path.

5.5 DNS

api.anthropic.com.  A    160.79.104.10
api.anthropic.com.  AAAA 2607:6bc0::10
NS: gemma.ns.cloudflare.com, nico.ns.cloudflare.com

5.6 Ping (10 packets)

10 packets transmitted, 10 packets received, 0.0% packet loss
min/avg/max/stddev = 13.753/21.961/27.084/3.666 ms

Healthy; small stddev.

5.7 Traceroute (ASN boundaries only; intermediate hop IPs omitted)

 1   home router (RFC 1918)
 2   cable-modem (RFC 1918)
 3   Comcast CGNAT (RFC 6598 / 100.64.0.0/10)
 4-7 Comcast regional aggregation (AS7922)
 8-9 Comcast iBone peering to Cloudflare (AS7922 → AS13335)
10-11 Cloudflare edge (AS13335)
12   160.79.104.10 target (announced by Cloudflare, Anthropic prefix)

Notable: hop 3 is CGNAT (RFC 6598), so Comcast is NAT'ing the egress. Long-lived TCP flows are exposed to Comcast's CGNAT conntrack timer, which is not externally tunable.

5.8 TLS

TLSv1.3 with TLS_AES_256_GCM_SHA384 (handshake probe) and in-band AEAD-CHACHA20-POLY1305-SHA256 (curl baseline); cert issuer C=US, O=Google Trust Services, CN=WE1, subject CN api.anthropic.com, verify return code 0.

6. Link-event correlation (local Wi-Fi / network flaps)

6.1 Claude Code CLI ECONNRESET bursts vs Claude desktop-app main.log network disconnects

I had not expected the desktop app's log to be informative, but it produced the cleanest cross-source signal in the whole investigation. Same machine, same network, different process.

The desktop app logs net::ERR_NETWORK_CHANGED and net::ERR_INTERNET_DISCONNECTED to ~/Library/Logs/Claude/main.log whenever Chromium's network stack sees a local connectivity flap. Aligning by local hour:

The 04-16 07:00 event in particular — 64 desktop-app ERR_INTERNET_DISCONNECTED events and 71 CLI ECONNRESETs in the same local hour — is a local-side network disruption, not an Anthropic server issue. Two independent processes on two different network stacks (Node/undici for the CLI, Chromium for the desktop app) both saw loss at the same wallclock moment.

6.2 macOS log show link events and live Wi-Fi state

Initially skipped for lack of sudo; follow-up capture run with elevated privileges.

Live Wi-Fi state (sudo wdutil info, captured 2026-04-19 08:29:46 UTC):

Wi-Fi debug log (sudo log show --last 72h --info --debug --predicate 'subsystem == "com.apple.wifi"', filtered for deauth|disassoc|reassoc|roam|beacon.?(miss|loss)|link.?(down|up)|disconnect|wake|power|bt.?coex):

Zero matches in 72 hours.

This is now an affirmative result, not an artifact of missing privileges: with --info --debug and sudo, macOS's unified log would surface deauth / disassoc / roam / beacon-loss events if any had been recorded. None were. That meaningfully shifts the interpretation of the 22% local-correlation signal from §6.1:

• The ERR_INTERNET_DISCONNECTED events that Chromium logged at the same local hours as CLI ECONNRESET bursts are not caused by Wi-Fi link-layer drops on this machine.
• They are therefore TCP/IP-layer or higher — consistent with CGNAT conntrack eviction, ISP-edge flaps, or router NAT pressure (hypothesis H2), not with physical Wi-Fi instability.
• The −66 dBm / 28 dB SNR is merely a weak compounding factor on long flows (higher retransmit rate under marginal signal), not a root cause.

6.3 Net: some fraction of ECONNRESETs are local-network-caused

71 / 325 = ~22% of CLI ECONNRESETs fall in a local hour where the desktop app also recorded ERR_INTERNET_DISCONNECTED. That's a lower bound — the desktop app only logs when it's running, and it wasn't running for most of the sample. The true "local-network-caused" share is plausibly higher. But even under generous assumptions, the majority of resets are NOT co-timed with any desktop-app disconnect event, which means there is almost certainly a second failure mode not explained by local connectivity — see hypothesis #1 below.

7. Ranked hypotheses

H1 — Anthropic edge / Cloudflare / LB terminates long streaming responses on large-context requests (most likely primary cause of the 75%+ of errors that don't co-time with local net flaps)

Mechanism. Session has accumulated >6 MB of conversation history. Every subsequent turn sends that whole context as the request body, and the model's response to a big request can run multi-minute. The connection is a single HTTP/2 stream held open for the duration of the generation. Somewhere in Cloudflare → Envoy → inference worker, a per-request wall-clock budget or per-stream idle timer expires, and instead of a clean 5xx the stream is TCP RST'd, which surfaces as ECONNRESET in Node's undici client.

Evidence in this data.

• 74.6% of errors come from the >= 6 MB session-size bucket, which is 1.8% of sessions on disk.
• Errors cluster in bursts (55% within 60 s of another) because retries of the same giant request hit the same budget again.
• Retry-1 success rate is 64% but retry-2+ is 5–22% — once the request has timed out twice, no amount of retrying helps. Classic "this request will never fit."
• Longest failing turn is 20.7 minutes / 66 messages. Second longest 16.4 min / 237 messages. Turns of this length are well beyond typical CDN / LB idle-timeout defaults.
• The 1M-context Opus variant (claude-opus-4-7[1m]) was in active use during at least some of the error-containing sessions (per user testimony; the on-disk message.model field does not distinguish the 1M tier from standard context, so this cannot be confirmed from logs alone). On the 1M tier, both the request payload and the potentially-distinct backend routing could compound the failure mode — making the 1M variant a strong candidate for the dominant failure surface.
• Median gap from preceding event to failure is only 46 s, 90p 98 s. Sessions are not idle; the socket is not stale. This isn't a first-request-after-nap failure.
• Mid-request-header cf-ray, server: cloudflare, x-envoy-upstream-service-time on successful responses confirms the architecture.
• 62 separate HTTP 529 overloaded_error responses (with x-should-retry: true) already seen for this account — Anthropic's backend does acknowledge overload sometimes with a clean HTTP response, which makes the silent TCP-RST path look like a different failure mode (maybe the worker is killed ungracefully when it exceeds budget rather than returning a proper 529/503).

What would falsify.

• If compacting a 9 MB session down to 1 MB and re-issuing the same prompt completes cleanly, H1 is strongly supported.
• If the 1 MB compacted session also resets, H1 is weakened.
• If Anthropic confirms no per-stream or per-request wall-clock budget exists at the edge/LB that could produce silent RSTs, H1 is falsified.

What Anthropic can do to confirm.

• Correlate the session IDs / request-id headers in Appendix A with edge/LB logs to see whether the RSTs are Cloudflare → origin, origin → inference worker, or inference worker → CPU-killed.
• Expose the x-request-id response header to the Claude Code client even on early-RST so users can include it in bug reports.

H2 — Home Comcast CGNAT / consumer router conntrack eviction on long-lived streams (secondary cause; explains the ~22% that co-time with local disconnects and possibly more)

Mechanism. Hop 3 on the traceroute is an RFC 6598 CGNAT address (100.64.0.0/10 range). Comcast's CGNAT and most consumer routers maintain a conntrack table with a finite TCP idle timeout (typical defaults: 300 s – 7200 s, but entries can also be evicted under pressure before timeout). A single streaming HTTP/2 response can have minutes of quiet wall-clock inside it while the model generates tokens. If the conntrack entry is evicted mid-stream, the router / CGNAT silently drops subsequent packets, the server keepalives fail, and the server RSTs the half-open connection.

Evidence in this data.

• Desktop-app main.log recorded simultaneous ERR_INTERNET_DISCONNECTED / ERR_NETWORK_CHANGED events alongside ~22% of CLI errors (per-hour alignment), indicating something local is breaking connectivity for both processes at the same time.
• Ping / handshake at rest is perfect but that doesn't exercise a long-lived flow.
• Wi-Fi SNR is 28 dB (mediocre 5 GHz on channel 157), which could contribute to occasional link-layer retransmits on long flows — but debug-level Wi-Fi logs for the last 72 h show no deauth/disassoc/roam/beacon-loss events, so the Wi-Fi link itself is not dropping. Whatever the local cause is, it sits at the TCP/IP layer or above (consistent with CGNAT conntrack or router NAT pressure), not at the physical link layer.

What would falsify.

• If moving to Ethernet eliminates the ECONNRESETs, or if running Claude Code through Tailscale (which changes the CGNAT path) eliminates them, H2 is supported.
• If Anthropic logs show the RST came from their side first (FIN / RST initiated by Envoy / origin), H2 is falsified.

What Anthropic can do to help.

• Implement more aggressive TCP keepalive on the streaming socket in Claude Code's HTTP client. Default Node undici does not set SO_KEEPALIVE with short intervals. Even a 30 s keepalive probe would refresh the CGNAT entry and catch half-open sockets much sooner, converting this class of failure from ECONNRESET (unclear who's to blame) into a cleaner "connection lost" that retry can cure.
• Surface a CLAUDE_CODE_TCP_KEEPALIVE_MS env var so I can tune this myself.

H3 — Comcast / ISP-level connectivity instability during peak hours (contributes to H2's 22%)

Mechanism. Residential Comcast in Chicago has well-documented evening/morning reliability issues (peak-hour congestion, node rebalancing). My household shares an Xfinity xFi Advanced Gateway modem/router. A brief backbone hiccup or node rebalance would disconnect all open TCP flows.

Evidence in this data.

• main.log showed 64 ERR_INTERNET_DISCONNECTED in a single hour on 2026-04-16 07:00 Central. That is not "one stream reset" — that is "the internet went away and came back."
• Peak local hours for errors (07, 11, 16, 20, 22 Central) correlate with typical residential Comcast congestion patterns.

What would falsify. Running Claude Code from a different ISP / cellular tether during the same time window and seeing the same reset pattern would falsify it. (Not done in this investigation.)

What Anthropic can do. Nothing — this is an ISP issue. But Anthropic's retry logic should be better at recovering from a 5-second connectivity gap. The current retry schedule is retrying inside the window the ISP is still down.

H4 — Claude Code HTTP/2 flow-control / stream-concurrency quirk under large requests (possible contributor)

Mechanism. HTTP/2 connection-level flow control has SETTINGS_INITIAL_WINDOW_SIZE and per-stream windows. If a very large POST body is being sent and the server hasn't issued enough WINDOW_UPDATE frames, or if the response body is being read slowly by the client during tool-call processing, stream can stall. Some middleboxes RST HTTP/2 streams that stall for too long.

Evidence in this data.

• Long-running turns (20 minutes, 200+ messages in-turn) were the ones that failed. Those are exactly when multiple tool-calls / sub-agents are running and the client might be blocking before reading the next chunk.
• 401 long-upload probe completed fine, so basic flow control is OK at small data volumes; the failure regime is specific to large data plus long duration.

What would falsify. Disable HTTP/2 in the client (force HTTP/1.1 only) and see if reset rate drops.

What Anthropic can do.

• Expose an HTTP/1.1 fallback env var in Claude Code.
• Log the specific HTTP/2 stream-close reason (GOAWAY? RST_STREAM with error code? TCP RST?) instead of collapsing everything to ECONNRESET.

H5 — Claude Code client regression in 2.1.87+ (weak; include for completeness)

Mechanism. Normalized error-per-session rate rose from 0.08–0.18 on versions up through 2.1.72 to 2.33+ on 2.1.87 and beyond. Could be a regression in retry/streaming code.

Evidence in this data.

• Normalized ratio rises post-2.1.87.

Evidence against.

• Session sizes also grew substantially in that same window (I started doing larger multi-hour projects). Confounded with H1.
• Errors are spread across 13 versions up through the current 2.1.114, not a single version.

What would falsify. Pin to 2.1.72 and see if reset rate drops while running a >= 6 MB session.

H6 — Wi-Fi roaming / association events (ruled out)

Mechanism. Wi-Fi reassociation drops TCP.

Evidence in this data.

• Debug-level log show --info --debug over the full Wi-Fi subsystem for the last 72 h (sudo-elevated follow-up capture) returned zero deauth / disassoc / reassoc / roam / beacon-miss / link-down events. This is an affirmative null, not a missing-privileges artifact.
• Bluetooth-Wi-Fi coexistence profile is disabled on both 2.4 and 5 GHz bands per wdutil info, ruling out BT coex as a drop mechanism.
• Machine is a desktop iMac on Wi-Fi — it doesn't roam between APs.
• SNR 28 dB / signal −66 dBm is mediocre but does not by itself cause the kind of connection reset seen here.

Ruled out as a contributor.

H7 — IPv6 path issue (not implicated)

AAAA record is returned (2607:6bc0::10) but curl defaulted to IPv4 (160.79.104.10) on all 11 probes and got clean responses. Not pursued.

H8 — User-behavior hypotheses

• Very large accumulated contexts → see H1, SUPPORTED by data.
• Heavy 1M-context Opus usage → UNDETERMINED — plausibly supported. The [1m] suffix does not appear in the message.model field of any session jsonl (error-containing or otherwise), so the structured log cannot tell us whether 1M was active for a given failing turn. However, the user reports that the 1M-context Opus variant was in use during at least some of the error-containing sessions. This re-opens the hypothesis: failing turns on the 1M variant would involve (a) larger total request payloads and (b) potentially a different backend routing / resource tier than the standard-context path, either of which could compound the mid-stream-reset failure mode described in H1. This is a strong candidate for Anthropic-side investigation and has been added to the Asks section (log effective context-window tier per request so users can self-diagnose).
• Stale overnight sessions → REJECTED: 0 errors with gap > 30 min; median gap 46 s.
• Many concurrent subagents → WEAKLY SUPPORTED: failing sessions were long turns with many messages (up to 237, 468 msg messageCounts in the turn_duration data), consistent with heavy tool-call parallelism.
• Hooks / MCP wrapping API → REJECTED: 0 user-level hooks, 0 user-level MCP servers.
• bypassPermissions mode → unrelated mechanism; it affects approval prompts, not HTTP transport.
• /loop / autonomous skills → Some affected sessions used autoresearch-style skills that iterate many turns; likely contributor to large context growth (indirect support for H1).

8. Asks for Anthropic

The specific, actionable asks — listed in rough order of impact — are:

1. Surface the request-id / cf-ray header on ECONNRESET. Right now the client logs only {"code":"ECONNRESET","path":"...messages?beta=true","errno":0}. If the TCP RST happens after response headers have been received, keep them. If it happens before, try to capture the cf-ray from a probe request triggered at the same edge. This would let me correlate specific turn failures to Anthropic's server-side logs. See Appendix A for what we have now — it's useless for cross-correlation.
2. Log why the stream closed, not just the OS-level errno. Was it an HTTP/2 RST_STREAM with a specific error code? A GOAWAY from the server? A FIN then RST? A raw TCP RST with no preceding FIN? Node / undici has access to this. Claude Code is collapsing it all to ECONNRESET.
3. Confirm for the record: are long-running messages?beta=true streaming generations subject to a Cloudflare proxy_read_timeout / Envoy route.timeout wall-clock limit? If yes, what is it, and does it count silent generation time or only idle time? This would let users self-diagnose whether they're hitting a known cap.
4. Document whether the ?beta=true query path routes differently than non-beta. Every single API call Claude Code makes from this machine is to ?beta=true (476/476 requests in the session log, including all 325 failed ones). That means the 100%-on-beta pattern is baseline, not a failure indicator — I cannot test beta-vs-non-beta from the client side because Claude Code never issues non-beta requests. If ?beta=true does in fact share the same edge / Envoy / LB config and same timeouts as non-beta (i.e., it is purely a feature-gate flag), please confirm so this line of inquiry can be closed. If it routes differently, please document how. Note also that 1M-context Opus is gated behind anthropic-beta, so users cannot opt out of beta=true without losing the 1M tier.
5. Expose CLAUDE_CODE_TCP_KEEPALIVE_MS (or equivalent) as a client env var. Setting SO_KEEPALIVE with a short interval would refresh intermediate NAT conntrack entries (see H2) and convert some silent RSTs into cleanly-detected dead-socket events that the existing retry code can actually recover from.
6. Consider providing an HTTP/1.1 fallback flag (CLAUDE_CODE_FORCE_HTTP1=1) for testing whether HTTP/2 flow-control is involved (see H4).
7. Consider a --on-error=compact behavior so that after N consecutive ECONNRESETs on the same turn, Claude Code offers to compact the session rather than silently dying with a synthetic error. For a 9 MB session that has failed 10 times, another retry will not help.
8. Correlate my account's request-id / cf-ray headers with your internal edge, Envoy, and inference-worker logs to determine the specific origin of the RSTs (Cloudflare edge? Envoy route timeout? Worker SIGKILL?). I can supply the Anthropic org ID out of band — see "Reply-only follow-up" at the end of this document.
9. Record the effective context-window tier (standard vs 1M) in Claude Code's session jsonl and in the request metadata exposed to users. Right now the message.model field is written as claude-opus-4-7 whether the 1M-context variant is active or not, so users cannot self-diagnose whether a failing turn was on the 1M tier. This matters for this issue specifically because the 1M variant may route to a different backend tier with different timeout behavior than standard context — which would let you split this failure mode by tier and see whether the dominant failure surface is 1M-specific.
10. If the 1M-context Opus tier uses a different edge / Envoy / inference-worker routing path than the standard-context path, please confirm and document. Several failing sessions in this data set were run on the 1M variant. If 1M has different per-request wall-clock limits, pool sizing, or connection-handling semantics, that is likely material to the root cause.

9. Commands that were skipped or failed

No other commands failed; no ambiguous outputs.

Appendix A — Representative raw api_error JSONL records

Paths / cwd / slug fields stripped; sessionId, request-id, version, and structural fields retained.

{
  "subtype": "api_error",
  "level": "error",
  "cause": {"code":"ECONNRESET","path":"https://api.anthropic.com/v1/messages?beta=true","errno":0},
  "error": {"type":null,"cause":{"code":"ECONNRESET","path":"https://api.anthropic.com/v1/messages?beta=true","errno":0}},
  "retryInMs": 503.10102399147405,
  "retryAttempt": 1,
  "maxRetries": 10,
  "timestamp": "2026-04-14T03:07:30.074Z",
  "sessionId": "fab7edcc-b849-41a9-8fd0-e7b667fef8d3",
  "version": "2.1.104",
  "gitBranch": "HEAD"
}

{
  "subtype": "api_error",
  "cause": {"code":"ECONNRESET","path":"https://api.anthropic.com/v1/messages?beta=true","errno":0},
  "retryInMs": 557.0120175956872,
  "retryAttempt": 1,
  "maxRetries": 10,
  "timestamp": "2026-04-14T02:08:03.510Z",
  "sessionId": "4c4f31b8-b773-42d2-89eb-79eafe74e87a",
  "version": "2.1.92",
  "gitBranch": "main"
}

{
  "subtype": "api_error",
  "error": {},
  "retryInMs": 611.7190747656514,
  "retryAttempt": 1,
  "maxRetries": 10,
  "timestamp": "2026-04-14T02:19:48.195Z",
  "sessionId": "4c4f31b8-b773-42d2-89eb-79eafe74e87a",
  "version": "2.1.92",
  "gitBranch": "main"
}

{
  "subtype": "api_error",
  "cause": {"code":"ECONNRESET","path":"https://api.anthropic.com/v1/messages?beta=true","errno":0},
  "retryInMs": 578.1537664332689,
  "retryAttempt": 1,
  "maxRetries": 10,
  "timestamp": "2026-04-14T02:14:00.186Z",
  "sessionId": "4c4f31b8-b773-42d2-89eb-79eafe74e87a",
  "version": "2.1.92",
  "gitBranch": "main"
}

{
  "subtype": "api_error",
  "cause": {"code":"ECONNRESET","path":"https://api.anthropic.com/v1/messages?beta=true","errno":0},
  "retryInMs": 586.2500581048495,
  "retryAttempt": 1,
  "maxRetries": 10,
  "timestamp": "2026-04-14T02:15:21.968Z",
  "sessionId": "4c4f31b8-b773-42d2-89eb-79eafe74e87a",
  "version": "2.1.92",
  "gitBranch": "main"
}

Example 529 (overloaded_error) response for reference — this is what a clean Anthropic-side failure looks like, in contrast to the silent ECONNRESET:

{
  "timestamp": "2026-03-17T21:48:33.224Z",
  "sessionId": "aa563665-c927-4cf9-bdb6-9367059272f7",
  "version": "2.1.72",
  "status": {
    "status": 529,
    "headers": {
      "request-id": "req_011CZ9PWLnL8MKuGL9LbWm4z",
      "anthropic-organization-id": "[REDACTED — supplied separately]",
      "server": "cloudflare",
      "x-envoy-upstream-service-time": "329",
      "cf-ray": "9ddf33cfda64f790-ORD",
      "x-should-retry": "true"
    },
    "error": {
      "type": "error",
      "error": {"type":"overloaded_error","message":"Overloaded. https://docs.claude.com/en/api/errors"}
    }
  }
}

Appendix B — Command outputs (redacted)

ProductName:  macOS
ProductVersion:  26.3
BuildVersion:  25D125
Darwin [HOSTNAME] 25.3.0 Darwin Kernel Version 25.3.0: Wed Jan 28 20:49:24 PST 2026; root:xnu-12377.81.4~5/RELEASE_ARM64_T8132 arm64
~/.local/bin/claude
2.1.114 (Claude Code)
Node: v24.13.1
SHELL=/bin/zsh

Active interface: en1 (Wi-Fi, MAC redacted)
IPv4: RFC1918 (redacted)
Default gateway: RFC1918 (redacted)

DNS:
  nameserver[0] : 75.75.75.75   (Comcast)
  nameserver[1] : 75.75.76.76   (Comcast)

Proxy:
  ExceptionsList: [*.local, 169.254/16]
  FTPPassive: 1
  (no explicit HTTP/HTTPS proxy)

Env proxy: (none set)

Public egress (ipinfo):
  ip: 98.63.x.x (first two octets kept per policy)
  hostname: [REDACTED Comcast residential PTR]
  city: Chicago
  region: Illinois
  org: AS7922 Comcast Cable Communications, LLC

A:    160.79.104.10
AAAA: 2607:6bc0::10

Ping 10/10 received, 0% loss, avg 22 ms

Traceroute (hops 1-2 are RFC1918 private, hop 3 is RFC6598 CGNAT, middle
hops are Comcast regional → Comcast iBone peering, final hops are Cloudflare
edge / Anthropic origin):
 1   [home router, RFC1918]
 2   [cable modem, RFC1918]
 3   [Comcast CGNAT, 100.64.0.0/10]
 4-5 [Comcast regional Chicago PoP]
 6-7 [Comcast aggregation]
 8-9 [Comcast iBone → Cloudflare peering]
 10  [Cloudflare edge, 141.101.x.x]
 11  [Cloudflare edge, 141.101.x.x]
 12  160.79.104.10 (api.anthropic.com)

Apps matching {snitch,lulu,radio silence,murus,vallum,hands off,charles,proxyman,wireshark,tailscale,wireguard,openvpn,nord,express}: (none)
Processes matching {vpn,proxy,wireguard,openvpn,tailscale,zerotier,cloudflared,mitmproxy,charles,proxyman,pritunl,nord,expressvpn}: (none)
pgrep tailscale: (none)
pfctl: still not captured (sudo aborted after three bad password attempts in follow-up run; see §9)

Interface: en1, 802.11ac, 5 GHz channel 157, 80 MHz
Signal: -66 dBm / Noise: -94 dBm (28 dB SNR)
Tx rate: 520 Mbps, MCS Index 5, NSS 2, Guard Interval 400
CCA (channel utilization): 30%
PHY modes supported: a/b/g/n/ac/ax (6E-capable hardware, not active)
Security: WPA2 Personal
Country: US
BT Coex Profile 2.4 GHz: Disabled
BT Coex Profile 5 GHz:   Disabled
IPv6: link-local only (no global IPv6 — API traffic all over IPv4)
DNS resolvers: 75.75.75.75 / 75.75.76.76 (Comcast public)
Active Bluetooth devices: 1 (HID mouse; low-bandwidth)
BSSID/SSID/MACs: [REDACTED]

sudo log show --last 72h --info --debug \
  --predicate 'subsystem == "com.apple.wifi"' --style compact \
  | grep -iE 'deauth|disassoc|reassoc|roam|beacon.?(miss|loss)|link.?(down|up)|disconnect|wake|power|bt.?coex'

(0 matches)

Interpretation: debug-level Wi-Fi subsystem logging was elevated via sudo and still returned zero link-change events across 72 hours. Affirmative null — Wi-Fi link layer is not dropping.

subject=CN=api.anthropic.com
issuer=C=US, O=Google Trust Services, CN=WE1
Protocol: TLSv1.3
Cipher: TLS_AES_256_GCM_SHA384 (openssl) / AEAD-CHACHA20-POLY1305-SHA256 (curl)
ALPN: h2 negotiated (curl); openssl s_client run without -alpn shows none
verify return code: 0

~/.claude/settings.json top-level keys:
  enabledPlugins  -> { "swift-lsp@claude-plugins-official": true }
  voiceEnabled    -> boolean
  skipDangerousModePermissionPrompt -> true
  permissions     -> { "defaultMode": "bypassPermissions" }
  (no mcpServers, no hooks, no env)

~/.claude/settings.local.json top-level keys:
  (minimal; no mcpServers, no hooks, no env)

Per-project .claude/settings.json inspected (counts only):
  one project: permissions block only
  one project: enableAllProjectMcpServers, enabledMcpjsonServers, disabledMcpjsonServers, deniedMcpServers, permissions
  one project: mcpServers (names redacted)
  All other projects: no .claude/settings.json
  Total MCP servers active in any affected session: unknown; none were implicated in stack traces.

2026-04-17 12:13:15 [error] [sessions-bridge] Poll error, backing off: net::ERR_NETWORK_CHANGED
2026-04-17 12:13:17 [error] [sessions-bridge] Poll error, backing off: net::ERR_INTERNET_DISCONNECTED
2026-04-17 12:13:21 [error] [sessions-bridge] Poll error, backing off: net::ERR_INTERNET_DISCONNECTED
2026-04-17 12:13:29 [error] [sessions-bridge] Poll error, backing off: net::ERR_INTERNET_DISCONNECTED
2026-04-17 12:13:45 [error] [sessions-bridge] Poll error, backing off: net::ERR_INTERNET_DISCONNECTED
2026-04-17 12:13:53 [error] Failed to fetch blocklist: Error: net::ERR_INTERNET_DISCONNECTED
2026-04-17 12:13:53 [error] Failed to check allowlist status: Error: net::ERR_INTERNET_DISCONNECTED
2026-04-17 12:13:58 [error] [growthbook] network error: Error: net::ERR_INTERNET_DISCONNECTED
2026-04-17 12:14:15 [error] [sessions-bridge] Poll error, backing off: net::ERR_INTERNET_DISCONNECTED
2026-04-17 18:46:35 [error] [sessions-bridge] Poll error, backing off: This operation was aborted
2026-04-17 18:46:51 [error] [sessions-bridge] Poll error, backing off: This operation was aborted
2026-04-17 18:46:53 [error] [sessions-bridge] Poll error, backing off: net::ERR_INTERNET_DISCONNECTED
...

baseline round (from prompt, ~07:50 UTC):
  1  HTTP 405  total=79ms  connect=27  tls=54  ttfb=78
  2  HTTP 405  total=91ms  connect=29  tls=51  ttfb=91
  3  HTTP 405  total=76ms  connect=22  tls=53  ttfb=76

mid-investigation (sequential, 5s spacing):
  1  HTTP 405  total=77ms  connect=27  tls=52  ttfb=77
  2  HTTP 405  total=85ms  connect=20  tls=55  ttfb=83
  3  HTTP 405  total=90ms  connect=28  tls=64  ttfb=90
  4  HTTP 405  total=81ms  connect=25  tls=56  ttfb=81
  5  HTTP 405  total=68ms  connect=17  tls=44  ttfb=68

end-of-phase-2 (after all other diagnostics, 3s spacing):
  1  HTTP 405  total=95ms  connect=26  tls=58  ttfb=95
  2  HTTP 405  total=88ms  connect=29  tls=62  ttfb=87
  3  HTTP 405  total=77ms  connect=22  tls=50  ttfb=77

Remote IP served on all 11 probes: 160.79.104.10  (no drift)

HTTP/2 401
request-id: req_011CaCnTouozV24ACN1UypoT
server: cloudflare
cf-ray: 9eea680afe7cbd1f-ORD
x-envoy-upstream-service-time: 77
body: {"type":"error","error":{"type":"authentication_error","message":"invalid x-api-key"}}
Total elapsed: 60.46s (connection held open across the full upload)
Result: clean 401 — server stayed alive for the entire upload window; no reset.

Total api_error rows: 325
All 325 are code=ECONNRESET
Distinct sessions with at least one ECONNRESET: 17
Distinct sessionIds referenced in error records: 33
Distinct projects affected: 11 (enumerated project-A .. project-K)
Distinct Claude Code versions seen in error records: 13