`API Error: The socket connection was closed unexpectedly` — packet captures show server-initiated FIN mid-stream (10 incidents, requestIds included)

[raphaelabreu1]

Summary

Claude Code intermittently kills active turns with:

API Error: The socket connection was closed unexpectedly. For more information, pass `verbose: true` in the second argument to fetch()

This happens ~8–18 times per day under heavy interactive use. I instrumented the environment (rotating tcpdump + ss socket-state logging + a transcript watcher) and captured 10 incidents with full packet evidence, across four different sessions/windows. All 10 show the same signature:

The remote side closes the TCP connection with a clean FIN while the response is actively streaming. The CLI surfaces the error 3–105 ms after the FIN and the turn is lost; a fresh connection opened immediately afterwards works fine.

This is not the usual "stale idle connection" story — evidence below.

Environment

• Claude Code 2.1.145 → 2.1.173 (reproduces across all versions in this window; the captured incidents ran 2.1.172 and 2.1.173)
• VS Code Dev Container on Docker Desktop (kernel 6.12.x-linuxkit), Debian 11
• Direct connection to api.anthropic.com (160.79.104.10) — DNS resolution, TLS certificate (CN=api.anthropic.com, Google Trust Services) and ~40 ms round-trip verified clean; no proxy / no MITM on this path, no HTTP(S)_PROXY set
• TCP keepalive is enabled on the CLI's sockets (~50 s timer, verified via ss -o) — so this is not the missing-SO_KEEPALIVE scenario

Signature (identical in 10/10 captured incidents)

1. Server-initiated, graceful FIN on the exact TCP connection carrying the in-flight request. Never an RST from a middlebox, never a client-side close, zero retransmissions before the event.
2. Mid-stream: the request body (1–2.5 MB) had been fully ACKed seconds earlier and the SSE response was actively streaming — 7–20 KB already delivered and content blocks already persisted by the CLI — when the FIN arrived. No terminal SSE event / error frame was received (otherwise the CLI would have surfaced that instead).
3. Selective: other pooled connections to the same destination remained ESTABLISHED through the event (verified in 5-second ss snapshots). In incident AWS Bedrock support #6, per-PID socket attribution shows the FIN hit exactly the connection owned by the requesting CLI process while connections owned by two other concurrently running claude processes survived untouched. This rules out local NAT, Docker networking, or machine-level network failure.
4. Instant recovery: the CLI opens a new connection within ~20 ms and the next request succeeds. The cost is the lost turn — partial response discarded, user must re-prompt.

