[Bug] Anthropic API Error: Connection closed mid-response

Status Open

Reported on v2.1.186

Maintainer reply None cached

Activity 18 comments · opened Jun 23, 2026

Bug Description
claude-code keeps stopping mid work, with the following message: ⏺ API Error: Connection closed mid-response. The response above may be incomplete.

This is costing real time and money.

Environment Info

Platform: darwin
Terminal: Apple_Terminal
Version: 2.1.186
Feedback ID: 44bd4a9a-a92e-4abe-9b05-e03afbfd8949

Errors

[]

View original on GitHub ↗

13 Comments

jsbintask22 · 2 months ago

same issues

thepixelabs · 2 months ago

i ge the same issue out of nowhere, on many different networks, this is costing me money!!! i have to restart whole workflows because of this

pessini · 1 month ago

Using Claude Code VSCode extension inside a Dev Container. It happens 3/4 times per session.

EduardsE · 1 month ago

Same issue, both VS Code extension and CLI

orzogc · 1 month ago

try setting CLAUDE_STREAM_IDLE_TIMEOUT_MS to larger timeout number or setting CLAUDE_ENABLE_BYTE_WATCHDOG/CLAUDE_ENABLE_STREAM_WATCHDOG to 0

rkseattle · 1 month ago

try setting CLAUDE_STREAM_IDLE_TIMEOUT_MS to larger timeout number or setting CLAUDE_ENABLE_BYTE_WATCHDOG/CLAUDE_ENABLE_STREAM_WATCHDOG to 0

Haven't noticed a difference. Still getting the error. Also, here's what Claude had to say about it:

_How do these relate to claude-code experiencing this: API Error: Connection closed mid-response._

The response above may be incomplete.Differentiated connection closure from watchdog timeout mechanismsDifferentiated connection closure from watchdog timeout mechanismsThey're related but distinct failure modes — and importantly, the watchdog variables are generally not the cause of (or fix for) that error. Here's the relationship: Two different ways a stream can die: 1. Silent stall — the socket stays open but nothing arrives. The connection is technically alive; the client just waits. This is what the watchdogs exist to catch: after CLAUDE_STREAM_IDLE_TIMEOUT_MS of silence, the watchdog proactively aborts the request and you see "Stream idle timeout - partial response received." 2. Explicit close — the connection is actually torn down mid-stream (server-side disconnect, proxy reset, network drop). The client doesn't need a timer to notice; the socket dies on its own and you get "Connection closed mid-response." In one well-documented case, packet captures showed server-initiated FIN mid-stream — i.e., the far end closed the connection. GitHub So: the watchdog variables govern error #1, not error #2. If you're seeing "Connection closed mid-response," raising CLAUDE_STREAM_IDLE_TIMEOUT_MS or toggling CLAUDE_ENABLE_BYTE_WATCHDOG/CLAUDE_ENABLE_STREAM_WATCHDOG won't help — there was no idle period to time out; the connection abruptly ended. The only indirect interaction is that if you disable the watchdogs, a stall that would've been cleanly aborted might instead hang until the connection eventually dies and surfaces as a "connection closed"-style error — but that's an edge case, not the typical cause.

sfischer-ngb · 1 month ago

I had the same problem and was directed to the "closed as duplicate" issue by claude. Here's the report, hope it helps:
<html><body>
<html><head></head><body><h2>Additional data point: repeated mid-stream stalls correlated with in-place extension version churn</h2>
Environment
<ul>
<li>Platform: Windows 10</li>
<li>Client: VS Code extension (<code>entrypoint: claude-vscode</code>)</li>
<li>Shell: Git Bash</li>
<li>Session type: long-running, tool-heavy conversation (multiple Explore/Agent subagent dispatches, large file reads)</li>
<li>Extension versions seen within a single session: 2.1.205 → 2.1.206 → 2.1.207</li>
</ul>
Summary
Over a single Claude Code session I hit 11 distinct "Response stalled mid-stream" recoveries. Each recovery shows up in the local transcript as a synthetic client-generated message (<code>model: "<synthetic>"</code>, <code>stop_reason: "stop_sequence"</code>, zero token usage) rather than a real model turn, so the transcript itself doesn't capture the underlying network/process failure reason — only that a recovery was needed.
Switching models (Sonnet → Opus) did not resolve it; the same stall pattern resumed after a short delay. No VPN or proxy in use.
Interruption timeline

Time (UTC) | Client version | Gap since last interruption
-- | -- | --
2026-07-10 20:17:36 | 2.1.205 | — (session start)
20:24:44 | 2.1.205 | 7.1 min
20:31:47 | 2.1.205 | 7.0 min
20:40:58 | 2.1.205 | 9.2 min
20:49:59 | 2.1.205 | 9.0 min
21:01:37 | 2.1.205 | 11.6 min
21:18:03 | 2.1.205 | 16.4 min
21:33:49 | 2.1.206 | 15.8 min
2026-07-11 08:24:00 | 2.1.206 | 650 min (session idle overnight)
08:28:48 | 2.1.207 | 4.8 min
08:43:35 | 2.1.207 | 14.8 min

