Repository navigation
bug: gateway crash-loops on macOS — binds to VM-internal podman bridge IP (10.89.0.1) on host #1358
Description
Description
brew services restart openshell on macOS results in a crash loop. The gateway process starts, binds successfully to 127.0.0.1:17670, but then also attempts to bind to 10.89.0.1:17670 — the gateway IP of the openshell-docker podman network. On macOS with podman machine (libkrun), this address only exists inside the Linux VM and is not reachable from the host. The bind fails with EADDRNOTAVAIL (os error 49), the process exits, and launchd respawns it every ~10 seconds.
Actual behavior: Gateway crash-loops, brew services list shows error status with exit code 1.
Expected behavior: Gateway should not attempt to bind to podman bridge IPs on macOS, since they are VM-internal addresses unreachable from the host.
Reproduction Steps
- Install openshell via Homebrew on macOS (Apple Silicon)
- Have podman machine running (libkrun)
brew services restart openshellbrew services listshowsopenshell error 1
Logs
stderr (/opt/homebrew/var/log/openshell/openshell-gateway.err.log):
Error: × transport error: failed to bind to 10.89.0.1:17670: Can't assign requested
│ address (os error 49)
Repeats every ~10 seconds as launchd respawns.
stdout (/opt/homebrew/var/log/openshell/openshell-gateway.out.log):
INFO openshell_server::cli: Starting OpenShell server bind=127.0.0.1:17670
INFO openshell_server: Using compute driver driver=docker
INFO openshell_server: Server listening address=127.0.0.1:17670
The primary bind to 127.0.0.1:17670 succeeds, but a secondary bind to the podman bridge gateway IP fails.
system log shows the spawn/inactive cycle:
Successfully spawned openshell-gateway-homebrew-service[60695] because semaphore
service inactive: homebrew.mxcl.openshell
Analysis
The openshell-docker podman network has subnet 10.89.0.0/24 with gateway 10.89.0.1. The gateway binary discovers this network and tries to also listen on the bridge gateway IP. On Linux (native podman), this would work because the bridge interface exists on the host. On macOS with podman machine (libkrun/Apple HV), all podman networking is inside the VM — 10.89.0.1 is not a host-side address.
$ ifconfig | grep 10.89
(no output — address does not exist on host)
$ podman network inspect openshell-docker | jq '.[0].subnets'
[{"subnet": "10.89.0.0/24", "gateway": "10.89.0.1"}]
Environment
- OS: macOS (Darwin 25.4.0, Apple Silicon)
- OpenShell: 0.0.39 (Homebrew, built from source)
- Podman: 5.8.2 (libkrun VM type)
- Podman machine: running
Related Issues
- bug: Podman driver fails on macOS with stale Podman machine — host-gateway unresolvable #1307 — same class of issue: podman bridge IPs are VM-internal on macOS. That issue covers
host-gatewayresolution in containerhostadd; this issue is about the gateway server itself binding to the bridge IP.
Proposed Fix
When running on macOS with podman machine, the gateway should skip binding to podman bridge network gateway IPs (they are unreachable from the host). The gateway could:
- Detect macOS + podman machine and only bind to the configured
OPENSHELL_BIND_ADDRESS - Probe whether the bridge IP is actually assigned to a local interface before attempting to bind
- Treat the bridge bind failure as non-fatal (log a warning, continue with
127.0.0.1listener only)
Note
Responses generated with Claude
Activity
WilliamK112 commentedon Jun 18, 2026
Thanks for the detailed report. I checked the current
maincode path and the release history against the reported0.0.39version.What I found:
v0.0.47.192.168.127.254) for the sandbox host aliases. That merge is included starting withv0.0.57.main, the gateway server only adds driver-provided extra listener addresses viastate.compute.gateway_bind_addresses(). The Podman setup path passes an empty extra bind-address list into the compute runtime, so I don't see the current Podman path requesting a bind on10.89.0.1:17670.I do not see an open PR needed for the current code as-is. Could this be retested on the latest release (
v0.0.65at the moment)? If it no longer reproduces there, this issue is probably closable as fixed after0.0.39. If it still reproduces, the most useful next diagnostic would be the effective gateway config / startup log showing where10.89.0.1:17670is being added as an extra bind address.maxamillion commentedon Jun 29, 2026
@kaovilai any chance you can retest on the latest release to validate that your issue is fixed? thank you!
kaovilai commentedon Jul 9, 2026
Retested on v0.0.79 (macOS Darwin 25.5.0, Apple Silicon, Podman 5.8.2 libkrun). Bug is fixed.
Gateway starts cleanly — binds only to
127.0.0.1:17670, detects the bridge network gateway IP (10.89.1.1) but does not attempt to bind to it. Useshost.containers.internal:17670for gRPC endpoint instead. NoEADDRNOTAVAILcrash-loop.Closing as fixed. Thanks for the pointers to #1516 and #1637.
Note
Responses generated with Claude