[BUG] Windows: undock (Ethernet->Wi-Fi interface swap) ends the in-flight turn with no retry, silently killing background sessions

Preflight Checklist

• [x] 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?

On Windows, a clean network interface change — undocking a laptop, so the USB-dock Ethernet NIC goes away and Wi-Fi takes over — kills the in-flight streaming request and ends the turn with no retry. The session prints:

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

and stops. There is no Retrying (n/10), and no system/api_error record is written to the session JSONL — unlike the transient failures in #87987, where the main loop logged api_error and recovered. Here the stream error is treated as a terminal turn outcome, not a retryable one.

This is not a "the network is broken" report. The interface swap is orderly and the new path is healthy within ~2 seconds; every other program on the machine rides through it. The client simply never tries again.

Why this hurts disproportionately: it silently ends background sessions. All six occurrences I can evidence were sessionKind: "bg". For an interactive session you see the error and press enter. For a background job there is nobody to press enter: the runtime emits turn_duration, drains the queue, and the job sits idle. In one case queued task-notifications arrived 25 minutes later, were dequeued, and still produced no turn. Another background session was dead for 16 hours until I typed "Status?" — work I believed was running had stopped at the moment I walked away from my desk, which is exactly when an undock happens.

Evidence: exact same-second correlation with the NIC transition

Six occurrences in my local session transcripts. For the five inside the 32-day Windows event-log retention window, each one lands on the same second as a Microsoft-Windows-NetworkProfile/Operational id=10001 (Network Disconnected) event:

| Transcript timestamp (UTC) | NetworkProfile event | CC version | Recovered? |
|---|---|---|---|
| 2026-09-15 04:37:50 | 04:37:50 id=10001 Disconnected | 2.1.272 | No — session idle until reconnect 3h later |
| 2026-09-15 02:26:08 | 02:26:08 id=10001 → 02:26:10 id=10000 Connected | 2.1.272 | Yes, only because a queued task-notification drove a new turn |
| 2026-09-14 09:19:28 | 09:19:28 id=10001 Disconnected | 2.1.270 | No — dead 16h until I typed into it |
| 2026-09-14 08:03:10 | 08:03:10 id=10001 → 08:03:12 id=10000 Connected | 2.1.270 | No — idle despite the path being back in 2s |
| 2026-08-31 13:25:37 | 13:25:37 id=10001 Disconnected | 2.1.251 | Yes, only because a user message was already queued |
| 2026-08-17 07:38:25 | (outside log retention) | 2.1.233 | Yes, user typed 2 min later |

The pattern in the "recovered" rows is the point: recovery never came from a retry. It came from something else happening to enqueue a turn. With an empty queue, the session just stops.

The JSONL shape is identical every time — a real assistant message, then:

{"type":"assistant","message":{"model":"<synthetic>", ... "API Error: Connection lost mid-response. The response above may be incomplete."}}
{"type":"system","subtype":"turn_duration","durationMs":52967, ...}

No api_error record, no retry record, in between or after.

Steps to Reproduce

1. Start a background session on a Windows laptop docked over USB-C Ethernet: claude with a long-running turn (a multi-minute tool sequence works well).
2. While the model is mid-stream, undock. Ethernet goes away, Wi-Fi associates within a couple of seconds.
3. Observe API Error: Connection lost mid-response. The turn ends. Nothing retries.
4. Leave the session alone with nothing queued. It stays idle indefinitely.

Get-WinEvent -FilterHashtable @{LogName='Microsoft-Windows-NetworkProfile/Operational'} | Where-Object Id -in 10000,10001 gives the transition timestamps to line up against the session JSONL.

Expected Behavior

A mid-stream socket loss should be retried like any other transient network error — re-resolve, open a fresh TCP connection on the current default route, and resume the turn. At minimum, a background session whose turn was terminated by a network error should not silently go idle; the harness should retry or surface a task notification so the job is recoverable without a human noticing it stopped.

Environment

• Claude Code 2.1.272 (also 2.1.270, 2.1.251, 2.1.233 — long-standing, not a recent regression)
• Windows 11 Pro 10.0.26200 (x64)
• Node v24.20.0
• Model: claude-opus-5
• Wired NIC: Realtek USB 2.5GbE (dock). Wireless: Intel Wi-Fi 7 BE211. The Wi-Fi adapter re-enumerates across dock cycles (Wi-Fi, Wi-Fi 2, Wi-Fi 5 all present, only one Up), so the interface index changes, not just the route.
• Tailscale is installed. It is not the trigger — the failing transitions are on the physical profile, and the many Tailscale-only up/down events in the same log produce no errors.
• No proxy, no VPN-based TLS inspection on this path.

Related but distinct

• #89552 — macOS, Wi-Fi drop, sticky ECONNRESET that survives relaunch and needs a reboot. Mine is Windows, an orderly interface swap, the client is not poisoned (a new session works immediately), and the defect is the missing retry on the turn that was in flight.
• #87987 — subagent streams dying without retry. Same missing-retry theme, but that one's parent loop did log api_error and recover; here nothing is logged at all.