Response stalled mid-stream regression introduced in 2.1.216 (0 occurrences on 2.1.210, 3-4% on 2.1.217/2.1.218)

[mauridev-vs]

Summary

Starting with 2.1.216, sessions frequently abort with:

API Error: Response stalled mid-stream. The response above may be incomplete.

The error did not exist in prior versions on the same machine and network. I correlated occurrences against message volume per version using my local session transcripts (~/.claude/projects/**/*.jsonl).

Evidence: error rate by version

Counted stalled mid-stream occurrences per session file, attributed to the version(s) recorded in that file, and divided by the number of assistant messages per version over the same period.

Version	Assistant messages	stalled mid-stream	Rate
2.1.210	1612	0	0%
2.1.216	486	7	1.4%
2.1.217	1429	43	3.0%
2.1.218	567	25	4.4%

2.1.210 has the largest sample of any version and zero occurrences. No session running only 2.1.210 produced the error; the only 2.1.210-tagged files that contain it are long-lived sessions that spanned an in-place upgrade.

Onset

Across ~400 transcript files spanning several months, the first occurrence is abrupt:

Date	Occurrences
before 2026-07-21	0
2026-07-21	30
2026-07-22	87
2026-07-23	40

First occurrence: 2026-07-21T13:05:10. 2.1.216 first appears in my transcripts on 2026-07-21. Totals: 153 occurrences across 49 sessions.

Related error counts over the same period, for context: terminated 63, ECONNRESET 12, Overloaded 5, Request timed out 3, fetch failed 4, Connection error 1, socket hang up 1.

Network causes ruled out

Same machine and network throughout, so this is not a plausible confound, but I verified anyway:

• Throughput/stability: 100 MB sustained HTTPS download completed in 19.5 s at 41 Mbps, max inter-chunk gap 1274 ms. A separate 150 s sustained connection stayed open (no lifetime cap).
• Packet loss: 0% over 20 ICMP probes to both LAN gateway and 8.8.8.8.
• TLS interception: none. api.anthropic.com presents Google Trust Services WE1 → GlobalSign GTS Root R4, validated against the system trust store. Only Windows Defender installed (no HTTPS inspection).
• Proxies: no HTTP_PROXY / HTTPS_PROXY / ALL_PROXY / ANTHROPIC_BASE_URL set.
• VPN: Tailscale is running but is not in the path — routes to the API for both address families go via the physical Ethernet interface, no exit node, no MagicDNS for this name.
• Idle behavior: idle connections receive a normal graceful FIN at ~15 s (standard keep-alive); no silent blackhole.

One unrelated, genuine local issue was found and fixed separately: the IPv6 route to the API was dead (5/5 connect timeouts at 15 s, while IPv6 to other destinations worked and IPv4 to the API connected in ~40 ms). Worked around with NODE_OPTIONS=--dns-result-order=ipv4first. That fix was in place before the measurements above, and did not affect the stall rate.

Environment

• Claude Code: 2.1.216 / 2.1.217 / 2.1.218 (affected), 2.1.210 (not affected)
• OS: Windows 11 Pro 26100
• Install method: npm global
• Node: v22.17.0
• Shell: PowerShell 7

Impact and workaround

Roughly 3–4% of assistant turns abort mid-response, truncating output and forcing a retry. It is most noticeable on longer responses.

Workaround: pinned to @anthropic-ai/claude-code@2.1.210 and disabled the auto-updater to keep it from moving forward.

Notes

Happy to provide additional aggregate counts. I have not shared transcript contents, only derived per-version counts.

[carrotRakko]

Data point from outside the client (full detail in a comment on #81609): running CLI 2.1.220 behind a forward proxy, we caught 3 of these stalls at the proxy on 2026-07-29 — in all three the upstream returned 200 + SSE headers and then zero body bytes for 6m32s–9m32s until the client's stall detector disconnected. The missing bytes never reached the client side of the proxy.

So at least some stalls originate upstream of the CLI. Your version correlation could still be real as the surfacing mechanism — if 2.1.216+ added or changed the stall detector, older versions would sit silently on the same dead streams instead of erroring (speculation). That reading would make your data and #81609's server-side onset data compatible rather than contradictory.

✍️ Author: Claude Code with @carrotRakko (AI-written, human-approved)