Claude Code Connection Closed Mid-Response (Now Connection Lost)

API Error: Connection closed mid-response. The response above may be incomplete. and API Error: Connection lost mid-response. The response above may be incomplete. are the same Claude Code notice. The Claude Code error reference says the wording changed from "closed" to "lost" in v2.1.227. Either way, the streaming connection broke after Claude had already finished at least one text block or tool call.

Claude Code keeps every block that finished, runs the tool calls that finished, and throws away the block that was still arriving. It does not re-send the request on its own, because a re-sent request could run the same tool calls twice. So your first job is to check which edits and commands actually happened, then reply continue. If the notice keeps coming back, the exact variant on screen and one line in the debug log tell you whether to look at your Claude Code version, your network, a proxy or gateway, security software, a third-party endpoint, sleep, or the API itself.

Connection closed vs. lost mid-response: renamed in v2.1.227

Builds before v2.1.227 print Connection closed mid-response; v2.1.227 and later print Connection lost mid-response for the same case. The same release renamed Response stalled mid-stream to The response stopped arriving. The error reference still lists the old strings in its lookup table, so a screenshot from an older build or an old forum thread describes the same failure you have now.

Which wording you see is only a clue about your version. Check it with claude --version. As of October 21, 2026, the newest entry in the Claude Code CHANGELOG is 2.1.306. If you still see "closed", your build is older than 2.1.227 and is missing several fixes that change how this error behaves (see the version table below).

Six incomplete-response variants and what each one names

Every notice that ends in "The response above may be incomplete." comes from the same mechanism. The words before it name the cause. Current builds print six variants:

Two neighbors look similar but mean something else. Connection lost before a response was produced (formerly Connection closed while thinking, before producing a response) means the drop came after thinking but before any text or tool call; Claude Code already re-issued the request and gave up. Unable to connect to API means no response started at all; the Claude Code Unable to Connect to API guide covers that case.

Before you type continue: check what already ran

The notice only appears after a block of text or a tool call completed. Earlier failures are retried first, up to 10 times with backoff for most error types. Once something has completed, Claude Code stops retrying on purpose: according to the error reference, it keeps the completed blocks, runs any tool calls Claude finished, and continues the turn from their results. What you lose is the final block that was still streaming, usually the last sentences of an explanation or a tool call that never finished forming.

That means some work may already be done even though the answer looks cut off. Before you continue:

1. Read the last complete block on screen. A sentence that ends abruptly belonged to the discarded block, so its content was never acted on.
2. Run git status and git diff to see which file edits landed.
3. For any command with side effects, such as a deploy, a database migration, git push, a package publish, or a message sent to another service, check the result at its destination rather than trusting the transcript.
4. Reply continue. If something must not run twice, say so in the same message, for example: continue; the migration already ran, do not run it again.

If you are unsure how to resume a long task cleanly, the guide to resuming Claude Code after API Error 500 or 529 without duplicating work walks through verifying finished edits and commands before handing the task back.

In claude -p, the Agent SDK, and CI: auto-continue first, then exit code 1

Non-interactive runs behave differently. Since v2.1.246, a -p run, an Agent SDK run, or a cloud session continues a cut-off response by itself, up to three times in a row, as long as the cut-off response contains text but no tool calls. You only see the notice after those continuations are used up. Since v2.1.257, subagents do the same in any session, so a subagent's last message is the notice only after its continuations fail too.

With the default text output, -p prints the last completed text block followed by the notice. Before v2.1.219 it printed only the notice and dropped the answer. With --output-format json or stream-json, the notice goes into the result field. In the local test described in the next section, every text-mode -p run that ended with a notice exited with code 1, so a CI step that checks the exit code will fail instead of passing partial output along as finished.

To pick the turn back up from the same directory once the connection is stable:

# resume the most recent conversation in this directory
claude -c -p "continue"

# or resume a specific session
claude -r SESSION_ID -p "continue"

Apply the same side-effect check as above before you do this in an automated job.

Debug-log signatures from a local 2.1.306 test: reset, early end, stall

Several different breaks print the same notice; the debug log separates them. To see which line belongs to which kind of break, a small test was run on October 21, 2026.

