[BUG] Desktop app: long streaming responses drop with ECONNRESET since v1.24012.11 auto-update

Preflight Checklist

• [ ] I have searched existing issues and this hasn't been reported yet
• [x] This is a single bug report (please file separate reports for different bugs)
• [x] I am using the latest version of Claude Code

What's Wrong?

Bug description
Long streaming responses reliably get cut off mid-stream with ECONNRESET since a specific auto-update. The connection establishes fine and receives data for several minutes, then dies — it's not a connect/DNS/TLS failure, it's a mid-stream drop.

Environment
OS: Windows 11 Home 10.0.26200
App: Claude desktop (MSIX / Microsoft Store install)
Network tested: home wired Ethernet, home Wi-Fi, and mobile hotspot — all reproduce it identically
A separate work computer on a different network never reproduces this
Timeline (from local app logs, %APPDATA%\Claude\logs\main*.log)
2026-08-04 18:39:48–53 — app auto-updated: Update downloaded and ready to install { releaseName: 'Claude 1.24012.11' }
2026-08-05 20:31:13 — first-ever occurrence of the error (no prior occurrence in logs going back to 2026-07-18):
[warn] [CCD CycleHealth] local_56f285ad-... api_error (success): API Error: Connection to the API was lost (ECONNRESET). This is usually temporary — try again.
Recurred on 2026-08-13, 2026-08-14, and 2026-08-17
App has since auto-updated further: 1.25927.0.0 → 1.28929.0.0 → 1.30096.5.0 (current) — issue still present on 1.30096.5.0 as of 2026-08-17
Key log pattern
[CCD CycleHealth] unhealthy cycle for local_1955ac2e-... (213s, hadFirstResponse=true, reason=api_error)
[CCD CycleHealth] api_error (success): API Error: Connection to the API was lost (ECONNRESET)
[CCD CycleHealth] unhealthy cycle for local_1955ac2e-... (689s, hadFirstResponse=true, reason=api_error)
[CCD CycleHealth] unhealthy cycle for local_1955ac2e-... (459s, hadFirstResponse=true, reason=api_error)
hadFirstResponse=true in every case — the stream starts fine and dies after several minutes (213s / 459s / 689s observed), correlating specifically with longer/slower-generating responses rather than occurring randomly.

What's been ruled out
Extensive client-side network diagnosis found no environmental cause:

DNS resolution: clean
TCP/TLS handshake to api.anthropic.com:443: succeeds immediately, every time (8/8 repeated POST tests, ~300–500ms each)
Packet loss: 0% over 20 pings
Path MTU: no blackhole detected
No proxy, no VPN active
IPv6 connectivity to the API host was found broken on this network and disabled (preferring IPv4) — no change in behavior
Removed leftover MITM-style root certificates from an old, no-longer-running game-accelerator tool — no change in behavior
Reproduces on wired Ethernet, Wi-Fi, and mobile hotspot alike (rules out a single router/NAT as sole cause)
Reproduces after fully restarting the app
Given it reproduces identically across three unrelated networks on the same machine, but never on a second machine, and the onset date lines up tightly with an auto-update, this looks like an app-side regression (possibly in streaming/keep-alive connection handling) introduced around 1.24012.11 and still present in 1.30096.5.0, rather than a user-network issue.

Repro
Send a prompt that produces a long response (multi-minute generation) from the Windows desktop app.
Wait for the stream to run for several minutes.
Connection drops with ECONNRESET; app shows "Request failed · retrying".

What Should Happen?

Long streaming responses should stay connected for their full duration. Instead, the connection drops mid-stream with ECONNRESET after several minutes, even though the first response was already received successfully.

Error Messages/Logs

[CCD CycleHealth] unhealthy cycle for local_1955ac2e-... (213s, hadFirstResponse=true, reason=api_error)
[CCD CycleHealth] api_error (success): API Error: Connection to the API was lost (ECONNRESET). This is usually temporary — try again.
[CCD CycleHealth] unhealthy cycle for local_1955ac2e-... (689s, hadFirstResponse=true, reason=api_error)
[CCD CycleHealth] unhealthy cycle for local_1955ac2e-... (459s, hadFirstResponse=true, reason=api_error)

First occurrence: 2026-08-05 20:31:13, immediately after auto-updating to release 'Claude 1.24012.11' on 2026-08-04 18:39:53. Recurred 08-13, 08-14, 08-17 on later versions up to 1.30096.5.0.

Steps to Reproduce

1. Open the Claude desktop app on Windows
2. Send a prompt that requires a long/slow-generating response (multi-minute)
3. Wait for the response to stream for several minutes
4. Connection drops with ECONNRESET; app shows "Request failed · retrying"

Network-level causes have been ruled out: clean DNS, TLS handshake, 0% packet loss, no proxy/VPN, reproduces identically on home wired Ethernet, home Wi-Fi, and mobile hotspot.

Claude Model

Opus

Is this a regression?

Yes, this worked in a previous version

Last Working Version

before 1.24012.11 (working until early Aug 2026)

Claude Code Version

2.1.215 (Claude Code)

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

PowerShell

Additional Information

_No response_