Claude Desktop macOS: bridge100 subnet (192.168.64.0/24) not configurable, conflicts with common LAN ranges

Summary

Claude Desktop on macOS creates a bridge100 interface on 192.168.64.1/24 via Apple's Virtualization.framework (vmnet). This subnet is hardcoded and cannot be changed. Any user whose LAN or VPN uses an overlapping range (e.g., 192.168.64.0/22) loses connectivity to all devices in that /24 — both on the local network and through VPN/WireGuard tunnels.

Environment

• macOS 26.3 (Tahoe)
• Claude Desktop (current as of 2026-02-27)
• LAN: 192.168.64.0/22
• WireGuard tunnel to remote network on same range

Symptoms

• bridge100 claims 192.168.64.1/24, hijacking all traffic to 192.168.64.x
• route -n get 192.168.64.x shows interface: lo0 instead of the actual NIC or WG tunnel
• LAN devices on 192.168.64.x unreachable while Claude Desktop is running
• WireGuard tunnel appears connected but traffic never leaves the Mac

What we tried

1. com.apple.vmnet.plist Shared_Net_Address — macOS Tahoe ignores this setting entirely (confirmed by canonical/multipass#4581)
2. "coworkNetworkMode": "gvisor" in config.json — works as a workaround (no bridge100 created), but gvisor has documented stability issues (#24933)

Feature request

Add a configurable subnet option, e.g.:

{
  "coworkSubnet": "192.168.100.0/24"
}

The Windows team already fixed a similar hardcoded-subnet conflict (172.16.0.0/24) in v1.1.4328 (#28668). macOS needs the same treatment.

Apple's own container tool supports per-app subnet config via defaults write com.apple.container.defaults network.subnet. Claude Desktop should offer equivalent configurability.

Current workaround

Setting "coworkNetworkMode": "gvisor" in ~/Library/Application Support/Claude/config.json bypasses vmnet entirely. This eliminates the conflict but trades it for potential Cowork instability.