#26807 — macOS: EHOSTUNREACH / FailedToOpenSocket when VPN Network Extension leaves orphaned virtual interfaces

[ElioNeto]

Describe the bug

OpenCode fails to connect to custom providers on macOS when a VPN application (ProtonVPN, Mullvad, etc.) has installed a Network Extension that leaves behind orphaned virtual interfaces after disconnection. The error logged is:

AI_APICallError → FailedToOpenSocket (EHOSTUNREACH)

The connection succeeds via curl, ping, and nc, but Node.js fetch and raw TCP sockets from the system Node.js and Python all fail with EHOSTUNREACH. The opencode models command may work (GET requests) while opencode run hangs or fails (POST requests with large payloads).

Root Cause

VPN Network Extensions (ProtonVPN WireGuard, Mullvad, etc.) create virtual tunnel interfaces (ipsec0, ipsec1, etc.) that claim the same subnet as the physical LAN interface. When the VPN disconnects, these interfaces can remain UP with stale IPs, causing the macOS kernel to route connect() syscalls from certain processes into the dead interface.

In this specific case:

• ipsec1 and ipsec2 persisted with config 192.168.1.174 → 192.168.1.174 netmask 0xffffff00
• Default routes pointed at these dead interfaces
• Only curl, nc, ping worked -- Node.js/Python got EHOSTUNREACH

To Reproduce

1. Install a VPN with a Network Extension (e.g., ProtonVPN, Mullvad)
2. Connect and disconnect the VPN
3. Configure OpenCode with a custom provider pointing to a LAN IP
4. Run opencode -m provider/model "hello"

Expected behavior

OpenCode should either:

• Connect succ

[Truncado — 2623 chars totais]

[ElioNeto]

Skipping — platform-specific issue (macOS VPN Network Extension). Cannot reproduce on Linux. Needs manual triage on macOS.

[ElioNeto]

Skipping — requires manual triage. Unable to resolve automatically due to complexity, platform/API constraints, or insufficient information.