Skip to content

bug: gateway crash-loops on macOS — binds to VM-internal podman bridge IP (10.89.0.1) on host #1358

Closed

Description

@kaovilai

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

  1. Install openshell via Homebrew on macOS (Apple Silicon)
  2. Have podman machine running (libkrun)
  3. brew services restart openshell
  4. brew services list shows openshell 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

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:

  1. Detect macOS + podman machine and only bind to the configured OPENSHELL_BIND_ADDRESS
  2. Probe whether the bridge IP is actually assigned to a local interface before attempting to bind
  3. Treat the bridge bind failure as non-fatal (log a warning, continue with 127.0.0.1 listener only)

Note

Responses generated with Claude

Activity

  1. WilliamK112 commented on Jun 18, 2026

    @WilliamK112

    Thanks for the detailed report. I checked the current main code path and the release history against the reported 0.0.39 version.

    What I found:

    • fix(docker): use host-gateway callbacks on macOS #1516 changed macOS Docker-compatible callback routing so it uses host-gateway aliases instead of asking the host gateway process to bind a VM bridge IP. That merge is included starting with v0.0.47.
    • fix(podman): avoid host-gateway on macOS machines #1637 changed the Podman-machine macOS default to use gvproxy's host-loopback IP (192.168.127.254) for the sandbox host aliases. That merge is included starting with v0.0.57.
    • On current main, the gateway server only adds driver-provided extra listener addresses via state.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 on 10.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.65 at the moment)? If it no longer reproduces there, this issue is probably closable as fixed after 0.0.39. If it still reproduces, the most useful next diagnostic would be the effective gateway config / startup log showing where 10.89.0.1:17670 is being added as an extra bind address.

  2. maxamillion commented on Jun 29, 2026

    @maxamillion
    Collaborator

    @kaovilai any chance you can retest on the latest release to validate that your issue is fixed? thank you!

  3. kaovilai commented on Jul 9, 2026

    @kaovilai
    Author

    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. Uses host.containers.internal:17670 for gRPC endpoint instead. No EADDRNOTAVAIL crash-loop.

    INFO openshell_server::cli: Starting OpenShell server bind=127.0.0.1:17670
    INFO openshell_server: Using compute driver driver=podman
    INFO openshell_driver_podman::driver: Bridge network ready network=openshell gateway_ip=Some("10.89.1.1")
    INFO openshell_driver_podman::driver: Auto-detected gRPC endpoint grpc_endpoint=http://host.containers.internal:17670 tls=false
    INFO openshell_server: Server listening address=127.0.0.1:17670
    

    Closing as fixed. Thanks for the pointers to #1516 and #1637.

    Note

    Responses generated with Claude

  4. removed
    state:triage-neededOpened without agent diagnostics and needs triage
    on Oct 1, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions