Claude Desktop VM (bridge100) hijacks IPv4 default route, breaking internet connectivity

Bug Description

The Claude Desktop app's internal Linux VM (claudevm.bundle) creates a bridge100 network interface that intermittently hijacks the macOS IPv4 default route. This causes all IPv4 traffic to be routed through the VM's bridge instead of the Wi-Fi interface (en0), resulting in ERR_ADDRESS_UNREACHABLE errors across the system — browsers, git, curl, etc.

Environment

• macOS: 15.5 (Build 24F74)
• Claude Desktop: 1.1.3363
• Hardware: MacBook Pro M4, 24GB RAM
• Network: Wi-Fi connected to Telekom Speedport router (Germany)

Symptoms

• Chrome/browsers show ERR_ADDRESS_UNREACHABLE on many sites (GitHub, Vercel, etc.)
• git push/pull fails: Failed to connect to github.com port 443
• Safari partially works (falls back to IPv6)
• IPv6 connectivity is unaffected — only IPv4 is broken

Root Cause

The VM process (com.apple.Virtualization.VirtualMachine, launched from /Users/<user>/Library/Application Support/Claude/vm_bundles/claudevm.bundle/) creates a bridge100 interface with a vmenet0 member. This bridge:

1. Steals the IPv4 default route — default → link#26 (bridge100) instead of default → 192.168.2.1 (en0)
2. Removes the Wi-Fi subnet route — the 192.168.2.0/24 → en0 route disappears intermittently
3. Persists across network resets — sudo killall -9 configd, Wi-Fi toggle, and DHCP renewal all fail to permanently fix the routing while the VM is running. The bridge re-asserts its routes.
4. Creates a catch-22 — without the subnet route, the gateway (192.168.2.1) is "unreachable", so sudo route add default 192.168.2.1 fails with Network is unreachable

Observed Network State (while broken)

# IPv4 routing table — bridge100 has stolen the default route
Routing tables
Internet:
Destination        Gateway            Flags        Netif
default            link#26            UCSIg        bridge100   ← WRONG
127                127.0.0.1          UCS          lo0
192.168.64         link#26            UC           bridge100
192.168.64.1       ae.7.75.a3.42.64  UHLWIi       lo0

# Note: NO route for 192.168.2.0/24 via en0, despite en0 having IP 192.168.2.x

# bridge100 interface created by Claude VM
bridge100: flags=8a63<UP,BROADCAST,SMART,RUNNING,ALLMULTI,SIMPLEX,MULTICAST>
  inet 192.168.64.1 netmask 0xffffff00 broadcast 192.168.64.255
  member: vmenet0 flags=10803<LEARNING,DISCOVER,PRIVATE,CSUM>

# VM process
PID 78662 /System/Library/Frameworks/Virtualization.framework/.../com.apple.Virtualization.VirtualMachine
  open file: /Users/<user>/Library/Application Support/Claude/vm_bundles/claudevm.bundle/efivars.fd

Resolution

Quitting the Claude Desktop app (which stops the VM and removes bridge100) followed by sudo killall -9 configd immediately restored correct IPv4 routing and full connectivity.

Expected Behavior

The Claude VM's bridge100 bridge should use NAT mode (or equivalent) so it does not interfere with the host's routing table. The VM should never modify the system's default IPv4 route or remove subnet routes for physical interfaces.

Steps to Reproduce

1. Connect Mac to Wi-Fi network
2. Launch Claude Desktop app (VM starts, bridge100 is created)
3. Wait — IPv4 connectivity degrades intermittently
4. Observe ERR_ADDRESS_UNREACHABLE in browsers, git failures, etc.
5. Run netstat -rn -f inet — default route points to bridge100 instead of Wi-Fi interface

Note: This may be specific to certain network configurations (DHCP, router type, IPv4/IPv6 dual-stack). The issue was observed consistently on a Telekom Speedport router in Germany.