What was run: Claude Code 2.1.306 (native build, macOS), pointed with ANTHROPIC_BASE_URL at a local Python server on 127.0.0.1 that speaks the Anthropic Messages streaming format. Each run was claude -p "Say hello" with --debug-file and a dummy API key. Every streamed reply sent one finished paragraph, opened a second one, and then broke in one chosen way.

Outside the test: Anthropic's API (no request reached it), real network, proxy, or VPN faults, interactive mode (the interactive behavior on this page comes from the error reference), builds older than 2.1.227 (so the old "closed" wording never appeared), and third-party endpoints.

Three things in these results help with real failures:

• "Lost" has two different sources. The word in parentheses separates them. ECONNRESET means something on the path sent a reset. StreamTruncated means the body ended cleanly but too early, which the error reference attributes to a proxy or gateway. Both print the same notice, so only the log tells them apart.
• Auto-continue is visible on the server side. In each of the first four cases, the server received four requests carrying 2, 4, 6, and 8 messages: the original plus three continuations, then the notice and exit code 1. The reset, early-end, and server-error runs finished in about 2 seconds; the stall run took 41 seconds, four attempts of 10 seconds each.
• A failure before anything completed shows no notice. The early reset was retried and then answered by the non-streaming fallback. If you see the notice, the break happened after at least one block finished.

With default settings, a stall waits much longer than 10 seconds: the byte-level watchdog is 180 seconds on the direct Anthropic API and 300 seconds through a custom ANTHROPIC_BASE_URL, according to the Claude Code network configuration page. After 20 seconds without data, the interactive spinner shows Waiting for API response · will retry in … · check your network; the request has not failed yet at that point.

To capture the same lines yourself, start Claude Code with a log file and search it after the next failure:

claude --debug-file ~/claude-debug.log
# after the error:
grep -E "Stream connection closed|Stream ended cleanly|Mid-stream server error|Streaming idle timeout|retrying streaming" ~/claude-debug.log

claude --debug also turns on debug logging. The log can contain session content, so trim it before sharing.

Fix Connection lost mid-response by cause

Match what you found to one of the branches below. Except for the version check and the server-error case, the causes come from individual GitHub reports. Each one is written with its scope; none is an official diagnosis.

Old Claude Code version: update past 2.1.222

Run claude --version, then claude update (other install methods are in the Claude Code install guide). Several releases changed how this error is reported or recovered:

The 2.1.222 fix matters most for old builds: before it, the notice could appear on a response that had arrived in full.

Home network or ISP: same-second failures and the hotspot test

If the debug log shows ECONNRESET or an idle timeout and you use the direct Anthropic API, test the path before changing settings:

