← Back to PRs

#12504: fix: allow docker cli container to connect to gateway

by bvanderdrift open 2026-02-09 09:58 View on GitHub →
docker stale
# Reason for PR Docker users are reporting issues reaching the gateway container. Examples: * https://github.com/openclaw/openclaw/issues/7976#issuecomment-3843441376 * https://github.com/openclaw/openclaw/issues/4142#issuecomment-3862093846 # Cause The gateway by default only trusts localhost connections. The CLI by default tries to find the gateway on localhost. Both are containers mounted on different network interfaces in Docker, so they can't reach or trust eachother. # Solution Share the same network between the containers so that both are available/originate on localhost for the other. # Proof After running `./docker-setup.sh`: ## `openclaw/openclaw/main` ``` $: docker compose run --rm openclaw-cli gateway probe 🦞 OpenClaw 2026.2.6-3 (unknown) Give me a workspace and I'll give you fewer tabs, fewer toggles, and more oxygen. │ ◇ Gateway Status Reachable: no Probe budget: 3000ms Discovery (this machine) Found 0 gateways via Bonjour (local.) Tip: if the gateway is remote, mDNS won’t cross networks; use Wide-Area Bonjour (split DNS) or SSH tunnels. Targets Local loopback ws://127.0.0.1:18789 Connect: failed - connect failed: connect ECONNREFUSED 127.0.0.1:18789 ``` ## This PR: ``` $: docker compose run --rm openclaw-cli gateway probe 🦞 OpenClaw 2026.2.6-3 (unknown) Give me a workspace and I'll give you fewer tabs, fewer toggles, and more oxygen. │ ◇ Gateway Status Reachable: yes Probe budget: 3000ms Discovery (this machine) Found 0 gateways via Bonjour (local.) Tip: if the gateway is remote, mDNS won’t cross networks; use Wide-Area Bonjour (split DNS) or SSH tunnels. Targets Local loopback ws://127.0.0.1:18789 Connect: ok (80ms) · RPC: ok Gateway: 5904ab6bbdb2 (172.19.0.2) · linux 6.10.14-linuxkit · app unknown Wide-area discovery: unknown ``` # Note I found that this solution was already submitted in https://github.com/openclaw/openclaw/pull/5712/changes. I'm creating a new PR in the hope this can get visibility and also fix the failing CI jobs there. <!-- greptile_comment --> <h2>Greptile Overview</h2> <h3>Greptile Summary</h3> This PR updates `docker-compose.yml` to run the `openclaw-cli` service in the same network namespace as `openclaw-gateway` via `network_mode: "service:openclaw-gateway"`, and adds `depends_on: [openclaw-gateway]` to express the intended startup ordering. The goal is to make `127.0.0.1:18789` from the CLI container resolve to the gateway container when using Docker Compose, addressing reports that the CLI cannot reach a gateway that only trusts localhost when both run in separate containers. <h3>Confidence Score: 4/5</h3> - This PR appears safe to merge and is narrowly scoped to Docker Compose networking. - Change is limited to adding `network_mode: service:openclaw-gateway` for the CLI container plus a `depends_on` entry. The YAML is valid and the change aligns with Docker’s supported pattern for sharing a network namespace to make localhost reachable across containers. I did not find a definite functional regression introduced by these edits given the current compose file (CLI has no ports/networks settings that would conflict with `network_mode`). - docker-compose.yml <!-- greptile_other_comments_section --> <sub>(2/5) Greptile learns from your feedback when you react with thumbs up/down!</sub> <!-- /greptile_comment -->

Most Similar PRs