SIGABRT crash on VPN connect/disconnect (network route change) — regression in 2.1.177, still present in 2.1.202

Environment

• Claude Code: 2.1.202 (also reproduced on 2.1.197, 2.1.179, 2.1.177; not on ≤2.1.170)
• macOS 15 (Darwin 24.6.0), Apple Silicon
• Cisco Secure Client 5.1.9.113 (unchanged since Sep 2025 — ruled out as the trigger side)
• Full-tunnel VPN (default route moves to utun on connect)

Bug

Any VPN connect or disconnect while a claude session is running kills the process with SIGABRT within seconds. This includes automatic reconnects (laptop sleep/wake, VPN idle timeout), so sessions die overnight or whenever the machine sleeps. All running claude processes on the machine die at once (interactive TUI sessions and headless -p jobs alike). Shell shows zsh: abort.

This is a regression: the same VPN client, profile, and usage pattern were fine for months on builds ≤2.1.170. First seen immediately after updating to 2.1.177 (2026-06-12). Pinning autoUpdatesChannel: stable did not help once stable advanced past the regression (crash confirmed on stable 2.1.179).

Crash signature

Two crashes today alone (2026-07-14, builds 2.1.197 and 2.1.202), identical faulting stacks — deliberate abort() inside the claude binary, not a segfault:

exception: EXC_CRASH (SIGABRT), Abort trap: 6, terminated by own process
faulting thread:
  libsystem_kernel.dylib   __pthread_kill
  libsystem_pthread.dylib  pthread_kill
  libsystem_c.dylib        __abort
  libsystem_c.dylib        abort
  claude                   0x8de1c0
  claude                   0x8da37c
  claude                   0x8da88c   (0x8d9ff8 in the 2.1.197 crash)
  claude                   0x90324c   (0x902fe0 in 2.1.197)
  claude                   0x75d22c
  claude                   0xbf70e0
  claude                   0x6f5838

Full .ips crash reports available on request (2.1.202-2026-07-14-100456.ips, 2.1.197-2026-07-14-053458.ips).

Secondary fallout: terminal left in mouse-reporting mode

Because the process dies via abort(), TUI teardown never runs. The terminal is left with SGR mouse reporting (and bracketed paste) enabled, so after the crash every mouse movement floods the shell with escape-sequence fragments (zsh: command not found: 35M35, 51, 23M64, …) until the user runs reset. This fallout is new in recent builds (earlier crashes didn't leave the terminal wedged), suggesting the abort path moved earlier/deeper than any cleanup handler.

Repro

1. Start claude (interactive or -p) with Cisco Secure Client connected (full tunnel).
2. Disconnect the VPN (or let the laptop sleep so the VPN drops and auto-reconnects).
3. Within seconds, the claude process aborts. Reproduces ~100% on this machine since 2.1.177.

Relationship to existing issues

• #75572 (VPN change → stale pooled Bun sockets → silent indefinite hang) describes the same trigger but a different failure mode: that issue is a hang with no error; this one is a hard SIGABRT. Plausibly the same underlying network-change handling, but on this setup the process dies rather than hangs.
• #5674 (ECONNRESET after VPN/MTU issues) — again same environment class, different failure: those are per-request errors, not process aborts.

Expected

A network route change mid-session should surface as a retryable request error (as it did ≤2.1.170), not terminate the process — and if the process must die, terminal state should be restored on the way out.