[BUG] API Error: Connection closed mid-response ==> frequent enough to make Claude Code unusable for any task

Adding the unattended / auto-accept angle, plus an auto-resume proposal

This error is especially painful in auto-accept / autonomous mode, where the whole point is to let Claude Code work unattended through a multi-step task. A single mid-stream drop halts the run and forces a human back to the keyboard to type continue and re-establish context — which defeats unattended operation. On long or data-heavy responses (large file reads, big tool/MCP output) the drop rate is high enough that long autonomous runs can't be trusted to finish on their own.

Why the existing retry logic doesn't cover this: Claude Code already retries transient failures at the start of a request (~10× with backoff), but a stream dropped mid-response is not retried — the partial response and any in-flight tool calls are simply lost, and there's no snapshot to replay. --continue / --resume only reopen the transcript; the resumed session carries no marker that it was cut off, so a human still has to notice and re-prompt.

#26729 proposed essentially this (detect network loss, save in-flight state, auto-resume on reconnect) and was closed as not planned. Given how much it undermines unattended/auto-accept usage, I'd like to make the case for reconsidering it. A bounded version:

1. Stream watchdog — detect the drop (the existing "no data for 20s" banner is a start) and abort the partial turn cleanly instead of dead-ending with an unrecoverable error.
2. Recovery snapshot — persist conversation state up to the last complete message plus the in-flight prompt. Record completed tool calls — especially mutations like Edit/Bash — so they aren't blindly re-run; read-only tools can be safely retried.
3. Auto-resume — re-issue the interrupted turn automatically, injecting a marker such as "previous response was truncated by a connection drop; continue from the last completed step" so the model doesn't redo finished work.

Suggested configuration:

• CLAUDE_CODE_AUTO_RESUME_ON_DROP=1 — default on in headless / auto-accept mode, prompt in interactive.
• CLAUDE_CODE_MAX_RESUME_ATTEMPTS=3 — bounded, with backoff; give up gracefully and print recovery instructions if exceeded.

Even just layers 1 + 3 (clean detection + automatic re-issue of the dropped turn) would remove most of the babysitting burden in auto mode, without requiring full mutation-aware state recovery up front.

Follow-up: the detection half of this already ships in the CLI — only the resume half is missing

Inspecting the installed CLI (v2.1.186), Claude Code already carries stream-stall detection infrastructure. The relevant (currently undocumented) env vars and behavior:

• Byte watchdog — CLAUDE_ENABLE_BYTE_WATCHDOG, default on. Wraps the HTTP response body, timestamps every chunk, and aborts if no bytes arrive within an idle window (≈3 min on the first-party API, tunable via CLAUDE_BYTE_STREAM_IDLE_TIMEOUT_MS, clamped ~1 ms–30 min). Emits tengu_byte_watchdog_fired with idle_ms / readable_errored / body_read_pending.
• Event/stream watchdog — CLAUDE_ENABLE_STREAM_WATCHDOG, default off, but forced to "1" in background/daemon sessions. Detects gaps between parsed SSE events; deadline is max(CLAUDE_STREAM_IDLE_TIMEOUT_MS, 300000) (floored at 5 min). Emits tengu_streaming_stall ("Streaming stall detected: …s gap between events").
• keepPartialMessageOnAbort — already retains the partial assistant text when a stream is aborted. This is exactly what prints "The response above may be incomplete."

So layer 1 of the #26729 proposal (detect the drop, abort cleanly) is effectively already implemented, and the partial response is even preserved. What's missing is layer 3 (auto-resume): after the watchdog aborts mid-response, the turn is not re-issued — the user has to manually continue and re-establish context.

For unattended / auto-accept runs (which, per the above, already run with the stream watchdog enabled), wiring the existing abort path into an automatic re-issue of the interrupted turn — injecting a marker that the previous response was truncated so completed work isn't redone — would close the gap with relatively little new machinery, since detection and partial-state capture are already present.

