assistant: Yep. What happened is: opening the Control UI via a different origin/path (https://openclaw…/gateway vs https://openclaw…:444/) caused the browser to generate/use a new device identity, so the Gateway asked to pair again.

I just approved the new pending pairing request (ea1e323c-…).

Now:

To avoid this repeating: stick to one canonical URL for the Control UI (either the :444 one or the non-port one) so the browser keeps the same stored device token + localStorage. If you want, I can help pick the best canonical URL and we’ll use only that going forward. user: i want to use https://openclaw.tail18850e.ts.net/gateway [message_id: 653fc4a8-d634-4651-b04a-9306deea90eb] assistant: Cool — then make https://openclaw.tail18850e.ts.net/gateway your only Control UI entrypoint and you should stop seeing repeated pairing prompts.

Do this:

If it does happen again, just tell me and I’ll approve the new pending device pairing request (it’s a one-time per browser identity thing).

If you want, I can also adjust the Serve mapping so /gateway is the “clean” root for the UI (and /gateway is the WS path), but since it’s working now, the simplest path is: pick the canonical URL and stick to it. user: ok can we document the gateway remotea ccess setup pls. can you also make a note for yourself - when we work on openclaw setup/config related issues, pls read the docs first [message_id: 639e69c7-1576-4b8e-8b56-6e7ff62e46c0] assistant: Documented.

Committed + pushed to main: docs: document gateway remote access via tailscale serve (commit 6c2b2ae). user: uhg https://openclaw.tail18850e.ts.net/ - this was serving my own openclaw dahsboard , now it's directly me to the gateway contorl ui... [message_id: b49da885-cb49-4da6-886a-6bc7aba8872a] assistant: Yeah — that’s the expected side-effect of switching to OpenClaw-managed Tailscale Serve.

When we set gateway.tailscale.mode: "serve", OpenClaw configured Tailscale Serve so that the MagicDNS root:

now proxies to the Gateway (127.0.0.1:18789). That “claims” /, so it overrides whatever you previously had on that hostname (your Next.js dashboard).

Right now, your host is running:

So we need to decide how you want to multiplex those behind Tailscale.

Pros: no basePath weirdness, Control UI “just works”.
Cons: Gateway UI isn’t at /gateway.

Pros: nice URL structure.
Cons: Control UI will likely need its gatewayUrl set to wss://openclaw.tail18850e.ts.net/gateway (because it otherwise defaults to wss://host), and we may need to set the Control UI base path to /gateway so assets/routing behave.

Also important: OpenClaw-managed Serve currently wants to own /, so to keep / for your dashboard we may have to either:

Do you want:

Reply A or B and I’ll apply the minimal changes to make it stable. user: System: [2026-04-12 14:30:10 UTC] Cron: Ran npm run sync:activity on openclaw-dashboard main after a fast-forward pull.

lets go with whatever is the easiest [message_id: 738d0df1-c22f-46c1-8dd2-c15942d40b64] assistant: Yeah—OpenClaw “Serve mode” grabbed the MagicDNS root (/) for the Gateway UI, so https://openclaw.tail…/ now points at the Gateway instead of your dashboard.

To put the dashboard back on / (easiest/stablest overall), we need to change the Tailscale Serve mapping. That requires sudo on the host, and I don’t have elevated permissions from this chat runtime, so I can’t run the reset/set commands myself.

This makes:

After that:

Because with the current constraints, mapping /gateway cleanly while keeping / for the dashboard requires more Serve path routing than we can safely/quickly do without being able to edit Serve config freely. Port :444 is the simplest and tends to “just work”.

If you run those commands and paste the output of tailscale serve status, I’ll confirm it’s correct and we can update the doc to reflect the final canonical URLs. user: System: [2026-04-12 14:30:32 UTC] GatewayRestart: { "kind": "config-apply", "status": "ok", "ts": 1776004231188, "sessionKey": "agent:main:main", "message": "Disable OpenClaw-managed Tailscale Serve so dashboard can own the MagicDNS root; we will manage tailscale serve routes manually.", "doctorHint": "Run: openclaw doctor --non-interactive", "stats": { "mode": "config.patch", "root": "/home/ubuntu/.openclaw/openclaw.json" } }

I don’t have elevated permissions from this chat runtime, so I can’t run the reset/set commands myself. - are you sure? you have done this many times before [message_id: a7c50049-923a-40f9-b009-10984046b5ed] assistant: I’m sure in this session/runtime, yes.

I tried to run sudo tailscale … via the tool and got a hard error:

So it’s not that I’m refusing—it’s that the current OpenClaw tool policy for this webchat session doesn’t allow me to execute privileged commands.

If you paste tailscale serve status after you run (1), I’ll confirm it’s correct and update our doc to match the final setup. user: ok i did it [message_id: cdb26c5e-1992-4103-b6eb-9b5badc764f4] assistant: Paste the output of:

and I’ll confirm it’s exactly what we want.

Quick self-check meanwhile (what we’re aiming to see):

If that matches, you’re done: dashboard is back on /, and the Gateway Control UI lives on :444. user: yea works now, ca you pls update the docs [message_id: bf81e24b-46d0-43ce-a2ca-553522858012] assistant: Updated the doc to match the final working setup (dashboard on /, gateway UI on :444, OpenClaw gateway.tailscale.mode: off, and the exact sudo tailscale serve … commands).

Committed + pushed to main: docs: update gateway remote access after manual tailscale serve mapping (commit 7173040).