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

> Claude Code renamed this error Connection lost mid-response in v2.1.227. Completed blocks are kept: check what ran, reply continue, then trace the cause.

- URL: https://blog.laozhang.ai/en/posts/claude-code-connection-closed-mid-response
- Published: 2026-10-21
- Updated: 2026-10-21
- Author: LaoZhang AI Team (https://blog.laozhang.ai/en/about)
- Topic: Claude Code
- Tags: Claude Code, Connection lost mid-response, API Error, Streaming, Debug Log, Troubleshooting

---
`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](https://code.claude.com/docs/en/errors#the-response-above-may-be-incomplete) 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](https://github.com/anthropics/claude-code/blob/main/CHANGELOG.md) 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:

| Text after `API Error:` | What broke, per the error reference | Older wording |
| --- | --- | --- |
| `Connection lost mid-response` | The connection dropped, or a proxy or gateway ended the response body cleanly before the response finished | `Connection closed mid-response` (before v2.1.227) |
| `The response stopped arriving` | The connection stayed open but no data came, so the streaming idle watchdog aborted it | `Response stalled mid-stream` (before v2.1.227) |
| `Server error mid-response` | The API sent an overloaded or 5xx error partway through the stream (needs v2.1.199 or later) | Before v2.1.199 the whole turn was reported as an error and the partial output was discarded |
| `Your computer went to sleep mid-response` | Claude Code detected that the computer slept while the response streamed | — |
| `Part of the response never arrived` | A stream event was dropped between the API and Claude Code | `API Error: Content block not found` (before v2.1.281) |
| `The response stream was malformed` | An event arrived damaged, or for a block that had already finished | Raw parser errors such as `API Error: JSON Parse error` (before v2.1.284) |

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](https://blog.laozhang.ai/en/posts/claude-api-error-connection-error) 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`.

![What Claude Code keeps and drops after Connection lost mid-response, with four checks before replying continue](https://blog.laozhang.ai/posts/en/claude-code-connection-closed-mid-response/img/before-you-continue.webp)

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](https://blog.laozhang.ai/en/posts/claude-code-500-529-rate-limit) 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:

```bash
# 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.

| What the server did after one finished paragraph | Last line printed | Debug-log line (one per attempt) |
| --- | --- | --- |
| Sent a TCP reset | `API Error: Connection lost mid-response.` | `[WARN] Stream connection closed (ECONNRESET) after 1 block(s) yielded — finalizing partial response` |
| Ended the body cleanly without `message_stop` | `API Error: Connection lost mid-response.` | `[ERROR] Stream ended cleanly inside open block 1 (stop_reason=null) — treating as a dropped connection`, then `[WARN] Stream connection closed (StreamTruncated) after 1 block(s) yielded` |
| Sent an `overloaded_error` event mid-stream | `API Error: Server error mid-response.` | `[WARN] Mid-stream server error after 1 block(s) yielded — finalizing partial response` |
| Went silent with the socket open, `CLAUDE_BYTE_STREAM_IDLE_TIMEOUT_MS=10000` | `API Error: The response stopped arriving.` | `[ERROR] Streaming idle timeout (byte-level): stream idle: no bytes for 10000ms, aborting stream`, plus `[WARN] [byte-watchdog] firing: idle=10000ms …` |
| Reset right after `message_start`, before anything completed, `CLAUDE_CODE_MAX_RETRIES=2` | No error; the answer arrived | `[WARN] Stream connection error (ECONNRESET) — retrying streaming (1/2)`, `(2/2)`, then `[ERROR] Error streaming, falling back to non-streaming mode: ECONNRESET…` |

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.

![Map from each mid-response notice to its debug-log line and likely cause: ECONNRESET reset, StreamTruncated early end, mid-stream server error, idle timeout](https://blog.laozhang.ai/posts/en/claude-code-connection-closed-mid-response/img/debug-log-signatures.webp)

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](https://code.claude.com/docs/en/network-config#streaming-idle-watchdogs). 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:

```bash
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](https://blog.laozhang.ai/en/posts/claude-code-install)). Several releases changed how this error is reported or recovered:

| Version | Change in the CHANGELOG or error reference |
| --- | --- |
| 2.1.199 | `Server error mid-response` keeps the partial output instead of failing the turn |
| 2.1.214 | `Socket is closed` (often a Windows corporate proxy dropping a tunnel) is retried |
| 2.1.219 | `claude -p` text output no longer drops the answer on a mid-stream error |
| 2.1.222 | No more `Connection closed mid-response` on responses that had actually completed; no spurious idle timeouts on custom `ANTHROPIC_BASE_URL` gateways that send keep-alive pings |
| 2.1.227 | "Closed" renamed "lost"; "stalled mid-stream" renamed "stopped arriving" |
| 2.1.232 | Stream idle timeouts recover instead of failing on Bedrock, Vertex, and gateways |
| 2.1.246 | `-p`, SDK, and cloud sessions auto-continue a cut-off response |
| 2.1.257 | Subagents auto-continue instead of ending with an incomplete response |
| 2.1.281 | A proxy-dropped stream event keeps the partial response instead of `Content block not found` |
| 2.1.284 | Retries after a mid-response drop share one budget, so a failing request gives up sooner |
| 2.1.288 | Mid-response API timeouts continue in non-interactive sessions and subagents |
| 2.1.290 | A response cut by sleep is no longer treated as a stall on Bedrock, Vertex, Foundry, and custom gateways |

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](https://github.com/anthropics/claude-code/issues/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](https://github.com/anthropics/claude-code/issues/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](https://blog.laozhang.ai/en/posts/claude-api-error-connection-error) 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](https://github.com/anthropics/claude-code/issues/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.

```json
{
  "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](https://blog.laozhang.ai/en/posts/claude-code-api-configuration).

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](https://github.com/anthropics/claude-code/issues/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](https://github.com/anthropics/claude-code/issues/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](https://github.com/anthropics/claude-code/issues/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](https://blog.laozhang.ai/en/posts/claude-code-openrouter-deepseek).

### 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](https://github.com/anthropics/claude-code/issues/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:

```bash
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](https://status.claude.com), 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](https://blog.laozhang.ai/en/posts/claude-code-overloaded-error) 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](https://github.com/anthropics/claude-code/issues/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](https://github.com/anthropics/claude-code/issues/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](https://github.com/anthropics/claude-code/issues/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.

## Sources

External pages this guide links to, in the order they appear. Last updated 2026-10-21.

- [Claude Code error reference](https://code.claude.com/docs/en/errors) (code.claude.com)
- [Claude Code CHANGELOG](https://github.com/anthropics/claude-code/blob/main/CHANGELOG.md) (github.com)
- [Claude Code network configuration page](https://code.claude.com/docs/en/network-config) (code.claude.com)
- [GitHub issue #69336](https://github.com/anthropics/claude-code/issues/69336) (github.com)
- [issue #83657](https://github.com/anthropics/claude-code/issues/83657) (github.com)
- [issue #84680](https://github.com/anthropics/claude-code/issues/84680) (github.com)
- [issue #84211](https://github.com/anthropics/claude-code/issues/84211) (github.com)
- [issue #84955](https://github.com/anthropics/claude-code/issues/84955) (github.com)
- [GitHub issue #84404](https://github.com/anthropics/claude-code/issues/84404) (github.com)
- [GitHub issue #102780](https://github.com/anthropics/claude-code/issues/102780) (github.com)
- [the Claude status page](https://status.claude.com/) (status.claude.com)
- [Issue #103058](https://github.com/anthropics/claude-code/issues/103058) (github.com)
- [Issue #103488](https://github.com/anthropics/claude-code/issues/103488) (github.com)