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

[mrctito]

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?

Summary

"API Error: Connection closed mid-response. The response above may be incomplete."
occurs frequently during normal usage. The response is cut off mid-generation with no way
to recover it.

Environment

• OS: Windows 11 / WSL2 (Ubuntu, kernel 6.18.33.1-microsoft-standard-WSL2)
• RAM: 64 GB
• Claude Code: latest version
• IDE: VSCode (latest), Claude Code extension (latest)
• Proxy: none
• Network: direct connection, no corporate firewall

Reproduction

The error occurs consistently when Claude generates long responses — for example,
reading multiple large files and producing a structured report. It does NOT require
any special conditions: no proxy, no low memory, no version mismatch.

Key observation

The same task on the same machine with the same network does NOT produce this error
with any other AI assistant (e.g., GitHub Copilot, Cursor, GPT-4). This strongly
suggests the issue is on Claude Code's streaming layer, not the environment.

Impact

The error is frequent enough to make Claude Code unusable for any task that produces
long responses. The user has to restart and retry repeatedly, often unsuccessfully.

Expected behavior

Long responses should complete normally or, at minimum, be resumable after a
connection drop.

Related issues

• [BUG] Persistent IDE disconnections in VS Code terminal (recurring issue, auto-closed #4871) #26285
• API Error: The socket connection was closed unexpectedly — packet captures show server-initiated FIN mid-stream (10 incidents, requestIds included) #67766

What Should Happen?

I just want that Claude works.

Error Messages/Logs

API Error: Connection closed mid-response

Steps to Reproduce

1. Try to use Claude inside VScode or CLI.

Claude Model

Not sure / Multiple models

Is this a regression?

No, this never worked

Last Working Version

No response

Claude Code Version

2.1.181

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

WSL (Windows Subsystem for Linux)

Additional Information

No response

[delor]

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.

[delor]

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.)

[peculiar-ragdoll]

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.

[honzastim]

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.

[kaelzhang]

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

[Shadetail]

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.

[komalkotkartrex]

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

Context memory when it was hit :

Nothing unusual on load of work.