multiple gateways | Friends of the Crustacean 🦞🤝 | Page 1

civic patrol Mar 12, 2026, 1:03 PM

#

I moved my Claw from a VM to physical computer. Followed all the migration instructions. But now I am unable to log in to the dashboard. I generated a new gateway token and entered it in the dashboard but no luck. Im on version 2026.03.11

tender karmaBOT Mar 12, 2026, 1:03 PM

#

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

jaunty otterBOT Mar 12, 2026, 1:05 PM

#

When the Dashboard won’t accept a token after a move, it’s almost always one of these:

you’re hitting the wrong gateway (old VM still up, or different host/port)
the gateway service is reading a different config than your CLI
you didn’t actually rotate the token (common gotcha: openclaw doctor --generate-gateway-token only sets one if missing)
you’re not “localhost” anymore (bind/tunnel/Tailscale expectations)

From the FAQ, the “correct” local flow is: open http://127.0.0.1:18789/ on the gateway machine and paste the value of gateway.auth.token into the Control UI auth setting. Docs: https://docs.openclaw.ai/help/faq#how-do-i-authenticate-the-dashboard-token-on-localhost-vs-remote

Quick checklist (please paste outputs)

On the new physical machine, run:

openclaw gateway status
openclaw status --all
openclaw config get gateway.auth.token

#

Things I’m looking for:

In openclaw gateway status: does it show RPC probe: ok and which URL/port it’s probing?
In openclaw status --all: do you see Config (cli) and Config (service) pointing to the same config? If they differ, you’ll keep chasing the wrong token.
Does openclaw config get gateway.auth.token match what you pasted?

If you truly want a new token

If you already had a token set, openclaw doctor --generate-gateway-token typically won’t rotate it. Do this instead, then restart:

openclaw config set gateway.auth.token "<new token>"
openclaw gateway restart

Also: where are you opening the dashboard from?

Same machine: use http://127.0.0.1:18789/
Different machine: use SSH tunnel or Tailscale Serve (recommended). The FAQ section above covers both.

#

Reply with:

the URL you’re opening in the browser
the output of openclaw gateway status (and whether Config service/cli differ)

…and we can pinpoint which of the 4 cases you’re hitting.

civic patrol Mar 12, 2026, 1:14 PM

#

Great. That worked. Now, how do I get the dashboard to show up on the other computers on my local network?

jaunty otterBOT Mar 12, 2026, 1:16 PM

#

To view the same Control UI (Dashboard) from other machines, you have two sane options:

Option A (recommended): keep Gateway on loopback + use Tailscale Serve

This avoids LAN binding + browser origin/security footguns, and it works from any device that’s on your tailnet (even if it’s physically on the same LAN).

Docs: https://docs.openclaw.ai/web (see “Integrated Serve (recommended)”)

Config shape:

{
  gateway: {
    bind: "loopback",
    tailscale: { mode: "serve" },
  },
}

#

Then open:

https://<magicdns>/

(Depending on your config, Control UI/WebSocket auth can be tokenless via Tailscale identity headers if gateway.auth.allowTailscale: true.)

Option B: bind the Gateway to your LAN IP and browse via `http://<lan-ip>:18789/`

This is what you want if you don’t want Tailscale.

Find the gateway machine’s LAN IP (e.g. 192.168.1.50)
Set:

gateway.bind: "lan"

Important: for non-loopback Control UI, you must set allowed origins or the gateway will refuse startup by default:

#

Docs: https://docs.openclaw.ai/web (see “Security notes”)

Example:

{
  gateway: {
    bind: "lan",
    controlUi: {
      allowedOrigins: [
        "http://192.168.1.50:18789",
        // add any hostname you’ll actually use from browsers too:
        // "http://openclaw.local:18789",
      ],
    },
  },

#

Restart the gateway (openclaw gateway restart), make sure your OS firewall allows inbound TCP 18789, then browse from another computer to:

http://192.168.1.50:18789/

…and paste the same gateway token you used locally.

Security note (worth saying out loud): the Dashboard is an admin surface (chat, config, exec approvals). Binding to LAN is fine on a trusted home network, but don’t expose it beyond that.

If you tell me:

macOS vs Linux on the new physical host, and
whether you want “works without installing anything on clients” (LAN bind) vs “works anywhere securely” (Tailscale)

…I can give you the exact minimal config for your setup.

civic patrol Mar 12, 2026, 1:25 PM

#

so if my other computer I wanted to access it from's IP addres was 192.168.0.10...

jaunty otterBOT Mar 12, 2026, 1:26 PM

#

Not the client computer’s IP.

gateway.controlUi.allowedOrigins wants the origin of the page you’re loading in the browser — i.e. the URL of the gateway host you type into the address bar.

So:

If the gateway machine (the one running OpenClaw) is 192.168.0.20, and you’re sitting at another PC (maybe 192.168.0.10) → you will open:

http://192.168.0.20:18789/

…and your allowedOrigins should include:

gateway: {
  bind: "lan",
  controlUi: {

#

    allowedOrigins: ["http://192.168.0.20:18789"],
  },
}

Only if the gateway machine itself is 192.168.0.10 would you use:

allowedOrigins: ["http://192.168.0.10:18789"]

You generally do not add every other computer on the LAN — because the UI is served from the gateway, so the browser’s origin is the gateway URL.

If you tell me the IP of the machine actually running the gateway, I’ll plug the exact string in for you.

civic patrol Mar 12, 2026, 1:30 PM

#

I added that, but I still cannot reach it. Do I have to do anything with MacOS Firewall?

jaunty otterBOT Mar 12, 2026, 1:32 PM

#

Yeah — macOS Firewall can absolutely be the reason you can’t reach :18789 from other machines, even if everything works on localhost.

Before touching firewall, do this quick split-test so we know what’s failing:

1) Is the gateway actually listening on LAN?

On the Mac that runs the gateway, try opening the dashboard using its LAN IP in a browser on that same Mac:

http://<gateway-mac-lan-ip>:18789/

If that doesn’t load on the same Mac, it’s not (yet) a firewall problem — it means the gateway is still bound to loopback, didn’t restart, or refused the non-loopback setup (origins/auth).

(Usually after changing gateway.bind you should do openclaw gateway restart to be sure.)

2) If it works on the Mac but not from other computers → firewall/network

On macOS:

System Settings → Network → Firewall

#

Temporarily turn Firewall Off to test.
- If that fixes it, turn it back On and go to Options…
  - Make sure whatever is running the gateway is allowed to accept incoming connections (often this shows up as node or the terminal/app that launched it).
  - Also ensure “Block all incoming connections” is OFF.

Because OpenClaw runs as a Node process, the firewall exception you need is commonly for the Node binary (especially if you use nvm/homebrew Node and it lives in a nonstandard path).

3) Also worth checking: router “client isolation”

If you’re testing from another device on Wi‑Fi, some routers have “AP/client isolation” enabled, which prevents device-to-device LAN access even if firewall is fine.

—

If you paste two things, I can tell you which branch you’re in immediately:

what URL you’re trying from the other computer (IP/hostname)
output of openclaw gateway status from the Mac running the gateway (it shows the probe URL / bind situation)

civic patrol Mar 12, 2026, 1:34 PM

#

If I turn off the firewall on the gateway machine, then I can connect to it

jaunty otterBOT Mar 12, 2026, 1:35 PM

#

Perfect — that pretty much proves your bind/origins/token stuff is fine, and it’s purely macOS Application Firewall blocking inbound.

On macOS you don’t “open a port” so much as you allow the executable that’s listening (usually node) to accept incoming connections.

Fix (recommended)

Turn the Firewall back On
Go to System Settings → Network → Firewall → Options…
Look for node (or sometimes the app that launched it) and set it to Allow incoming connections
- If it’s not listed, click + and add your Node binary.

To find the exact Node path OpenClaw is using, run on the gateway Mac:

which node
which openclaw

#

Common Node paths are:

Apple Silicon Homebrew: /opt/homebrew/bin/node
Intel Homebrew: /usr/local/bin/node
nvm: ~/.nvm/versions/node/vXX.X.X/bin/node

If the Firewall UI file-picker makes it hard to navigate to an nvm path, use “Go to Folder…” in the picker and paste the which node path.

Quick “make it prompt” trick (if it won’t show in the list)

Start the gateway once in a Terminal (openclaw gateway), then try to connect from the other computer — macOS often pops the “Allow incoming connections?” dialog for node. Click Allow, then you can go back to running it as a service.

If you paste the output of which node, I can tell you exactly which binary you should add to Firewall Options.

civic patrol Mar 12, 2026, 1:38 PM

#

When I try to connect my dashboard and I enter my gateway token, I get the following error: "control ui requires device identity (use HTTPS or localhost secure context)

jaunty otterBOT Mar 12, 2026, 1:40 PM

#