• Switch to a phone hotspot or another network and repeat a long task. If the error disappears, the problem is on your usual path. In GitHub issue #94225, users in Spain and Poland traced resets on their home lines to packet size and path MTU around the TLS handshake. Those mostly showed up as Connection dropped (ECONNRESET) before any output, but the hotspot comparison is the same test.
• Compare timestamps across sessions. One user in GitHub issue #69336 found that failures from unrelated sessions landed on the same second of a 5-minute cycle. The router's log showed the WAN link dropping for 1–2 seconds every 300 seconds, which reset NAT and silently cut long streams. Those errors read The response stopped arriving.
• Expect some background rate. One user counted 130,204 API responses in local transcripts on a network with no proxy or VPN: 0.16% ended with Connection closed mid-response over the full history, and about 1% from July 29, 2026 on (issue #83657). An occasional notice on a healthy network is not proof that something local is broken.

For DNS, firewall, and proxy checks that apply when the connection fails outright, use the Claude Code Unable to Connect to API guide rather than repeating them here.

Proxy, VPN, or LLM gateway ending or buffering the stream

StreamTruncated in the log, or a failure that only happens through a gateway such as LiteLLM, points at whatever sits between Claude Code and the API. Look at that component's own idle and response timeouts, and at whether it buffers the whole response before passing it on. A load balancer or reverse proxy that closes connections after a fixed time cuts long responses after the same elapsed time, every time.

Two reports from GitHub fit this branch:

• Mainland China with a full-tunnel VPN (issue #84680, Windows, 2.1.223): failures tracked request size. Small claude -p requests passed; requests of roughly 100 KB or more, which every real session with project context reaches, failed with ECONNRESET or Connection closed mid-response. A commenter reported that pointing Claude Code directly at the VPN client's local proxy port in ~/.claude/settings.json fixed it. The issue was closed as stale, and that fix was never confirmed by anyone else.

{
  "env": {
    "HTTP_PROXY": "http://127.0.0.1:7890",
    "HTTPS_PROXY": "http://127.0.0.1:7890"
  }
}

Replace 7890 with your own VPN client's local HTTP proxy port.

• A Windows corporate proxy dropping an established tunnel shows up as Socket is closed in the error reference. Update to v2.1.214 or later, set HTTPS_PROXY before launching Claude Code, and add your company's root certificate with NODE_EXTRA_CA_CERTS if the proxy inspects TLS. Where these settings live is covered in Claude Code API configuration: keys, settings, models, and gateways.

Raising timeouts helps only when the stream goes quiet or the gateway holds the response; it does nothing for a reset. CLAUDE_BYTE_STREAM_IDLE_TIMEOUT_MS (10 seconds to 30 minutes) and CLAUDE_STREAM_IDLE_TIMEOUT_MS (raised to at least 5 minutes) give a silent stream more time before The response stopped arriving. API_TIMEOUT_MS only limits the wait for response headers, so raise it when a gateway holds responses until generation finishes.

Windows security software: EDR inspection and leftover Winsock LSPs

If Claude Code fails on every network you try while claude.ai in a browser on the same PC works, suspect software that sits in the PC's network stack.

• Leftover Winsock LSP (issue #84211, open): one user had a layered service provider left behind by an uninstalled network accelerator. Claude Code 2.1.220 worked; 2.1.221 and 2.1.222 failed on almost every request with ECONNRESET and Connection closed mid-response. A second PC on the same Wi-Fi had no problem. netsh winsock reset plus a reboot fixed it for the reporter. Later comments named Proxifier and MaLion as other LSP products with the same effect, including a report that 2.1.235 was still affected. Run netsh winsock show catalog first and look for non-Microsoft providers. A Winsock reset also removes entries that VPN clients and other network tools rely on, so you may need to reinstall them.
• EDR with HTTPS inspection (issue #84955, 2.1.223): on a corporate PC with WithSecure Elements Agent, the CLI and the VS Code extension hit repeated Connection closed mid-response on the office network, home Wi-Fi, and a phone hotspot, while claude.ai in the browser was fine. The reporter attributed it to the EDR inspecting long streaming connections and closed the issue; nobody from Anthropic confirmed the cause. If your company runs similar software, ask IT whether Claude Code's traffic can be excluded from HTTPS inspection.

Third-party Anthropic-compatible endpoints: the 2.1.221–2.1.229 reports

Users running Claude Code against DeepSeek's /anthropic endpoint and other Anthropic-compatible services (Qwen and iFlytek MaaS among them) reported that versions 2.1.221 through 2.1.229 broke streaming. The stream reset right after the first chunk, Claude Code retried 10 times, and the turn either finished through the non-streaming fallback after more than three minutes or ended with Connection lost mid-response. In the debug log this looks like first byte after … followed by Stream connection error (ECONNRESET) — retrying streaming (1/10) and onward, the same retry line the early-reset test above produced.

The canonical report, GitHub issue #84404, was closed as not planned on October 2, 2026, and the CHANGELOG through 2.1.306 has no entry that matches it. Whether current builds still fail against these endpoints has no public answer: the issue is closed, and the local test above did not include third-party endpoints.

The workaround users posted was to pin 2.1.220 and set DISABLE_AUTOUPDATER=1. That trades this problem for every fix in the version table from 2.1.222 on, including the fix for false notices on completed responses and non-interactive auto-continue. Try the current version first, keep a debug log of the failure, and send it to the endpoint's provider as well as to Anthropic, since only that route is affected. Setup details for these routes are in Claude Code with OpenRouter and DeepSeek: setup, routes, and first-error fixes.

Your computer went to sleep mid-response on a Mac

This variant is literal: the machine slept while the response streamed, and Claude Code treats the connection as broken once it wakes. In GitHub issue #102780 (macOS, 2.1.300), a session with three background agents left running overnight was cut every time the Mac went into idle sleep. Each cut triggered a full regeneration of the turn without prompt-cache hits, which the reporter flagged as a cost problem.

A commenter's workaround holds a sleep assertion for as long as the Claude Code process runs. Start it from a second terminal:

caffeinate -i -w "$(pgrep -nx claude)"

-i blocks idle sleep and -w releases it when that claude process exits. It does not stop sleep when you close the lid on battery. On Bedrock, Vertex, Foundry, and custom gateways, update to 2.1.290 or later so a sleep cut is not misreported as a stall.

Server error mid-response: overload, not your network

Server error mid-response means the API itself sent an overloaded or 5xx error partway through the stream. Network changes will not help. Check the Claude status page, wait, and send continue after the side-effect check above. If overload keeps interrupting long tasks, the guide to Claude Code API Overloaded (529): switch models or add a fallback covers switching models and configuring a fallback.

When it's not your setup: what to include in a bug report

Stop changing local settings when the evidence points away from your machine: the hotspot test changes nothing, the timestamps cluster across sessions with no shared local cause, or the failures start suddenly with no change on your side. Two open GitHub reports describe that pattern, and both remain unconfirmed by Anthropic:

• Issue #103058 counted 291 mid-response errors on one Mac in seven days, 276 of them on October 16–17, 2026. That includes 206 Connection lost mid-response and 83 The response stopped arriving. Fifteen times, two separate Claude Code processes failed within two seconds of each other, often in the same millisecond, on wired Ethernet.
• Issue #103488 (Linux, 2.1.302, Max plan, direct API) matched debug-log ECONNRESET lines to TCP reset packets coming from 160.79.104.10, the api.anthropic.com address, 15–20 ms after the first byte.

A report that someone can act on contains:

• claude --version, the surface (terminal, VS Code or JetBrains extension, desktop app, -p, Agent SDK), OS, and model
• The route: direct Anthropic API, Bedrock, Vertex, Foundry, a gateway, or a third-party ANTHROPIC_BASE_URL
• The exact notice and the matching debug-log lines: [API REQUEST] … x-client-request-id=…, first byte after …, and the Stream connection closed (…) or idle-timeout line
• The req_… request ID if you have it, and UTC timestamps of several failures, noting any that coincide across sessions
• Whether a hotspot or another network changed the result

File it with /bug inside Claude Code or on GitHub. Anthropic staff have closed duplicate reports in favor of issue #69336, which is still open.

FAQ about Claude Code mid-response errors

Is "Connection closed mid-response" my network or Anthropic?

It can be either, and the notice alone does not say which. The quickest separator is a hotspot test plus timestamps: a different network that fixes it points at your path, failures across separate sessions in the same second point at something shared (your router or the server), and failures on every network while claude.ai in a browser works point at software on your PC. Server error mid-response is the one variant that names the API directly.

Does typing continue re-run the commands Claude already executed?

Claude Code itself does not re-run the interrupted request; it keeps completed blocks and runs tool calls that had finished. When you send continue, Claude picks up from the last completed block, and it may not know which side effects already happened. Check files and commands first, and tell it what not to repeat.

Why does it happen right at the start of a new context window?

The notice needs only one completed block, so a single short sentence before the drop is enough to trigger it instead of a silent retry. That fits reports such as issue #69336, where one or two sentences appeared before the drop. A large first request can also matter on some paths: the VPN report in issue #84680 found that requests above roughly 100 KB failed while small ones passed.

Will raising API_TIMEOUT_MS fix it?

Not for Connection lost mid-response. API_TIMEOUT_MS controls how long Claude Code waits for response headers, not how long a stream may run. The idle-timeout variables only help The response stopped arriving on a slow or buffering path. A reset needs a fix on the path that sends it.

Should I downgrade Claude Code to 2.1.220?

Only as a last resort, and only for the third-party endpoint regression reported on 2.1.221–2.1.229. Downgrading also removes the 2.1.222 fix for false notices, auto-continue in -p and subagents, and the later retry and sleep fixes. Test the current build and collect a debug log first.

Why does my CI job exit with an error and half an answer?

In -p text mode, Claude Code prints the last completed text block, then the notice, after up to three automatic continuations. In the local 2.1.306 test those runs exited with code 1. Treat that output as unfinished, and resume the session with claude -c -p "continue" or claude -r SESSION_ID -p "continue" after checking what the job already changed.