Error messages

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

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

Claude was partway through answering, the connection carrying the answer dropped, and Claude Code decided to keep what it had instead of starting over. On current versions the line reads:

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

Most people search for the older wording, though. Until version 2.1.227 the same message said:

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

66 issues in anthropics/claude-code quote the "closed" version as of September 25, 2026, against 17 for "lost". Nothing changed but the verb. I read how 2.1.282 decides to print it, and what Anthropic's error reference says to do next.

Why Claude Code doesn't just retry it

This is the interesting part. Claude Code retries a dropped connection happily, with the usual backoff, as long as nothing of Claude's answer has been completed yet. Once Claude has finished a block of text or a tool call, it stops doing that. The error reference gives the reason: re-sending "could run the same tool calls twice". If the first attempt already ran a shell command or wrote a file, a blind retry would do it again.

So instead the code keeps every block that finished, marks the turn as ended (as a tool call if one had completed, so that tool still runs), and prints the notice. The reference adds a detail that's easy to miss: a final block that was still arriving when the connection went is thrown away when the turn ends. The last sentence or the last tool call you expected may not be there.

If the connection goes before Claude has produced anything visible, you get a shorter cousin, Connection lost before a response was produced. Try again., and if it goes after the answer is complete, 2.1.282 notices the finished stop reason and ends the turn normally with no error at all. That last case used to show this notice too, before v2.1.222.

The same notice with other causes

The second sentence is shared. The first one tells you why the stream ended, and 2.1.282 has several: Server error mid-response when the API failed mid-stream (see the 500 page), Your computer went to sleep mid-response, The response stopped arriving when the connection stayed open but went silent, and a couple for a stream that arrived garbled. Only the "lost" one is about the connection being cut.

What to do next

Read what's on screen, then reply continue. That's the reference's advice, and Claude picks up from its last completed block. In a -p run, an Agent SDK run or a cloud session you often won't see the notice at all: since v2.1.246 Claude Code prompts Claude to carry on by itself, up to three times, when the cut-off answer had text and no tool calls. Subagents got the same treatment in v2.1.257.

Once is bad luck. On every turn it's a network problem, and the checks are the same as for a socket reset: try curl -I https://api.anthropic.com from the same shell, then look at proxies, VPNs and container runtimes in the path. We went through those on the ECONNRESET page.

What people are reporting

The report duplicates get pointed at is #70217, filed June 23, 2026 on version 2.1.186 and still open: "claude-code keeps stopping mid work". When a Linux user filed the same thing in August on 2.1.226, a Claude Code collaborator closed it as a duplicate of that one.

The most careful report is #85539 (August 10, 2026, 2.1.226 on Windows). The drop came right after tool calls that returned about 40 or more lines of output, and the reporter ruled out a lot: VS Code and plain cmd behaved identically, so did several Wi-Fi networks, a fresh login, fixing an out-of-sync Windows clock and a clean reinstall. No cause has been posted on either thread, and I can't tell from the binary why output size would matter, so that one stays open.