(Behavior observed via strings on the installed binary; these env vars appear undocumented, so the exact names/defaults may change between releases.)

Same issue hit today in claude code. No VPN, no special firewall, no new setup, never hit these issues previously.

Please give us a better way to avoid or handle these errors for big context long running tasks.

Corroborating from a different environment — this is not WSL2-specific, so it rules out the WSL2/Windows theory:

Environment

• OS: Linux (native, not WSL2)
• Claude Code CLI (latest), model Claude Opus 4.8 (1M context)
• Direct connection, no proxy, no corporate firewall, high-RAM workstation

When it hits us
Most frequently during long autonomous / agentic sessions — many turns of heavy tool use (shell commands, background tasks/subagents) with a large accumulated context. The longer the session and the bigger the context, the more often the stream drops with:

API Error: Connection closed mid-response. The response above may be incomplete.

Why it's especially costly for agentic use
Long multi-step autonomous work is exactly Claude Code's strongest use case. When the connection drops mid-response the model is usually mid-task (mid tool-plan, mid-report); the partial output can't be resumed and the whole turn has to be restarted, losing the in-flight reasoning. For long-running / background agent loops this turns a reliable workflow into a coin-flip.

+1 to the SSE-heartbeat proposal in #70017 — a periodic keepalive during long generation/reasoning, plus graceful mid-stream resume, would directly address this. Same machine + network does not reproduce this with non-Claude tooling, matching the original report. Happy to share timing/frequency data if useful.

Same issue hit today in claude code. And if it occurs once, no matter how many times you retry, it will always fail the same way, which will exhaust all your tokens

This has started happening to me from time to time over the last week or so, with irregular frequency. Nothing in my setup has changed. I'm using Claude Code VS Code Extension.

This has been happening to me inconsistently on version of claude cli v2.1.195.

<img width="672" height="71" alt="Image" src="https://github.com/user-attachments/assets/4d5161b1-efbc-40b0-99af-18544d3ad64f" />

Context memory when it was hit :

<img width="670" height="244" alt="Image" src="https://github.com/user-attachments/assets/c8a1e351-7c3e-4fe4-b7ed-676a28c41c1e" />

Nothing unusual on load of work.

Encountering the same issue in claude code latest build (2.1.195) on macos since the last 2 days.

Its just constant happening. No alternative. No flushing the the conversation. Compact does nothing. Everything I spent $$$ working with it beforehand is unusable because the conversation can't go anywhere now.

<img width="372" height="535" alt="Image" src="https://github.com/user-attachments/assets/24ddfcf5-3083-42e3-9035-6ea8a02aff30" />

Same issue on Windows 11 on ARM (Snapdragon) — adding a platform data point, since the reports here so far are mostly macOS / Linux / WSL / VSCode.

Environment

• Claude Code v2.1.195 (desktop app)
• Windows 11 Home, build 26200 — Snapdragon X Plus (X1P42100), ARM64
• Model: Opus 4.8

Symptoms (multiple times a day for the past week):

• Connection went idle — The response stream stopped before finishing — try again in a moment.
• API Error: Connection closed mid-response. The response above may be incomplete.

Happens most often partway through longer responses and right after tool calls. "Try again" usually resumes and committed work survives, but it's frequent enough to be genuinely disruptive.

Local network ruled out: at the time of the drops, ping api.anthropic.com showed 0% packet loss / ~52 ms avg over 20 packets, Wi-Fi at 100% signal, and status.claude.com listed all services Operational. So in my case this is a server-side stream termination, not local connectivity — worth flagging because these errors are easy to misattribute to the user's network.

+1 for a fix, or the SSE-heartbeat mitigation proposed in #70017.

Same issue here on Claude Desktop for macOS.

Device: MacBook Pro M5 Pro
OS: macOS Tahoe 26.5.1

Can confirm I'm experiencing the same behavior.

The chances are it's the API_TIMEOUT_MS var or the CLAUDE_STREAM_IDLE_TIMEOUT_MS. I set both of them to 36000000ms and now it's brewing for the few hours straight

