#Setup Help

1 messages · Page 1 of 1 (latest)

turbid furnace
#

When I run docker compose logs -f openclaw-gateway

I get the following error:

openclaw-gateway-1 | 2026-03-07T06:22:11.938+00:00 Gateway failed to start: Error: non-loopback Control UI requires gateway.controlUi.allowedOrigins (set explicit origins), or set gateway.controlUi.dangerouslyAllowHostHeaderOriginFallback=true to use Host-header origin fallback mode

ionic lindenBOT
#

To help others find answers, you can mark your question as solved via Right click solution message -> Apps -> âś… Mark Solution

kind fossilBOT
#

That error means your Gateway is listening on a non-loopback interface (e.g. bind: "lan" / 0.0.0.0). In that mode, OpenClaw refuses to start the Control UI unless you explicitly allow the browser origin that’s allowed to open the WebSocket (DNS-rebinding hardening).

Fix (recommended): set gateway.controlUi.allowedOrigins

Pick the origin where your browser loads the Control UI from (scheme + host + port; no path).

Common Docker/VPS setup (Gateway on LAN, you access via an SSH tunnel on your laptop):

docker compose run --rm openclaw-cli \
  config set gateway.controlUi.allowedOrigins '["http://127.0.0.1:18789"]' --strict-json

Then restart:

docker compose up -d openclaw-gateway
# or: docker compose restart openclaw-gateway
#

If you access via a domain / reverse proxy, use that instead, e.g.:

gateway: {
  controlUi: {
    allowedOrigins: ["https://control.example.com"],
  },
}

Docs: https://docs.openclaw.ai/web/control-ui (see the “Non-loopback Control UI deployments…” section)

Alternate (not recommended): Host-header fallback

You can bypass the explicit allowlist with:
gateway.controlUi.dangerouslyAllowHostHeaderOriginFallback=true
…but it’s intentionally labeled dangerous, so only do it if you understand the tradeoff.

If you tell me how you’re accessing the UI (SSH tunnel to 127.0.0.1:18789 vs direct IP vs domain), I can tell you the exact allowedOrigins value(s) to use.

turbid furnace
#

UI is being accessed via ssh tunnel

kind fossilBOT
#

If you’re accessing the Control UI through an SSH tunnel (so your browser URL is something like http://127.0.0.1:18789/), then your allowed origin is your local browser origin, not the VPS IP.

Set:

docker compose run --rm openclaw-cli \
  config set gateway.controlUi.allowedOrigins '["http://127.0.0.1:18789","http://localhost:18789"]' --strict-json

Then restart the gateway container:

docker compose restart openclaw-gateway

Notes:

  • Origins must be exact: http:// vs https://, and the port must match what you open in the browser.
#
  • If you’re tunneling a different port, replace 18789 accordingly.

Also, what does docker compose run --rm openclaw-cli --version print? (Just to make sure we’re looking at the right behavior for your build.)

turbid furnace
# 
[+]  1/1t 1/1
 âś” Container openclaw-openclaw-gateway-1 Started                                                          0.0s
Container openclaw-openclaw-cli-run-2f51ef4fbc30 Creating 
Container openclaw-openclaw-cli-run-2f51ef4fbc30 Created 
Error response from daemon: cannot join network namespace of container: Container 949f8122b13c4a938c331aac17b8a288c3f8f28577114806ff633e6aff08c57d is restarting, wait until the container is running```
kind fossilBOT
#

Yep — that happens because your openclaw-cli service is (most likely) configured with network_mode: "service:openclaw-gateway" (or similar), so Docker tries to “join” the gateway container’s network namespace. Since the gateway is in a restart loop, Docker refuses.

Two easy ways out:

Option A (fastest): edit the config file on the host

Your compose mounts:

  • ${OPENCLAW_CONFIG_DIR}:/home/node/.openclaw

So on the VPS host, edit:

  • ${OPENCLAW_CONFIG_DIR}/openclaw.json (often ~/.openclaw/openclaw.json)

Add this (JSON5 is fine):

# 
{
  gateway: {
    controlUi: {
      allowedOrigins: ["http://127.0.0.1:18789", "http://localhost:18789"],
    },
  },
}

Then:

docker compose restart openclaw-gateway

Option B: run the config command using the gateway image (no openclaw-cli needed)

#

This avoids the broken network-namespace join entirely:

docker compose run --rm --no-deps openclaw-gateway \
  node dist/index.js config set gateway.controlUi.allowedOrigins \
  '["http://127.0.0.1:18789","http://localhost:18789"]' --strict-json

Then restart:

docker compose restart openclaw-gateway

If your SSH tunnel uses a different local port than 18789, tell me what URL you open in the browser (exactly), and I’ll give you the exact allowedOrigins value.

#

That’s almost always tool policy, not “browser setup”.

openclaw browser … from the CLI can work fine, but your agent can only use the browser if the browser tool is allowed for that session/agent.

1) Check if you’re on the default “messaging” tool profile

New setups often have:

  • tools.profile: "messaging"

That profile does not include browser (it only includes messaging + session tools). Browser lives in group:ui.

Fix in ~/.openclaw/openclaw.json:

{
  tools: {
# 
    profile: "messaging",
    allow: ["group:ui"], // enables browser + canvas
    // or: allow: ["browser"]
  },
}

(Also make sure you don’t have tools.deny: ["browser"], and if you have per-agent overrides under agents.list[].tools, that they aren’t denying it.)

Config reference (tool groups/profiles): https://docs.openclaw.ai/gateway/configuration#tools

2) If you’re using the Chrome extension relay

Even with the tool allowed, the chrome profile only works when you’ve attached the extension to a tab (badge ON). It won’t auto-attach.

Docs: https://docs.openclaw.ai/tools/chrome-extension

#

Quick question

When the agent “can’t access it”, what does it say exactly?

  • “Tool browser not allowed” → tool policy (above)
  • “No tab connected / pairing required” → extension not attached / wrong profile
  • Something else → paste the error text and I’ll zero in fast.
#

Yeah — good call. This thread is about the Control UI allowedOrigins / gateway startup error.

For the browser-control question, please start a new thread/post in #setup-help and include:

  • what the agent says (exact error text),
  • whether you’re using openclaw managed browser or the Chrome extension relay,
  • and a snippet of your tools.profile / tools.allow config.

Keeps things searchable (Answer Overflow) and way easier to troubleshoot.

turbid furnace
#

Now I see this issue: [gateway] ⚠️ Gateway is binding to a non-loopback address. Ensure authentication is configured before exposing to public networks.

kind fossilBOT
#

That log line is just a safety warning, not a failure.

You’re running the gateway with --bind lan / 0.0.0.0 (non-loopback), so OpenClaw warns: “don’t expose this without auth”.

If you followed the Docker/VPS guide, you’re still safe because Docker is likely publishing the port only on VM loopback, e.g.:

ports:
  - "127.0.0.1:${OPENCLAW_GATEWAY_PORT}:18789"

So nothing is publicly reachable unless you remove the 127.0.0.1: prefix (or open the firewall).

What to double-check:

  1. You have a real token set (strong random), e.g. OPENCLAW_GATEWAY_TOKEN=...
  2. You did not set gateway.auth.mode: "none" anywhere
  3. Your port publishing is still loopback-only (or you’ve firewalled it)
#

If the UI now loads through your SSH tunnel and asks for a token/password, you’re good.

If this fixed your original startup issue, please right-click the solution message → Apps → ✅ Mark Solution so it gets indexed on Answer Overflow.