"Connection closed mid-response" truncates responses 315 times across 130 sessions; silent partial output for unattended runs

Environment: Claude Code desktop app 2.1.219, Windows 11 (10.0.26200). ~52 scheduled tasks configured, 10-20 concurrent sessions typical.

What is wrong

Responses are frequently cut off partway through, surfacing as:

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

In the transcript these records carry "error": "server_error", "isApiErrorMessage": true, "model": "<synthetic>".

Frequency, counted from local transcripts rather than estimated: 315 occurrences across 130 distinct sessions. Recent daily counts: 07-25 30, 07-26 17, 07-27 60, 07-28 47, 07-29 21, 08-01 9.

Why this matters more than the visible error

Interactively you see the message and retry, so it is an annoyance. In an unattended scheduled run there is nobody to see it. The run produces a shorter result than it should, the error text itself says the response "may be incomplete", and nothing downstream flags the truncation. A scheduled job can therefore do a fraction of its work and report success.

What should happen

The response completes. Failing that, the failure should be machine-detectable rather than a line of prose in a transcript, so an unattended run can tell it was truncated and retry or fail rather than silently returning partial work. A scheduled run that suffered a mid-response truncation should not be able to finish and report success as though it produced its full output.

Three things ruled out before filing

1. Not server-side overload. Across the entire local history: 4 HTTP 529s (all inside one 24-minute window on one evening) and zero 500s. That cannot account for 315 truncations over weeks.
2. Not the orphaned-process leak in #80885. That was the working hypothesis and it is wrong. The app was fully restarted with a clean process table and the first truncation arrived within about 2 minutes.
3. Not an isolated network blip. There are also 254 ECONNRESETs across 250 transcripts in the last 9 days on the same machine, so connection instability is persistent rather than incidental.

Reproduction

There is no deterministic trigger and I am not going to invent one. It is not tied to a particular prompt, tool or file type. The condition under which it reproduces reliably here:

1. Run the desktop app on Windows with many concurrent sessions plus ~52 scheduled tasks, several firing daily.
2. Work normally for a few hours.
3. Truncations appear at roughly 20-60 per day, spread across many different sessions rather than concentrated in one.

To count them from local data rather than by eye, search session transcripts under the projects directory for the literal string Connection closed mid-response. Each hit is one truncated response; that is how the figures above were produced.

Honest limit

I cannot tell from the client side whether the connection is dropped locally, in transit, or server-side. The pattern worth noting is that this machine runs many concurrent sessions, so a connection-pool or concurrency limit would be hit here before a typical setup hits it.

Regression: unknown, I do not have a known-good earlier version to point to.