Intermittent ECONNRESET / Connection error on /v1/messages — auth OK, transport-level reset, 3 macOS machines

Summary

Persistent intermittent ECONNRESET / "Connection error" on /v1/messages across 3 macOS machines (2× headless Mac mini + 1× MacBook Air), all logged into the same account. A 4th machine (Windows PC) on the same network/WiFi does not exhibit it. The errors are transport-level (auth succeeds on every attempt), so this appears to be a server/edge connection issue rather than a client auth or local network problem.

Symptom

On each failing request:

1. [API:auth] OAuth token check starting → complete — succeeds every time (not auth-related)
2. [API REQUEST] /v1/messages ... dispatched
3. ~40ms later: [ERROR] API error (attempt N/16): undefined Connection error.
4. Final: code=ECONNRESET, message=The socket connection was closed unexpectedly

Retries eventually recover, but bursts can exhaust the retry budget and abort the turn.

What we ruled out (with evidence)

• Not auth / token: OAuth token check completes successfully on every single attempt across all logs.
• Not local network: single curl (both IPv4 and IPv6) to api.anthropic.com from an affected machine succeeds 20/20, fast TLS handshake.
• Not egress path: routing one affected machine's traffic through a separate SSH SOCKS5 tunnel (different egress IP) did not stop the resets.
• Not multi-device credential race: each machine has its own independent local .credentials.json (separate files, separate disks, no shared/networked storage).

Environment

• Client versions observed: 2.1.199, 2.1.196, 2.1.179
• CLAUDE_CODE_RETRY_WATCHDOG=1 and CLAUDE_CODE_MAX_RETRIES=15 are set and confirmed active (retry counter shows /16)
• macOS (Apple Silicon), installed via Homebrew cask; Windows PC unaffected
• Model: claude-opus-4-8[1m]

x-client-request-id samples for server-log lookup

• 40bad3a9-c066-4e2a-8bf5-5ad34846cc0e (client flagged this one as "give this to the API team for server-log lookup")
• cebf6335-0267-4259-81c4-9d8652d40c74
• a748c52a-58ea-4b23-b493-dd83da11e82b
• 23efc0a0-40e1-4f11-b954-5171f5bc16ad
• fbd1203c-dded-4b1f-baf0-c3defaa89659
• 850cd93f-014c-4db6-a365-0c498f2fb7eb

Timestamps: 2026-07-03 05:27–05:30 UTC and 07:14–07:15 UTC.
Source contexts: repl_main_thread and away_summary (forked agent).

Question

Can the team look up these request IDs server-side to determine where the connection is being reset (edge/LB/backend)? Happy to provide full debug logs.