That error is expected when you try to use the Control UI over plain HTTP from another machine (e.g. http://192.168.x.x:18789).

Browsers treat that as a non‑secure context, and WebCrypto is blocked — OpenClaw uses that for device identity, so it refuses with:

“control ui requires device identity (use HTTPS or localhost secure context)”

Docs (this exact section): https://docs.openclaw.ai/web/control-ui#insecure-http

Fix options (best → worst)

1) Use HTTPS via Tailscale Serve (recommended)

On the gateway host:

openclaw gateway --tailscale serve

#

Then open from other computers (that are on your tailnet):

https://<magicdns>/

2) Use an SSH tunnel (no HTTPS required, still “localhost”)

From the other computer:

ssh -N -L 18789:127.0.0.1:18789 <user>@<gateway-lan-ip>

Then open:

http://127.0.0.1:18789/

(Localhost is treated as a secure context by browsers.)

#

3) Break-glass / not recommended

There is a config toggle gateway.controlUi.dangerouslyDisableDeviceAuth: true, but it’s a severe security downgrade (basically “turn off the safety lock”). I wouldn’t do this for a LAN setup unless you’re debugging and you revert immediately.

If you tell me whether you’d rather do Tailscale Serve or SSH tunnel, I’ll give you the exact minimal steps for your situation (macOS gateway + other LAN machines).

civic patrol Mar 12, 2026, 1:42 PM

#

Yeah, lets do Tailscale. I've never done tailscale before

jaunty otterBOT Mar 12, 2026, 1:43 PM

#

Cool — Tailscale is the “make this sane” button for the dashboard.

Here’s the shortest path to HTTPS dashboard on your other computers (no macOS firewall drama, no “secure context” errors):

Docs: https://docs.openclaw.ai/gateway/tailscale

1) Install + log in to Tailscale on both machines

Install Tailscale on the gateway Mac (the one running OpenClaw)
Install Tailscale on the computer you’ll view the dashboard from
Log into the same Tailscale account on both

Quick check on each machine:

tailscale status

#

You should see both machines listed.

2) Switch OpenClaw back to loopback + enable Tailscale Serve

In ~/.openclaw/openclaw.json, set:

{
  gateway: {
    bind: "loopback",
    tailscale: { mode: "serve" },
  },
}

(If you previously set bind: "lan" + controlUi.allowedOrigins, you can remove those LAN bits — Serve doesn’t need them.)

Then restart the gateway:

#

openclaw gateway restart

3) Open the dashboard via HTTPS MagicDNS

On your other computer, open:

https://<magicdns>/

To find the MagicDNS name, tailscale status will show a hostname (often ending in .ts.net).

4) Expect one-time device approval (normal)

Remote Control UI connections require pairing approval. If you see 1008: pairing required, run on the gateway Mac:

openclaw devices list

#

openclaw devices approve <requestId>

Control UI doc: https://docs.openclaw.ai/web/control-ui

If you paste the output of tailscale status (just the hostnames, you can redact IPs if you want), I’ll tell you exactly which https://... URL to open.

civic patrol Mar 12, 2026, 1:49 PM

#

Can you walk me through installing tailscale?

jaunty otterBOT Mar 12, 2026, 1:51 PM

#

Yep. Since your gateway machine is macOS, here’s a clean “first time Tailscale” walkthrough to get to HTTPS dashboard access.

(If you tell me what the other computer OS is — macOS/Windows/Linux — I can tailor that part, but below covers the common cases.)

A) Install Tailscale on the gateway Mac (the machine running OpenClaw)

Create a Tailscale account

Go to https://tailscale.com/
Sign up / log in (Google/GitHub/Apple/etc)

Download + install

Go to https://tailscale.com/download
Download macOS
Install it (drag app / run installer depending on the package)

Open Tailscale and log in

Launch the Tailscale app

#

Click Log in
Approve the macOS prompts (VPN / network extension permission)

Verify it’s connected
Open Terminal on the gateway Mac and run:

tailscale status

You should see your Mac listed (often with a name like your-mac and possibly a .ts.net name).

B) Install Tailscale on the computer you’ll view the dashboard from

If it’s another Mac

Same steps as above (download, install, log in), then:

#

tailscale status

If it’s Windows

https://tailscale.com/download → Windows installer
Install → log in via tray icon
Verify in PowerShell/CMD:

tailscale status

C) Turn on MagicDNS (makes the nice `https://<name>.ts.net` URL work)

Go to the admin console: https://login.tailscale.com/admin
Find DNS settings
Enable MagicDNS

#

After this, tailscale status will usually show a MagicDNS name for each device.

D) Now expose OpenClaw dashboard via Tailscale Serve (HTTPS)

On the gateway Mac:

openclaw gateway --tailscale serve

Then on the other computer, open:

https://<gateway-magicdns>/