[BUG] Claude Desktop (macOS): in-flight completion stream dies with "TypeError: network error" when router deprecates/renumbers IPv6 prefixes; not retried, response lost

What's Wrong?

On macOS, Claude Desktop intermittently loses long responses ("No reply yet" / "Connection lost"). The renderer log shows a fetch TypeError: network error on the completion stream, marked non-retryable, so the reply is dropped. For the failures I could check (Sep 17-18), every one coincided (same second) with a macOS IPv6 configuration change (network changed ... v6(en1...)) caused by my router repeatedly deprecating and re-issuing IPv6 prefixes. With IPv6 disabled on the router, failures stopped, and three long multi-tool workloads that previously failed every time completed cleanly. The same Mac on a different network (the ISP gateway's Wi-Fi, bypassing the router) was also clean.

Environment

• macOS 27.0 (build 26A428), Mac16,10 (Mac mini, Apple silicon)
• Claude Desktop 2.2553.1
• Network: eero mesh gateway behind an AT&T gateway (double NAT), Mac on 5 GHz Wi-Fi, strong signal, single access point
• Router advertises IPv6 (SLAAC) with rotating prefixes (details below)

Error Messages/Logs

File: ~/Library/Logs/Claude/claude.ai-web.log. This is ONE failure (4 lines in the same second), not three retries:

2026-09-18 17:06:40 [error] [COMPLETION] Request failed {"name":"TypeError","message":"network error","stack":"TypeError: network error"}
2026-09-18 17:06:40 [error] [COMPLETION] Not retryable error, throwing
2026-09-18 17:06:40 [error] [COMPLETION] Non-API stream error {"name":"TypeError","message":"network error","stack":"TypeError: network error"}
2026-09-18 17:06:40 [error] Uncaught (in promise) TypeError: network error
2026-09-18 17:06:42 [error] [COMPLETION] Failed all attempts to invalidate conversation tree with consistency=eventual {...}
2026-09-18 17:06:42 [warn] [COMPLETION] message_store_sync_blocked {"reason":"tree_shrink","prev_tree_count":34,"new_tree_count":32,...}

No net::ERR_* code is logged for these failures.

Frequency

Onset early Aug 2026. Distinct failures per day: Aug 27: 22, Aug 28: 16, Aug 29: 15, Aug 30: 31, Aug 31: 4, Sep 1: 6, Sep 2: 16, Sep 16: 15, Sep 17: 4, Sep 18: 2. Intervals between failures ranged from ~6 to ~54 minutes, only during active streaming.

Evidence it is triggered by local IPv6 address changes

• For the 4 failures inside my macOS unified-log window (Sep 17 22:06:20, Sep 17 22:28:15, Sep 18 17:06:40, Sep 18 17:25:04), configd/IPMonitor logged network changed ... v6(en1...) in the same second as the failure.
• Those IPv6 changes happened ~441 times in ~27 hours (about one per 3.6 minutes), so a chance same-second match is ~1% per event.
• The router (eero) is the only IPv6 default router. A snapshot of the Mac's addresses showed a deprecated global /64 (preferred lifetime 0) being replaced by a new global /64, plus several different ULA prefixes with short lifetimes.
• After disabling IPv6 on the router (Sep 18): zero failures since, and no IPv6 "network changed" entries in the first few minutes I checked afterward. Three long, multi-tool workloads that used to fail every time completed normally.

What I ruled out

Router hardware (replaced with a new unit, no change), SQM/QoS toggle (no change), router security filtering (off), API reachability (api.anthropic.com responded at every failure), and the Mac itself (clean on the ISP gateway's Wi-Fi).

What Should Happen?

1. A stream aborted by a local network change should be retried or resumed (or the completed reply re-fetched), not treated as non-retryable and dropped.
2. If Chromium's network-change handling (ERR_NETWORK_CHANGED-style) is aborting streams on IPv6 address changes that don't affect the connection's source address, please consider tolerating them.
3. Log the underlying net error code for [COMPLETION] failures. The generic TypeError: network error made this take weeks to diagnose.
4. After the failure, the conversation shows "No reply yet" and message_store_sync_blocked (tree_shrink). If the reply finished server-side, offer a way to re-sync it.

Steps to Reproduce

Intermittent, no deterministic repro. On a network where the router keeps deprecating and re-issuing IPv6 prefixes, stream long responses (or run tool-heavy sessions) in Desktop; failures appeared within tens of minutes. To check the correlation on macOS: compare failure timestamps in claude.ai-web.log against /usr/bin/log show --predicate 'process == "configd" AND eventMessage CONTAINS "network changed"'. Disabling IPv6 on the router stops the failures.

Related issues

• #82208 has the same log signature (TypeError: network error followed by message_store_sync_blocked / tree_shrink, on Linux) with the trigger unspecified. This report adds a concrete trigger (local IPv6 address changes) on macOS.
• #82242 (closed) reports turns failing on a local network path change while the host is online.
• #84463 has similar timing (Aug 2026, macOS, Desktop-only mid-response drops) but a different signature (Connection closed mid-response, remote-tools-device 1006 reconnects). My main*.log has neither.

Happy to attach fuller log excerpts.

Start with the completion-stream handling associated with ~/Library/Logs/Claude/claude.ai-web.log, and compare its failure timestamps with the provided configd log command and related issues #82208 and #82242. Done means local network-change failures are handled without silently losing the response, the conversation can recover when appropriate, and completion failures expose the underlying network error rather than only TypeError: network error.