Four incidents (#4, #7, #8, #10) additionally captured server-side drain waves — batches of FINs hitting several pooled connections (across multiple independent CLI processes) within a few hundred ms to ~90 s. In incident #4 the wave included one FIN immediately followed by RST (win 0) and one connection where ~26 KB of in-flight client upload was answered with a burst of 18 RSTs. In every wave, only the connections with an in-flight stream surfaced user-visible errors; idle ones died silently. Incidents #7, #8 and #9 fired at second :54 of nearby minutes (01:19:54, 01:20:54, 01:22:54 UTC) — a stable 60 s sweep phase — while #10 broke the phase, so the closes recur at minute-scale intervals with a non-fixed phase.

Two further data points: (a) during a 14-minute burst (5 incidents, 01:10–01:25 UTC on 2026-06-12), status.claude.com reported all components operational — this is chronic, sub-threshold behavior, not a declared outage; (b) in some incidents the CLI's retry recovered the turn transparently, in others the turn was lost and required a manual re-prompt — the damage depends on where in the turn the FIN lands.

Traceable requestIds (UTC)

#	requestId	Error logged at	FIN → error gap
1	req_011CbxEk13e5XAKmG4GwvQw3	2026-06-11 22:10:34.909Z	24 ms
2	req_011CbxHiBmrXDFWLrBKLHLCL	2026-06-11 22:49:39.819Z	2.4 ms
3	req_011CbxKGVEbLhFv3W5TxTdRz	2026-06-11 23:10:40.124Z	105 ms
4	req_011CbxKexjRqhJsHaxXShsT7	2026-06-11 23:15:09.491Z	3 ms
5	req_011CbxMiTSti9KUcdoiQDZDi	2026-06-11 23:42:12.223Z	12 ms
6	req_011CbxUTz53C6nVahGAygovR	2026-06-12 01:10:55.601Z	17 ms
7	req_011CbxV68JtDnpPGRCf56ED2	2026-06-12 01:19:54.074Z	10 ms
8	req_011CbxVFutYvCCpvfgLZ4KYo	2026-06-12 01:20:54.067Z	50 ms
9	req_011CbxVPtdsJpnjd58E1b2yS	2026-06-12 01:22:54.575Z	6 ms
10	req_011CbxVWHA7aD7ux6svfT4fc	2026-06-12 01:24:24.772Z	5 ms

Example — incident #3, packet-level timeline

23:09:48.214  Out  172.20.0.4.54120 > 160.79.104.10.443  [S]            ← connection opened (new user turn)
23:09:48.223  In   160.79.104.10.443 > 172.20.0.4.54120  [S.]
              ... ~1.4 MB request uploaded, fully ACKed, zero retransmits ...
23:10:40.012  (CLI persists streamed assistant content — response is flowing, ~15 KB down)
23:10:40.019  In   160.79.104.10.443 > 172.20.0.4.54120  [F.]           ← SERVER closes, mid-stream
23:10:40.019  Out  172.20.0.4.54120 > 160.79.104.10.443  [F.]           ← client acknowledges close
23:10:40.124  CLI: "API Error: The socket connection was closed unexpectedly..."

(172.20.0.4 is the container's private address.)

Frequency / what was ruled out

Parsed isApiErrorMessage entries across 23 days of local session transcripts: 200 errors / 171 incidents.

• Not idle-related: 87/171 incidents occurred < 5 s after previous API activity (mid-task); only 7 after > 1 min.
• Not a version regression: uniform across 2.1.145 → 2.1.173.
• Not local concurrency: error rate per session-minute is the same whether 1 or 2+ Claude Code windows are active (27.9 vs 24.7 errors/1000 session-minutes).
• Not the local network path: verified no proxy/MITM, healthy latency, and survivor connections during every incident.
• 84% of incidents recover on the first fresh connection.

Asks

1. Could you trace the requestIds above server-side? What closed these connections mid-stream — LB connection-lifetime/drain policy, deploy rollout, backend crash?
2. If edge connection recycling is expected behavior, could the CLI handle it gracefully (transparent retry/stream resume on FIN/GOAWAY mid-stream) instead of failing the user's turn? The request is identifiable and in all captured cases the stream was only a few content blocks deep.

Methodology (reproducible)

• Packet ring (headers only): sudo tcpdump -i any -nn -U -s 128 -C 10 -W 5 -w ring.pcap 'tcp and net 160.79.104.0/24'
• Socket state every 5 s: ss -tinoep dst 160.79.104.0/24
• Watcher tailing ~/.claude/projects/**/*.jsonl for new isApiErrorMessage entries, correlating each error timestamp against the capture

Full pcap slices for each incident are archived and available on request.

[github-actions]

Found 3 possible duplicate issues:

1. API Error: The socket connection was closed unexpectedly. + SOLUTION FOR ANTHROPIC DEVS #60133
2. [BUG] Persistent mid-stream ECONNRESET on large-context sessions (v1/messages?beta=true) #51164
3. Recurring fetch() socket disconnects in Node SDK — n=81 corpus, cross-client cascade correlated with status.claude.com "Elevated errors" entry #62146

This issue will be automatically closed as a duplicate in 3 days.

• If your issue is a duplicate, please close it and 👍 the existing issue instead
• To prevent auto-closure, add a comment or 👎 this comment

🤖 Generated with Claude Code

[abhinas90]

Gateway/production reliability issues in multi-agent setups are painful because they cascade — one gateway freeze takes down every agent behind it. Here's what to check:

Diagnostic matrix:

1. Event-loop blocking — the most common silent-freeze cause in agent gateways is a long-running tool call blocking the event loop. Check: is there a cron job firing at the same time as the freeze? If a tool call takes >30s and isn't properly async, it blocks the entire gateway.

2. Session delivery replay — after a crash/restart, the gateway can replay old sessions. Check the session DB for duplicate deliveries: sort by timestamp, look for the same session_id delivered twice within seconds. This is usually a state-recovery bug.

3. Memory pressure — agent gateways accumulate state per active session. If the gateway's RSS exceeds available memory, OOM killer takes it out silently. Set a monitoring alarm: watch -n 60 'ps -o pid,rss,comm -p $(pgrep -f gateway) | tail -1'. If RSS > 2GB, restart proactively during a quiet window.

4. Subprocess orphan check — every agent task spawns child processes. After a gateway restart, check for orphaned agent processes: ps aux | grep -E '(claude|agent|worker)' | grep -v grep. Orphaned workers can hold file locks that block the new gateway instance.

Production multi-agent reliability is the #1 adoption blocker I see. I've got a deployment hardening checklist that covers these patterns — happy to share if you're dealing with this repeatedly.

[akashish504]

Bug Report Summary — Claude Code "Connection closed mid-response" (recurring)

Environment

• macOS, darwin-arm64
• Claude Code native install: version 2.1.201 (commit 5bb45156ece6)
• Install path: /Users/ashish/.local/share/claude/versions/2.1.201
• Config install method: native, auto-updates enabled, channel latest
• Also tested via Cursor's Claude Code panel/extension
• Node/npm also present via nvm (v22.16.0) — had a separate leftover npm global install, now identified as unrelated

Symptom

• Recurring error: API Error: Connection closed mid-response. The response above may be incomplete.
• Occurs mid-task, typically during/after the model kicks off exploratory work (e.g. "let me explore the environment" followed by a tool call)
• Visible retry occurs (client attempts backoff retry) but still fails — not a single transient drop
• Task: exploring a repo/data archive (large options-data archive + git repo tailoredai) to validate Tuesday-expiry counts and tick granularity before writing strategy code

Timeline note

• Started failing today without any known change on the user's side

Diagnostic steps taken, in order

1. Checked Claude Code version — initially found stale at 2.1.169 despite believing an update had been run.
2. Found PATH shadowing issue: which claude resolved to /Users/ashish/.local/bin/claude, a symlink into the native install (~/.local/share/claude/versions/2.1.169), which was ahead of the nvm-managed npm install (2.1.201) in $PATH.
3. Ran claude update to update the native install directly (rather than removing it) → confirmed version now 2.1.201.
4. Retried the task — same error still occurred (this is the key point: version was NOT the fix).
5. Tested Cursor panel vs. plain terminal — failed in both, ruling out Cursor's IDE-bridge/extension layer as the cause.
6. Checked for VPN/proxy — none in use, ruling out TLS-inspection interference.
7. Checked Anthropic status page — no active incident at time of testing (last resolved incident was July 4, 2026); no evidence of a broad public outage.
8. Ran claude doctor — output showed:
   • Correct native version running (2.1.201), auto-updates healthy
   • Leftover npm global install flagged (cosmetic, addressed via npm -g uninstall @anthropic-ai/claude-code)
   • One MCP server (claude.ai Google Drive) shown as "needs authentication"
9. Disabled MCP entirely for a test run — error still occurred, ruling out the unauthenticated MCP server as the cause.
10. Tested a trivial task with no tool calls ("say hello") — worked fine, confirming basic connectivity/auth/streaming is healthy.
11. Tested resumed session vs. brand-new session — the failing run had been a resumed/continued session; started a genuinely fresh session (claude, no --resume/--continue) — still failed, ruling out session-state corruption/bloat as the sole cause.
12. Checked for concurrent sessions — was running two Claude Code windows simultaneously against related work; asked to isolate to a single window/session — still failed even in isolation (per user: "tried every combination").
13. Considered and did not yet conclusively rule out: the new streaming idle watchdog (CLAUDE_ENABLE_STREAM_WATCHDOG=0) as a possible cause if a specific tool call (e.g. scanning a large data archive) stalls past the 5-minute idle threshold — this test was suggested but not confirmed completed before the user reported failure "with every combination."

What's been ruled out

• Client version (confirmed on latest, 2.1.201)
• PATH/binary shadowing (resolved, correct binary now running)
• Cursor extension/IDE-bridge specific issue (fails in plain terminal too)
• VPN/proxy interference (none present)
• Public Anthropic-wide outage (none active per status page)
• MCP server auth (disabled, still fails)
• Session state corruption (fresh session still fails)
• Concurrent-window resource contention (fails in isolation too)

Not yet fully tested

• CLAUDE_ENABLE_STREAM_WATCHDOG=0 in a controlled single test explicitly confirmed
• Whether the specific tool call at the failure point (likely a bash/file-scan command against the options archive or repo) is unusually slow or large, independent of watchdog settings
• Server-side/account-specific rate limiting or routing issues (not visible from client side)