Adding a data point plus a workaround that resolved this for me.

Same symptom: API Error: Response stalled mid-stream. The response above may be incomplete. — the sibling wording of "Connection closed mid-response". It hit me repeatedly on v2.1.199 (the latest channel), during exactly the runs described here: long, large-context, autonomous/agentic sessions with heavy tool output. Typing continue would buy a few more minutes before it stalled again.

What fixed it for me: moving off the latest channel back to the stable build. On 2.1.199 the stalls were frequent; since switching to stable (v2.1.191) I haven't reproduced it.

Claude Code has a native release-channel setting, so you don't have to disable auto-update to stay pinned:

// ~/.claude/settings.json
{
  "autoUpdatesChannel": "stable"
}

Then reinstall the stable build once (switching the channel alone won't downgrade you):

npm install -g @anthropic-ai/claude-code@stable

After that the auto-updater tracks the stable channel only — it won't jump back to latest/preview builds, but you still get future stable fixes. (There's also a minimumVersion setting to guard against downgrades.)

Caveats, so this doesn't mislead anyone: this is anecdotal / n=1, and I see others here hit it on 2.1.186 and 2.1.195 — so it's plausible this is really a specific regressed latest build (2.1.199 in my case) rather than the stable/latest distinction as such. Sharing it because it's cheap to try and it cleanly stopped the stalls for me.

just hit this over the last night. nothing i have tried has worked to resolve it so far.

• tried upgrade to latest, v2.1.201
• tried downgrading to stable, v2.1.193
• tried compacting (context was at 15% before though, which is not a lot)
• tried clearing context, re-running
• tried different network

issue occurs on macbook pro, m4 max.

seems to have started randomly, no version change prior. claude-code ran a long running multi-agent workflow successfully for a few hours, before it stopped getting a response from the api in the middle of that workflow

Im frequently hitting this issue for few weeks now already its super annoying... Im on a Starlink connection which drops out every now and then for a bit. Not sure if it's related to that but at the end, it should recover from this and not get stuck forever so that you need to nudge it to keep going...

the only way that i have found "helps" getting around this is to compact, and drop the effort down a level, and then prompt claude-code to do some tiny incremental version of the original prompt, and specify that it should work in small batches for that stage in the work... isn't great because it breaks my workflow to manually go in and investigate+prompt out of it.

im certain my little prompt ritual is not the minimal number of steps to resolve it, but it was the last set of things i did before i got it moving again... going to have to cargo cult this for now.

I ran into the same issue, starting from approx. 3 weeks ago, both on Windows 11 and Ubuntu 24. >50% of prompts resulted in the Connection closed mid-response error. After lots of debugging, the thing that solved it for me right now was to disable IPv6 completely. I have no idea whether the problems are with my local network setup, with my ISP, or further upstream, but by enforcing everything over IPv4 I have had no issues anymore.

No idea if this is feasible for others, but worthwhile to try if you're running into this.

Confirming this on a different platform and path — Claude Code 2.1.202, macOS (darwin) — so it isn't Windows/WSL-specific.

Quantified from JSONL transcripts (ground-truthed via isApiErrorMessage: true, to exclude quoted/echoed occurrences): 11 genuine Connection closed mid-response events in a single ~4.5 h session, concentrated on long Agent-tool (Task) subagent turns. Each affected subagent transcript ends exactly at the error record — the subagent dies mid-turn with no in-agent retry/resume; it only recovered because a parent orchestrator re-dispatched it (and a naive re-dispatch of the same large turn dropped again).

So the failure spans foreground and background/subagent paths, across Windows/WSL and macOS. Your "should be resumable after a connection drop" expectation is exactly right; full forensics + the concrete prevention (server-side SSE heartbeat, and/or a client-settable retry/resume for background Agent-tool dispatches) are in #70017.

+1 — getting the same issue.

API Error: Connection closed mid-response. The response above may be incomplete. shows up during normal usage and the response is cut off with no way to recover it.