Observations
<ol>
<li>Periodic recurrence, not one-off flakiness. During the first active cluster (20:17–21:33 UTC), stalls recurred roughly every 7–16 minutes — consistent with a timeout/reconnect cycle on some underlying channel rather than random packet loss.</li>
<li>Version churn mid-session. The extension's reported client version incremented twice (2.1.205 → 2.1.206 → 2.1.207) without the session restarting. This suggests the VS Code extension auto-updated in place at least twice while a long-lived connection to the CLI subprocess (or the subprocess's own connection upstream) stayed open. This is the one concrete correlated event visible in the transcript, and a plausible candidate cause: an in-place extension update may not cleanly hand off or re-establish whatever long-lived channel (SSE/websocket) backs the stream.</li>
<li>No explicit error string in the transcript. No <code>ECONNRESET</code>, timeout, or "socket hang up" string appears anywhere in the local JSONL — the file only records the synthetic recovery prompt, not the network-layer failure. That detail likely only exists in <code>claude --debug</code> output or the extension's own output channel/log, neither of which was captured for this session.</li>
<li>Not resolved by switching models. Sonnet → Opus initially appeared to help but the same stall pattern returned.</li>
</ol>
Source
Local transcript: <code>~/.claude/projects/c--Users-stefan-Claude-Projects-Der-Gouverneur/8cb1d86d-0be9-4609-8550-9486bf72effd.jsonl</code>
Question for the team
Does the VS Code extension hot-update while a session's connection is open, and if so, could that update interrupt or fail to restore the underlying stream? Happy to provide raw JSON for any of the 11 events above, or re-run with <code>claude --debug</code> if that would help isolate the actual network-layer error.</body></html>
</body>
</html>

rkseattle · 1 month ago

This is still happening, and apparently at a higher frequency. Is anybody from Anthropic paying attention?

!image

thomasmack021 · 1 month ago

+1, same issue since yesterday in Claude Code via iTerm

FabLrc · 1 month ago

Same issue ..

FabLrc · 1 month ago

I found a temporary solution: The problem is probably that the agent is trying to enter too much data into a tool (in my case, creating a plan). So I asked him to write the plan step by step (he wrote the plan in several “chunks” in the same file), and I didn't have any issues.

orzogc · 1 month ago

I found a temporary solution: The problem is probably that the agent is trying to enter too much data into a tool (in my case, creating a plan). So I asked him to write the plan step by step (he wrote the plan in several “chunks” in the same file), and I didn't have any issues.

you could try this: https://github.com/anthropics/claude-code/issues/70217#issuecomment-4929077488

ogijster-del · 1 month ago

Additional data point: local network ruled out with a 25-minute parallel probe

Environment

Platform: macOS 26.5.2 (darwin)
Claude Code: 2.1.183 (CLI + desktop app sessions)
Region: Europe (Serbia), residential ISP

Symptoms (2026-07-21, all day)

Repeated ECONNRESET on the API socket, visible as system/api_error entries in ~/.claude/projects/*/*.jsonl with retryAttempt N / maxRetries 10, isSSLError: false. 83 ECONNRESET events on the worst day, 3 requests exhausted all 10 retries.
Separate failure mode: server opens the stream but never sends a chunk. Client sits until CLAUDE_STREAM_IDLE_TIMEOUT_MS, then injects "API Error: Stream idle timeout - no chunks received" / "Connection closed mid-response". The desktop app logs it as timed out after ~1000s of inactivity, reason=incomplete_response, and the UI shows "Request interrupted by user" even though nobody touched anything.
Errors continued for hours AFTER the three status.claude.com incidents on 2026-07-21 were all resolved (last one closed 12:07 UTC; I still logged api_errors at 16:54 UTC and session stalls at 15:36 UTC).

Why I'm confident it is not my network

Ran a 25-minute probe in parallel with failing Claude sessions: every 15 s, an HTTPS request to api.anthropic.com (got expected 401), one to google.com, and a 1 MB upload. 82 rounds, zero connection errors, zero resets, while Claude Code sessions on the same machine were stalling at the same time.
Verified the TLS chain on api.anthropic.com is the genuine Google Trust Services chain (no corporate MITM, no system proxy).
Not correlated with 529/overloaded: only a handful of overloaded_error entries in the whole log.

Mitigation that helps a little

CLAUDE_STREAM_IDLE_TIMEOUT_MS=120000 (fail fast and retry instead of waiting 10 minutes). It does not fix the resets, it just shortens the hang.

Happy to share sanitized api_error JSONL excerpts or app logs if useful.

Showing cached comments. Read the full discussion on GitHub ↗

[Bug] Anthropic API Error: Connection closed mid-response

13 Comments

Related Claude Code issues

Browse by topic