One data point that may help triage: this issue is labeled platform:wsl, but I'm hitting the same error on macOS with a direct connection, so it doesn't appear to be WSL/Windows-specific.

Environment:

• OS: macOS 26.5.2 (Build 25F84), Apple Silicon (arm64)
• Claude Code: 2.1.204 (CLI)
• Terminal: iTerm2 / zsh
• Node.js: v24.18.0
• Proxy: none (no proxy env vars set, no corporate firewall)

happens constantly

Keeps occurring regardless of Anthropic subscription or AWS Bedrock hosted model instance, even when switching mid session.

Same issue here

Same issue here

Just hit this, only affects one of the chats i have only. The others work fine. Started suddenly on Claude CLI (latest as of today), on Windows

Adding a rate-normalized macOS data point

Environment

• macOS (darwin 25.5.0), Apple Silicon
• Claude Code 2.1.209 (CLI), Anthropic API direct (no Bedrock/proxy)
• Direct connection; confirmed not WSL/Windows-specific (matches @dharmveerjakhar / @honzastim / @asawicki)

Rate, not just counts. Absolute error counts mostly track how heavy the day was, so they're misleading. Genuine errors ÷ assistant turns per day (July):

| date | genuine drops | assistant turns | rate |
|------|--------------:|----------------:|-----:|
| 07-05 | 27 | 3172 | 0.9% |
| 07-06 | 29 | 4610 | 0.6% |
| 07-07 | 49 | 6144 | 0.8% |
| 07-08 | 21 | 6803 | 0.3% |
| 07-09 | 35 | 11119 | 0.3% |
| 07-13 | 36 | 4905 | 0.7% |
| 07-14 | 33 | 2218 | 1.5% |

Baseline sits at ~0.3–1.0%; drops are mid-stream on long/heavy agentic turns (large multi-file reads, big tool/MCP output, subagent turns), never at connect time — live IPv4/IPv6 TLS handshakes to api.anthropic.com are both ~30–70ms and healthy while streams still die minutes in. Spans every workspace + subagent transcripts, so it's the streaming layer, not any project.

Client-side resilience is already exhausted on my end and doesn't cover it: CLAUDE_CODE_MAX_RETRIES=15, CLAUDE_CODE_RETRY_WATCHDOG=1, CLAUDE_STREAM_IDLE_TIMEOUT_MS and CLAUDE_BYTE_STREAM_IDLE_TIMEOUT_MS both at 20 min. The byte/stream watchdog fired only 3× ever, so these are not premature-timeout kills — and retries only fire at request start, so a mid-stream FIN is unrecoverable. This is exactly the gap @delor / @asawicki describe: detection + partial capture exist, auto-resume doesn't.

Sample requestIds (all genuine mid-stream drops, 2026-07-14 UTC):

req_011Cd2TpzTJgnRe87ty2cPPM  18:59:09
req_011Cd2U3SsdM2FdXjXAKjXwm  19:01:54
req_011Cd2UbncvR7htqF1sWGA72  19:09:16
req_011Cd2W3xd2RfVFaKmLzf478  19:28:19
req_011Cd2WF8ephYH2pmfSrURh6  19:30:58
req_011Cd2WPWwFCwd4J9t7NG2KP  19:32:41
req_011Cd2Wg5m9NLYWh47GZJUHY  19:36:37
req_011Cd2WqFtbRVJaAQxHpLNxr  19:45:16

32 of 34 today's drops carry requestIds; happy to share the full list or timing/frequency data if it helps triage.

+1 to the SSE-heartbeat + resumable-stream proposals (#70017). A server-side keepalive during long generation, and/or a client-settable retry/resume for background Agent-tool dispatches, would directly address this.

Update to my comment above. The increased error rate today (1.5%) has been attributed to an advanced Endpoint Detection and Response (EDR) system extension crash-looping, driving high CPU.

The root problem w/ Claude Code disconnects is still occurring but at a normal frequency forcing me to keep prodding the harness to "try again" or "continue".