trying to access the dashboard | Friends of the Crustacean 🦞🤝 | Page 1

dusty rune Feb 19, 2026, 1:18 AM

#

I have a basic openclaw setup right now. On a VM using ububtu.

I am trying to get to the dashboard from my PC but I can't get to it. tried local host trickery and also tried the https bit but i can't seem to get it to work. what am i missing? is that even possible?

wary rootBOT Feb 19, 2026, 1:18 AM

#

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

tough charmBOT Feb 19, 2026, 1:21 AM

#

Yes, totally possible — the gotcha is that by default the Control UI (“dashboard”) is only reachable on localhost of the machine running the Gateway (your Ubuntu VM). So when you open http://127.0.0.1:18789/ on your PC, you’re hitting your PC’s localhost, not the VM.

Recommended (works in basically every setup): SSH tunnel

From your PC, run:

ssh -N -L 18789:127.0.0.1:18789 <user>@<vm-ip-or-hostname>

Then on your PC open:

http://127.0.0.1:18789/

If the UI asks for auth, get the token on the VM:

#

openclaw config get gateway.auth.token

…and paste it into the Control UI settings auth field.

Docs: https://docs.openclaw.ai/gateway/remote and https://docs.openclaw.ai/web/dashboard

Alternative (LAN access, less safe): bind to LAN

If you really want to hit the VM directly from your PC (no tunnel), you must bind the gateway to LAN and have a token set:

{
  gateway: {
    bind: "lan",
    auth: { mode: "token", token: "replace-me" }

#

}
}

Then you’d open:

http://<vm-lan-ip>:18789/

Be careful: this is an admin UI (chat + config + approvals), so don’t expose it broadly.

Docs: https://docs.openclaw.ai/help/faq#i-set-gatewaybind-lan-or-tailnet-and-now-nothing-listens-the-ui-says-unauthorized

About the “https bit”

The gateway does not serve HTTPS on that port by default. HTTPS is usually via Tailscale Serve or a reverse proxy in front.

If you paste:

#

openclaw --version
openclaw gateway status

…and tell me whether your VM networking is NAT or bridged, I can tell you which of the above is the cleanest for your setup.

dusty rune Feb 19, 2026, 1:25 AM

#

what goes here? <user>@<vm-ip-or-hostname>

#

also I have it bridges and also natted

tough charmBOT Feb 19, 2026, 1:27 AM

#

If you have both bridged + NAT enabled, you basically have two different ways the VM can be reachable — and they behave very differently:

What “bridged + NAT” means for dashboard access

NAT adapter

Your VM is behind a virtual router.
From your PC you cannot reach 18789 on the VM unless you set up port forwarding in the VM software.
So “localhost trickery” won’t work unless you tunnel/forward.

Bridged adapter

Your VM gets a real LAN IP (same network as your PC).
In theory you can reach http://<vm-ip>:18789/ but only if the Gateway is bound to LAN (not loopback) and firewall allows it.

Best option (works regardless of NAT/bridged, and avoids HTTPS headaches): SSH tunnel

On your PC:

#

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

Then open on your PC:

http://127.0.0.1:18789/

This is also nice because the Control UI is running on localhost (which avoids “secure context” issues that can happen when you hit a raw LAN IP over plain HTTP).

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

If you want to access it directly via bridged IP (less recommended)

On the VM, check what it’s actually bound to:

#

openclaw config get gateway.bind
openclaw config get gateway.port
openclaw gateway status

If gateway.bind is loopback, your PC will never reach it directly. You’d need to switch to lan and ensure you have a token configured (non-loopback binds require auth):

Docs: https://docs.openclaw.ai/help/faq#i-set-gatewaybind-lan-or-tailnet-and-now-nothing-listens-the-ui-says-unauthorized

Quick question so I can pinpoint it

When you run this on the VM:

openclaw gateway status

#

Can you paste the output? (It prints the probe/URL it thinks it’s serving on, which usually makes the problem obvious.)

dusty rune Feb 19, 2026, 1:28 AM

#

🦞 OpenClaw 2026.2.17 (4134875) — It's not "failing," it's "discovering new ways to configure the same thing wrong."

│
◇
Service: systemd (enabled)
File logs: /tmp/openclaw/openclaw-2026-02-19.log
Command: /usr/bin/node /home/openclaw/.npm-global/lib/node_modules/openclaw/dist/index.js gateway --port 18789
Service file: ~/.config/systemd/user/openclaw-gateway.service
Service env: OPENCLAW_GATEWAY_PORT=18789

Config (cli): ~/.openclaw/openclaw.json
Config (service): ~/.openclaw/openclaw.json

Gateway: bind=lan (0.0.0.0), port=18789 (service args)
Probe target: ws://192.168.112.128:18789
Dashboard: http://192.168.112.128:18789/
Probe note: bind=lan listens on 0.0.0.0 (all interfaces); probing via 192.168.112.128.

Runtime: running (pid 1273, state active, sub running, last exit 0, reason 0)
RPC probe: ok

Listening: *:18789
Troubles: run openclaw status
Troubleshooting: https://docs.openclaw.ai/troubleshooting
openclaw@openclaw01:~$

tough charmBOT Feb 19, 2026, 1:30 AM

#

Your openclaw gateway status looks perfect: the Gateway is running, listening on *:18789, and it thinks the dashboard is at:

http://192.168.112.128:18789/

So the issue isn’t “OpenClaw isn’t up” — it’s almost certainly how you’re accessing it from another machine.

The big gotcha: remote over plain HTTP is blocked by default

If you open the dashboard from your PC via http://<vm-ip>:18789/, that’s a non-secure browser context (not HTTPS, not localhost). Modern browsers block WebCrypto there, and OpenClaw blocks Control UI connections by default in that mode (you’ll usually see it load but fail to connect/auth).

Docs: https://docs.openclaw.ai/web/control-ui (see “Insecure HTTP”)

Fix options (pick one)

Option A (recommended): SSH tunnel → open on localhost

From your PC:

#

ssh -N -L 18789:127.0.0.1:18789 <user>@192.168.112.128

Then open on your PC:

http://127.0.0.1:18789/

This is “secure context” (localhost) so the UI works normally.

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

Option B (recommended): HTTPS via Tailscale Serve

This gives you a proper https://... URL (secure context) without exposing the port publicly.

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

#

Option C (workaround): allow insecure HTTP (downgrades security)

If you really want http://<vm-ip>:18789/ from your PC, set:

{
  gateway: {
    controlUi: { allowInsecureAuth: true }
  }
}

(Keep token auth enabled.) Then restart the gateway.

Docs snippet is in the same “Insecure HTTP” section: https://docs.openclaw.ai/web/control-ui

Quick check

When you hit http://192.168.112.128:18789/ from your PC, does the page load but then show a “can’t connect/unauthorized” style error — or does it not load at all (timeout)? That tells us instantly whether it’s the secure-context block vs networking/firewall.

dusty rune Feb 19, 2026, 1:31 AM

#

says this:
disconnected (1008): control ui requires HTTPS or localhost (secure context)

Main Session

|

Disconnected from gateway.
disconnected (1008): control ui requires HTTPS or localhost (secure context)

tough charmBOT Feb 19, 2026, 1:32 AM

#

That error is exactly the “insecure HTTP” guardrail.

You opened it as http://192.168.112.128:18789/ from your PC, which is not a secure context, so the Control UI intentionally drops the WS connection with code 1008.

Fix 1 (best / fastest): SSH tunnel, then use localhost

On your PC:

ssh -N -L 18789:127.0.0.1:18789 <user>@192.168.112.128

Then open:

http://127.0.0.1:18789/

(If it asks for auth, grab token on the VM: openclaw config get gateway.auth.token.)

#

Fix 2 (nice UX): Tailscale Serve (HTTPS)

This gives you https://<magicdns>/ which satisfies the secure-context requirement.
Docs: https://docs.openclaw.ai/gateway/tailscale

Fix 3 (not recommended, but works): allow insecure auth over HTTP

Add this to ~/.openclaw/openclaw.json on the VM:

{
  gateway: {
    controlUi: { allowInsecureAuth: true }
  }
}

Then restart:

#

openclaw gateway restart

This disables device identity + pairing protections for the Control UI, so only do it if you trust your LAN.

Docs: https://docs.openclaw.ai/web/control-ui (section “Insecure HTTP”)

If you tell me what you prefer (SSH tunnel vs Tailscale), I’ll give you the exact minimal steps for that path.

dusty rune Feb 19, 2026, 1:33 AM

#

if it is on an internal VM how much of a risk is option 3

tough charmBOT Feb 19, 2026, 1:34 AM

#

Option 3 is basically: “let me use the admin UI over plain HTTP anyway.”

That’s fine for quick testing, but it does remove an important safety layer. The practical risk depends on what “internal VM” means in your setup:

What risk it adds

With gateway.controlUi.allowInsecureAuth: true:

The Control UI will accept token-only auth over HTTP.
That means the token travels over the network in plaintext (WebSocket handshake), and the UI itself is also served over HTTP (so it’s susceptible to MITM / traffic tampering on that network).
Anyone who can sniff or intercept traffic on that network could potentially steal the token and get full admin access (chat + config + approvals, etc).

Without that setting, OpenClaw blocks you specifically to avoid this (“HTTPS or localhost”).

When it’s low-ish risk

The VM is only reachable from your host machine (host-only / isolated virtual network), and
You trust everything on that host, and
You’re not on shared Wi‑Fi / untrusted LAN segments.

#

When it’s a bad idea

Your VM is bridged onto your home/office LAN (which yours is), because now any device on that LAN can at least reach the port.
Any shared network (roommates, office, coffee shop Wi‑Fi, corp LAN) where sniffing/mitm is a realistic threat.

My recommendation

Use SSH tunneling (option 1) for LAN/VM setups. It’s almost zero config, and you keep the “localhost secure context” behavior.

If you tell me what OS your PC is on (Windows/macOS/Linux), I’ll paste the exact tunnel command in the right format (PowerShell vs Terminal).

dusty rune Feb 19, 2026, 1:37 AM

#

k - i did fix 1
PS C:\Users\Bobe> ssh -N -L 18789:127.0.0.1:18789 openclaw@192.168.112.128
The authenticity of host '192.168.112.128 (192.168.112.128)' can't be established.
ED25519 key fingerprint is SHA256:MDLJv4d1FXAF1Lblxo7+iOGSmTr4vCfryk5MrrLw0jk.
This host key is known by the following other names/addresses:
C:\Users\Bobe/.ssh/known_hosts:1: 192.168.121.130
C:\Users\Bobe/.ssh/known_hosts:4: 192.168.1.84
Are you sure you want to continue connecting (yes/no/[fingerprint])? yes
Warning: Permanently added '192.168.112.128' (ED25519) to the list of known hosts.
openclaw@192.168.112.128's password:

#

from the browser: interventions.
disconnected (1008): unauthorized: device token mismatch (rotate/reissue device token)

Main Session

|

Disconnected from gateway.
disconnected (1008): unauthorized: device token mismatch (rotate/reissue device token)

tough charmBOT Feb 19, 2026, 1:40 AM

#

That one means your browser is presenting a stale/incorrect device identity token for a device the Gateway already knows about (so it rejects with 1008).

Easiest fix (usually): reset the browser’s saved device identity

On your PC, for the dashboard origin you’re using (e.g. http://192.168.112.128:18789):

Open DevTools → Application → Storage
Clear site data (localStorage / indexedDB for that site)
Reload the dashboard

Or just try an Incognito/Private window (fresh storage).

After that you’ll either:

connect cleanly, or
get “pairing required” (also normal for remote access)

If you see “pairing required”: approve the new device on the VM

Run on the VM:

#

openclaw devices list
openclaw devices approve <requestId>

Docs: https://docs.openclaw.ai/web/control-ui and https://docs.openclaw.ai/cli/devices

Alternative (also good): use an SSH tunnel so it counts as “localhost”

If you access via an SSH tunnel and open http://127.0.0.1:18789/ on your PC, the Gateway sees it as a local connection and it’s typically auto-approved, which avoids most device-pairing weirdness.

If you paste the output of openclaw devices list (redact tokens if any show), I can tell you exactly which device entry to revoke/rotate.

dusty rune Feb 19, 2026, 1:41 AM

#

Paired (1)
┌────────────────────────────────────────────────────────────────────┬──────────────┬────────────────────────────────────────────────────────┬─────────────┬─────────────────┐
│ Device │ Roles │ Scopes │ Tokens │ IP │
├────────────────────────────────────────────────────────────────────┼──────────────┼────────────────────────────────────────────────────────┼─────────────┼─────────────────┤
│ 717b3a3d3382517d7b374c52da8744647d21a4c84dd5771ad07739cf9c9de13d │ operator │ operator.admin, operator.approvals, operator.pairing │ operator │ 192.168.112.128 │
└────────────────────────────────────────────────────────────────────┴──────────────┴────────────────────────────────────────────────────────┴─────────────┴─────────────────┘
-bash: syntax error near unexpected token `newline'
openclaw@openclaw01:~$

#

^

tough charmBOT Feb 19, 2026, 1:45 AM

#

That device token mismatch error is the Control UI’s device identity getting out of sync (usually because the browser has an old stored device token, or you changed auth/bind settings and the server-side device record no longer matches).

Do this in order:

1) Clear the browser’s stored device token (fastest)

On your PC, for http://192.168.112.128:18789:

DevTools → Application → Storage → Clear site data
(or just try an Incognito/Private window)

Reload the page.

2) If it then says “pairing required”, approve it on the VM

On the VM:

#

openclaw devices list
openclaw devices approve <requestId>

Docs: https://docs.openclaw.ai/web/control-ui

3) If it still says “device token mismatch”, revoke the old device entry

On the VM:

openclaw devices list

Find the device that corresponds to that browser, then:

#

openclaw devices revoke --device <deviceId> --role operator

Reload the browser; it should generate a fresh pairing request you can approve.

Docs: https://docs.openclaw.ai/cli/devices

If you paste the output of openclaw devices list (no tokens should appear, but redact anything secret if it does), I’ll tell you exactly which one to revoke/approve.

dusty rune Feb 19, 2026, 1:45 AM

#

how do i get to dev tools - my machine is a pc

tough charmBOT Feb 19, 2026, 1:46 AM

#

On a PC you’ll use your browser’s built-in Developer Tools. Here are the quick ways:

Chrome / Edge (Windows)

Press F12, or
Press Ctrl + Shift + I, or
Right‑click the page → Inspect

Firefox (Windows)

Press F12, or
Press Ctrl + Shift + I, or
Right‑click → Inspect

Then clear the site data (to fix the device token mismatch)

Open DevTools
Go to the Application tab (Chrome/Edge)
- If you don’t see it: click the » overflow menu to find Application
Left sidebar: Storage

#

Click Clear site data (or clear Local Storage for http://192.168.112.128:18789)

Reload the dashboard page after clearing.

If you tell me which browser you’re using (Chrome, Edge, Firefox), I can give the exact clicks for that one.

dusty rune Feb 19, 2026, 1:49 AM

#

im using brave

tough charmBOT Feb 19, 2026, 1:50 AM

#

Brave is Chromium-based, so it’s the same as Chrome.

Open DevTools in Brave (Windows)

Press F12, or
Press Ctrl + Shift + I, or
Right‑click the page → Inspect

Clear the saved device token / site data (fixes the mismatch)

Open DevTools
Click the » (double-arrow) at the top if needed → choose Application
In the left sidebar, open Storage
Click Clear site data
Reload the page (Ctrl+R)

If you can’t find “Application”

Use Brave’s menu instead:

Menu (≡) → More tools → Developer tools

#

After you clear site data and reload, you’ll typically either connect or get “pairing required” — if you see pairing required, run on the VM:

openclaw devices list
openclaw devices approve <requestId>

dusty rune Feb 19, 2026, 1:52 AM

#

│ 717b3a3d3382517d7b374c52da8744647d21a4c84dd5771ad07739cf9c9de13d │ operator │ operator.admin, operator.approvals, operator.pairing │ operator │ 192.168.112.128 │

tough charmBOT Feb 19, 2026, 1:52 AM

#

That line looks like a paired operator device entry (device id starts with 717b3a...). If your browser is now saying:

unauthorized: device token mismatch (rotate/reissue device token)

…then the quickest way to fix it is to revoke that device, clear the browser storage, and let it re-pair.

On the VM, run:

openclaw devices revoke --device 717b3a3d3382517d7b374c52da8744647d21a4c84dd5771ad07739cf9c9de13d --role operator

Then on your PC (Brave) for the dashboard site:

clear site data again (DevTools → Application → Storage → Clear site data)
reload the dashboard page

If after reload you get “pairing required”, do:

#

openclaw devices list
openclaw devices approve <requestId>

One note: if you’re accessing via http://192.168.112.128:18789/ (LAN HTTP), you’ll still hit the “HTTPS or localhost (secure context)” rule unless you’re using SSH tunnel / HTTPS / or you enabled gateway.controlUi.allowInsecureAuth. The “clean” path is still SSH tunnel → open http://127.0.0.1:18789/ on your PC.

dusty rune Feb 19, 2026, 1:55 AM

#

i am trying that but it is still now working

#

not*

tough charmBOT Feb 19, 2026, 1:56 AM

#

“Still not working” can mean a couple different things here — the next step depends on the exact message you see in the browser now.

1) First: what URL are you opening?

If you are opening http://192.168.112.128:18789/ from your PC → you will keep getting secure-context / device-auth weirdness unless you explicitly allow insecure auth.
If you use an SSH tunnel, you must open http://127.0.0.1:18789/ on your PC (that’s the whole point: it becomes “localhost” on your PC).

2) If you’re trying the SSH tunnel, use this exact flow

On your PC (PowerShell is fine), run and leave it running:

ssh -N -L 18789:127.0.0.1:18789 openclaw@192.168.112.128

Then in Brave on your PC, open:

http://127.0.0.1:18789/

#

If that page doesn’t load at all, the tunnel isn’t up (usually SSH can’t connect).

3) If the page loads but disconnects: paste the new disconnect reason

Common ones:

“pairing required” → on the VM run:

openclaw devices list
openclaw devices approve <requestId>

“device token mismatch” → you need to clear the site data for the exact origin you’re using (so if you switched from 192.168… to 127.0.0.1, clear both), then reload. If it still persists, revoke the device and re-pair.

4) Quick question so I can land this:

When you open the dashboard right now, are you opening http://127.0.0.1:18789/ or http://192.168.112.128:18789/ — and what is the full disconnect (1008) message you see?

#

“not” as in you’re not opening http://127.0.0.1:18789/ on your PC (through an SSH tunnel)?

Because if you’re still opening http://192.168.112.128:18789/, you’ll keep hitting the secure-context/device-auth issues.

If you want the SSH-tunnel path (recommended)

On your PC, run this and leave it running (it won’t print anything when it’s working):

ssh -N -L 18789:127.0.0.1:18789 openclaw@192.168.112.128

Then on your PC open (this part matters):

http://127.0.0.1:18789/

If that still fails, paste the exact error from the PC terminal (e.g. “connection refused”, “permission denied”, etc.). Also confirm you can run:

#

ssh openclaw@192.168.112.128

If you don’t want SSH tunnels

Then you must do either:

HTTPS (Tailscale Serve), or
set gateway.controlUi.allowInsecureAuth: true and restart (works over http://192.168…, but is a security downgrade).

Quick thing to paste so I can pinpoint it

Which URL are you opening in Brave right now? (127.0.0.1 vs 192.168.112.128)
What is the full disconnected (1008): ... message you see now?

dusty rune Feb 19, 2026, 1:57 AM

#

disconnected (1008): unauthorized: device token mismatch (rotate/reissue device token)

#

disconnected (1008): unauthorized: device token mismatch (rotate/reissue device token)

tough charmBOT Feb 19, 2026, 1:59 AM

#

That message means: the Gateway recognizes your browser’s device ID, but the browser is sending a different (old) device token than what the Gateway has on record for that device.

In practice, it almost always means you need to re-pair the browser (server-side revoke + client-side clear).

Step A (on the VM): revoke the paired operator device(s)

Run:

openclaw devices list

For every row with role operator, revoke it (you can start with the one you pasted earlier):

openclaw devices revoke --device 717b3a3d3382517d7b374c52da8744647d21a4c84dd5771ad07739cf9c9de13d --role operator

#

Then run openclaw devices list again to confirm it’s gone.

Step B (on your PC / Brave): actually clear the site data for the right origin

Make sure you clear data for the exact URL you’re using:

if you browse http://192.168.112.128:18789 → clear data for that
if you browse http://127.0.0.1:18789 (SSH tunnel) → clear data for that too

Fastest way (avoids missing some storage): open a new Brave profile:

Brave menu → Create new profile
Open the dashboard in that fresh profile

Step C: reconnect → you should get “pairing required”

If you now see pairing required, approve it on the VM:

#

openclaw devices list
openclaw devices approve <requestId>

If it still says “device token mismatch” after Step A, paste the full output of openclaw devices list (all lines). That will show whether there’s another operator device entry still present that needs revoking.

dusty rune Feb 19, 2026, 2:01 AM

#

it is not revoking the device - it is still there

#

it is not revoking the device - it is still there

#

not gone

#

openclaw@openclaw01:~$ openclaw devices revoke --device 717b3a3d3382517d7b374c52da8744647d21a4c84dd5771ad07739cf9c9de13d --role operator

🦞 OpenClaw 2026.2.17 (4134875) — curl for conversations.

│
◇
{
"deviceId": "717b3a3d3382517d7b374c52da8744647d21a4c84dd5771ad07739cf9c9de13d",
"role": "operator",
"revokedAtMs": 1771466866511
}
openclaw@openclaw01:~$ openclaw devices list

🦞 OpenClaw 2026.2.17 (4134875) — IPC, but it's your phone.

│
◇
Paired (1)
┌────────────────────────────────────────────────────────────────────┬──────────────┬────────────────────────────────────────────────────────┬─────────────┬─────────────────┐
│ Device │ Roles │ Scopes │ Tokens │ IP │
├────────────────────────────────────────────────────────────────────┼──────────────┼────────────────────────────────────────────────────────┼─────────────┼─────────────────┤
│ 717b3a3d3382517d7b374c52da8744647d21a4c84dd5771ad07739cf9c9de13d │ operator │ operator.admin, operator.approvals, operator.pairing │ operator │ 192.168.112.128 │
└────────────────────────────────────────────────────────────────────┴──────────────┴────────────────────────────────────────────────────────┴─────────────┴─────────────────┘
openclaw@openclaw01:~$

tough charmBOT Feb 19, 2026, 2:08 AM

#

If the device row is still showing Tokens: operator (not operator (revoked)), then either:

the revoke command didn’t actually succeed, or
you revoked a different device/role than the one you’re looking at.

The good news: openclaw devices revoke always prints a JSON result. Can you run this on the VM and paste the exact output?

openclaw devices revoke --device 717b3a3d3382517d7b374c52da8744647d21a4c84dd5771ad07739cf9c9de13d --role operator
openclaw devices list

What we should see:

The revoke command should print something like:

#

  { "ok": true, "result": { "deviceId": "...", "role": "operator", "revokedAtMs": 123 } }

And then openclaw devices list should show Tokens as:
- operator (revoked) (that’s the “it worked” indicator)

If you get { "ok": false, "error": ... } from revoke, paste that too — it’ll tell us exactly why it isn’t changing.

Also double-check: are you running these commands as the same Linux user that runs the gateway service? (From your prompt it looks like openclaw@..., which is correct — just confirming.)

dusty rune Feb 19, 2026, 2:09 AM

#

openclaw@openclaw01:~$ openclaw devices revoke --device 717b3a3d3382517d7b374c52da8744647d21a4c84dd5771ad07739cf9c9de13d --role operator

🦞 OpenClaw 2026.2.17 (4134875) — curl for conversations.

│
◇
{
"deviceId": "717b3a3d3382517d7b374c52da8744647d21a4c84dd5771ad07739cf9c9de13d",
"role": "operator",
"revokedAtMs": 1771466866511
}
openclaw@openclaw01:~$ openclaw devices list

🦞 OpenClaw 2026.2.17 (4134875) — IPC, but it's your phone.

│
◇
Paired (1)
┌────────────────────────────────────────────────────────────────────┬──────────────┬────────────────────────────────────────────────────────┬─────────────┬─────────────────┐
│ Device │ Roles │ Scopes │ Tokens │ IP │
├────────────────────────────────────────────────────────────────────┼──────────────┼────────────────────────────────────────────────────────┼─────────────┼─────────────────┤
│ 717b3a3d3382517d7b374c52da8744647d21a4c84dd5771ad07739cf9c9de13d │ operator │ operator.admin, operator.approvals, operator.pairing │ operator │ 192.168.112.128 │
└────────────────────────────────────────────────────────────────────┴──────────────┴────────────────────────────────────────────────────────┴─────────────┴─────────────────┘
openclaw@openclaw01:~$

tough charmBOT Feb 19, 2026, 2:10 AM

#

Yep — that device will still show up in openclaw devices list even after revoking. Revoke doesn’t delete the device entry, it only revokes the token for that role.

What you should see change is the Tokens column:

before: operator
after revoke: operator (revoked)

1) Run revoke and paste the command output

On the VM, run:

openclaw devices revoke --device 717b3a3d3382517d7b374c52da8744647d21a4c84dd5771ad07739cf9c9de13d --role operator

That command prints JSON. Paste what it prints (this will tell us if it actually succeeded or if it’s failing with unknown deviceId/role / unauthorized / etc).

2) Re-list to confirm it’s revoked

#

openclaw devices list

If it still shows operator (not operator (revoked)), then revoke didn’t take.

3) After it’s revoked: fix the browser side

In Brave, use a fresh Brave profile (best) or clear site data, then reload. You should then get either “pairing required” (approve it) or it should connect.

If you paste the revoke JSON output, I can tell you exactly what’s blocking it.

#

“Not gone” is expected — revoke does not remove the device row. It only marks the operator token as revoked.

What should change is the Tokens column:

before: operator
after revoke: operator (revoked)

1) Let’s verify whether the revoke command is actually succeeding

On the VM, run this exact command and paste what it prints:

openclaw devices revoke --device 717b3a3d3382517d7b374c52da8744647d21a4c84dd5771ad07739cf9c9de13d --role operator

It will print JSON with either ok: true or an error (that error is what we need).

Then run:

#

openclaw devices list

…and check whether it now says operator (revoked).

2) Easiest way to stop fighting device tokens: use an SSH tunnel

This avoids the whole remote device-token pairing path.

On your PC:

ssh -N -L 18789:127.0.0.1:18789 openclaw@192.168.112.128

Then open in Brave on your PC:

#

http://127.0.0.1:18789/

This should not hit “device token mismatch”.

Paste the JSON output from the revoke command and we’ll know immediately why it’s not flipping to “(revoked)”.

dusty rune Feb 19, 2026, 2:14 AM

#

it is not revoking - that is where we are stuck.

tough charmBOT Feb 19, 2026, 2:14 AM

#

Your revoke did work — the JSON confirms it:

{ "deviceId": "...", "role": "operator", "revokedAtMs": ... }

Two important gotchas:

1) The device entry will NOT disappear

openclaw devices revoke doesn’t remove the device from the list. It only revokes the token for that role. So seeing the device still listed is normal.

To see the real state, run this (on the VM):

openclaw devices list --json

#

and look for the paired[].tokens[] entry — it should include revokedAtMs for the operator token.

2) The browser still has an old token cached → that’s why you keep getting “device token mismatch”

Even after revoking on the server, Brave will keep trying with whatever it has saved for that site.

The clean fix (recommended): use an SSH tunnel so the UI is “localhost”

On your PC:

ssh -N -L 18789:127.0.0.1:18789 openclaw@192.168.112.128

Then open in Brave:

http://127.0.0.1:18789/ (not the 192.168… URL)

This uses a different origin, so Brave won’t reuse the old device token, and it avoids the whole “secure context” pain.

#

If you insist on opening `http://192.168.112.128:18789/`

Then you must clear site data for that exact origin (or use a brand new Brave profile) after you revoke/rotate — otherwise you’ll keep sending the stale token.

If you paste the output of:

openclaw devices list --json

I can point to the exact revokedAtMs field so we know whether the gateway side is clean, and then we’ll focus purely on the browser side.

dusty rune Feb 19, 2026, 2:15 AM

#

openclaw@openclaw01:~$ openclaw devices list --json
{
"pending": [],
"paired": [
{
"deviceId": "717b3a3d3382517d7b374c52da8744647d21a4c84dd5771ad07739cf9c9de13d",
"publicKey": "wGCbGaG9oOLvqAGcLd5wRqhJNfwroF_-uG6D1cx-y50",
"platform": "linux",
"clientId": "cli",
"clientMode": "cli",
"role": "operator",
"roles": [
"operator"
],
"scopes": [
"operator.admin",
"operator.approvals",
"operator.pairing"
],
"createdAtMs": 1771366414793,
"approvedAtMs": 1771366414793,
"remoteIp": "192.168.112.128",
"tokens": [
{
"role": "operator",
"scopes": [
"operator.admin",
"operator.approvals",
"operator.pairing"
],
"createdAtMs": 1771366414793,
"rotatedAtMs": 1771467195355
}
]
}
]
}

#

get to look at this output?

tough charmBOT Feb 19, 2026, 2:20 AM

#

It is revoking — the JSON you pasted proves it.

What’s confusing you is this:

devices revoke does not delete the device row. It only revokes/rotates the token for that device+role.
And as soon as the browser tries to connect again, the Gateway can auto re-issue a fresh token for that same device entry (so the list goes back to showing just operator). So it can look like “revoke didn’t stick”, even though it did.

What you’re actually stuck on

Brave still has a stale saved token for that device → the Gateway has already moved on to a new one → you get:

device token mismatch

Fix (do this exact sequence)

In Brave, create a new profile (best)
Brave menu → Create new profile
(or clear site data for the dashboard origin)

#

On the VM, get your Gateway token (don’t paste it into Discord):

openclaw config get gateway.auth.token

Open the dashboard in the fresh Brave profile and paste that token into the Control UI Settings auth field, then connect.
If it then says pairing required, approve it on the VM:

openclaw devices list
openclaw devices approve <requestId>

Even simpler (recommended): SSH tunnel

This avoids most of the device-auth pain:

#

ssh -N -L 18789:127.0.0.1:18789 openclaw@192.168.112.128

Then open on your PC:

http://127.0.0.1:18789/

If you tell me which URL you’re opening right now (192.168... vs 127.0.0.1), I’ll point you to the exact “clear site data” entry to wipe.

#

It is revoking — but you’re revoking the CLI device, not the browser, and the device row is not supposed to disappear.

What your `devices list --json` is telling us

This entry:

clientId: "cli"
platform: "linux"
clientMode: "cli"

…is the OpenClaw CLI itself (created when you run openclaw devices … commands). It’s not Brave.

Also, notice:

Your revoke printed revokedAtMs: … (so revoke succeeded)
but your later devices list --json shows only rotatedAtMs and no revokedAtMs

That means a new token got re-issued/rotated after you revoked (so the list no longer shows “revoked”). That can happen just by making another authorized connection.

#

The “device token mismatch” you see in Brave is a browser-side cache problem

Brave is still sending an old stored device token for the dashboard origin you’re visiting.

The fix is not “keep revoking”, it’s:

Option A (recommended): SSH tunnel so the UI is localhost

On your PC:

ssh -N -L 18789:127.0.0.1:18789 openclaw@192.168.112.128

Then in Brave open:

http://127.0.0.1:18789/

This uses a different origin (localhost), so the stale device token problem goes away.

#

Option B: wipe Brave’s storage for the exact URL you’re using

If you’re opening http://192.168.112.128:18789/, you must clear site data for that exact origin (not for 127.0.0.1), or use a brand new Brave profile.

One question to unblock this fast

Which URL are you opening in Brave right now?

http://192.168.112.128:18789/
or
http://127.0.0.1:18789/ (through an SSH tunnel)

If you answer that, I can give the exact next click/command with no guessing.

dusty rune Feb 19, 2026, 2:23 AM

#

i tried accessing this on edge: http://127.0.0.1:18789/
and it fails

tough charmBOT Feb 19, 2026, 2:24 AM

#

http://127.0.0.1:18789/ only works if the Gateway is running on your PC.

Right now your Gateway is running on the Ubuntu VM, so 127.0.0.1 on the PC points to the PC itself → it will fail unless you create a tunnel.

Fix: make 127.0.0.1 on your PC forward to the VM (SSH tunnel)

On your PC, open PowerShell and run (leave this window open):

ssh -N -L 18789:127.0.0.1:18789 openclaw@192.168.112.128

Then open in Edge:

http://127.0.0.1:18789/

If that still fails, the usual cause is: local port already in use

Try a different local port:

#

ssh -N -L 18790:127.0.0.1:18789 openclaw@192.168.112.128

Then open:

http://127.0.0.1:18790/

Quick check

When you open http://127.0.0.1:18789/ in Edge, what exact error do you get? (e.g. ERR_CONNECTION_REFUSED vs a page that loads and then shows a disconnect message)

dusty rune Feb 19, 2026, 2:27 AM

#

back to disconnected (1008): unauthorized: gateway token missing (open the dashboard URL and paste the token in Control UI settings)

tough charmBOT Feb 19, 2026, 2:28 AM

#

Good — that means the tunnel/network part is now fine. You’re just missing the Gateway token in the Control UI.

1) Get the token on the VM

Run this on the Ubuntu VM:

openclaw config get gateway.auth.token

(Do not paste the token into Discord.)

2) Paste it into the Control UI on your PC

In Edge/Brave Control UI:

Click Settings (gear icon) in the Control UI
Find the Gateway Token field
Paste the token

#

Click Connect / Save (wording varies a bit)

After that, the disconnect should go away.

If you don’t see the token field: it’s in the Control UI under something like Control → Overview → Gateway Access (there are usually two auth inputs side-by-side: Token and Password).

dusty rune Feb 19, 2026, 2:30 AM

#

i cant find the control ui - where is that?

tough charmBOT Feb 19, 2026, 2:31 AM

#

The page you’re looking at is the Control UI — it’s the “dashboard”.

You just need to open the Settings panel inside it to paste the token.

In the dashboard page (http://127.0.0.1:18789/)

Look for:

a gear icon (Settings), usually in the top bar, or
a left sidebar item called Settings

In there you’ll see auth inputs, typically:

Gateway Token
(sometimes also) Password

Paste the token from:

#

openclaw config get gateway.auth.token

If you still can’t find it

Do this on the VM (it prints the correct dashboard URL and helps you find auth):

openclaw dashboard --no-open

Also: what do you see on the page exactly — is it a blank page, a simple “Disconnected from gateway” screen, or a full UI with tabs? If you can screenshot it, I can point to the exact button.

dusty rune Feb 19, 2026, 2:36 AM

#

i cant get to the dashboard - how can i do that?

tough charmBOT Feb 19, 2026, 2:37 AM

#

To get to the dashboard from your PC you need two things:

a way for your PC to reach the VM’s Gateway port
the gateway token entered in the Control UI

Step 1: open the dashboard via an SSH tunnel (recommended)

On your PC (PowerShell), run and keep it running:

ssh -N -L 18789:127.0.0.1:18789 openclaw@192.168.112.128

Then open in your PC browser:

http://127.0.0.1:18789/

Step 2: easiest way to avoid hunting for the token field

#

On the VM, run:

openclaw dashboard --no-open

It will print a dashboard URL that includes the auth (usually as a #token=... fragment). Copy that printed URL and open it on your PC through the tunnel (so it starts with http://127.0.0.1:18789/...).

If you still see `gateway token missing`

Then you need to paste the token into the UI:

On the VM:

openclaw config get gateway.auth.token

#

Then in the dashboard UI, open Settings (gear icon) and paste it into Gateway Token.

When you say “I can’t get to the dashboard”, which one is happening on your PC?

Page won’t load at all (ERR_CONNECTION_REFUSED / timeout)
or
Page loads but says “Disconnected (1008) …”

dusty rune Feb 19, 2026, 2:38 AM

#

the tunnel does not work

tough charmBOT Feb 19, 2026, 2:39 AM

#

The tunnel failing usually means SSH to the VM isn’t working (or you’re not actually keeping the tunnel running).

1) First check: can you SSH into the VM at all?

On your PC, run:

ssh openclaw@192.168.112.128

If that fails (timeout / connection refused), the tunnel can’t work yet.
Paste the exact error text you get.

Quick port test (Windows):

Test-NetConnection 192.168.112.128 -Port 22

#

If port 22 is closed, on the VM you likely need to install/start SSH:

sudo apt update
sudo apt install openssh-server
sudo systemctl enable --now ssh

2) If SSH works, start the tunnel (and keep the window open)

Run this in PowerShell and leave it running (it should look like it “hangs” with no output — that’s normal):

ssh -N -L 18789:127.0.0.1:18789 openclaw@192.168.112.128

Then open in the browser:

#

http://127.0.0.1:18789/

If it immediately exits back to the prompt, paste whatever it printed.

3) Common Windows gotcha: local port already in use

Try a different local port:

ssh -N -L 18790:127.0.0.1:18789 openclaw@192.168.112.128

Open:

http://127.0.0.1:18790/

Tell me this (so I can pinpoint it)

When you run the SSH tunnel command, what exact error do you see in PowerShell? (Copy/paste the line.)

dusty rune Feb 19, 2026, 2:40 AM

#

Last login: Thu Feb 19 01:24:37 2026 from 192.168.1.31
openclaw@openclaw01:~$ ssh -N -L 18789:127.0.0.1:18789 openclaw@192.168.112.128
openclaw@192.168.112.128's password:
bind [127.0.0.1]:18789: Address already in use
channel_setup_fwd_listener_tcpip: cannot listen to port: 18789
Could not request local forwarding.

tough charmBOT Feb 19, 2026, 2:41 AM

#

Perfect — SSH works. The tunnel failed because port 18789 is already in use on the machine where you ran the tunnel command.

And from your output, you ran the tunnel on the VM itself (openclaw@openclaw01:~$), not on your PC. That’s why it’s colliding: the gateway is already listening on 18789 on the VM.

Do this instead

Option A (recommended): run the tunnel on your PC

On your PC (PowerShell):

ssh -N -L 18789:127.0.0.1:18789 openclaw@192.168.112.128

Then open on your PC:

http://127.0.0.1:18789/

#

Option B: if you want to test the tunnel from the VM anyway, use a different local port

On the VM:

ssh -N -L 18790:127.0.0.1:18789 openclaw@192.168.112.128

Then you’d open (on that same machine):

http://127.0.0.1:18790/

…but this doesn’t help your PC unless you do the tunnel on the PC.

Quick check

Can you run SSH from your PC? (Windows has it built in now.) If not, tell me your PC OS/version and we’ll pick the easiest way (PowerShell SSH vs PuTTY).

dusty rune Feb 19, 2026, 2:42 AM

#

fails

tough charmBOT Feb 19, 2026, 2:43 AM

#

“Fails” can mean a few different things here — but your last log proves the idea is right; we just need the tunnel to run on the PC, and we need the exact error text from the PC.

1) Make sure you’re running the tunnel on your PC (Windows), not inside the VM

If your prompt looks like this:

openclaw@openclaw01:~$

…you are on the VM, not on the PC.

On the PC, open PowerShell (or Windows Terminal) and run:

ssh -N -L 18790:127.0.0.1:18789 openclaw@192.168.112.128

#

(Using 18790 avoids “port already in use” on the PC.)

Then open in your PC browser:

http://127.0.0.1:18790/

2) If it still fails: paste the exact PowerShell error

Copy/paste exactly what PowerShell prints after you run the command above.

Common ones and what they mean:

bind ... Address already in use → that port is taken on your PC (try another like 18791)
Connection timed out / Could not resolve hostname → PC can’t reach the VM at that IP, or wrong IP
ssh : The term 'ssh' is not recognized → SSH client missing (rare on modern Windows)

3) Quick port-use check (on the PC)

If you get “Address already in use”, run:

#

netstat -ano | findstr :18790

and we’ll pick a free local port.

Send the PowerShell output and I’ll tell you the exact next step.

dusty rune Feb 19, 2026, 2:45 AM

#

This site can’t be reached
127.0.0.1 refused to connect.

#

This site can’t be reached
127.0.0.1 refused to connect.

#

hello?

tough charmBOT Feb 19, 2026, 2:59 AM

#

I’m here — we’re just missing one concrete detail from the PC side.

Right now we know:

SSH works (you can log into the VM)
The tunnel command you ran was inside the VM, where port 18789 is already taken (so it failed with “Address already in use”)

Do this exact thing on your PC (Windows)

Open PowerShell on your PC (not the VM)
Run:

ssh -N -L 18790:127.0.0.1:18789 openclaw@192.168.112.128

Leave that window open (it should “hang” with no output).

In your PC browser open:

#

http://127.0.0.1:18790/

Then tell me which of these happens

A) PowerShell prints an error immediately (copy/paste it), or
B) The command stays running, but the browser still can’t load (tell me the browser error).

If you’re unsure whether you’re on the PC vs VM: on the PC you’ll see a PS C:\...> prompt; on the VM you’ll see openclaw@openclaw01:~$.

dusty rune Feb 19, 2026, 3:00 AM

#

bind [127.0.0.1]:18790: Address already in use
channel_setup_fwd_listener_tcpip: cannot listen to port: 18790
Could not request local forwarding.

tough charmBOT Feb 19, 2026, 3:01 AM

#

Great, that’s a clear one: port 18790 is already taken on your PC.

Just pick another local port for the tunnel.

1) Find what’s using 18790 (optional, but helpful)

On your PC PowerShell:

netstat -ano | findstr :18790

That will show the PID that’s holding it.

2) Use a different local port (quick fix)

Try 18791:

#

ssh -N -L 18791:127.0.0.1:18789 openclaw@192.168.112.128

Then open:

http://127.0.0.1:18791/

If 18791 is also taken, just keep incrementing (18792, 18793, …) until it stays running.

3) Once the page loads, you’ll likely need the gateway token

If you get 1008: gateway token missing, grab it on the VM:

openclaw config get gateway.auth.token

#

…and paste it into the dashboard Settings.

Tell me which local port finally works (or paste the netstat line if you want to free the port instead).

dusty rune Feb 19, 2026, 3:09 AM

#

connection refused

tough charmBOT Feb 19, 2026, 3:14 AM

#

“Connection refused” (in the browser) means nothing is listening on that local port on your PC → i.e. the SSH tunnel is not actually up (or you opened the wrong port).

Let’s make it unambiguous:

1) Pick a “weird” local port to avoid conflicts

On your PC PowerShell, run (and leave it running):

ssh -N -L 18889:127.0.0.1:18789 openclaw@192.168.112.128

This command should appear to “hang” with no output. That’s good.

2) While that’s running, test the local port (PC, new PowerShell window)

Test-NetConnection 127.0.0.1 -Port 18889

#

If it says TcpTestSucceeded : True → tunnel is up → open:
- http://127.0.0.1:18889/
If it says False → tunnel isn’t up. Then the SSH window must have printed an error or exited. Paste that error.

3) Tell me which “connection refused” you mean

When you say “connection refused”, is it:

the browser error (ERR_CONNECTION_REFUSED) to 127.0.0.1:xxxxx, or
the ssh command error like connect to host ... port 22: Connection refused?

Reply with:

the exact URL you opened, and
whether Test-NetConnection …18889 is True/False, and
anything printed in the SSH window.

dusty rune Feb 19, 2026, 3:25 AM

#

This is the result:
Last login: Thu Feb 19 02:40:03 2026 from 192.168.112.1
openclaw@openclaw01:~$ ssh -N -L 18777:127.0.0.1:18789 openclaw@192.168.112.128
openclaw@192.168.112.128's password:

When I try http://127.0.0.1:18777/ it times out. refused to connect

#

I cannot be the only one trying to do this

tough charmBOT Feb 19, 2026, 3:27 AM

#

You’re not — this is a super common “remote localhost” + “port already used” tunnel dance. The good news is: the errors you’re seeing are normal and very specific.

Right now you’ve hit two different issues:

“Address already in use” → you picked a local port on your PC that some other program is already using.
“Connection refused” in the browser → the tunnel wasn’t actually running on the port you opened.

Let’s do a clean, almost-guaranteed-to-work run:

Clean recipe (Windows PC → Ubuntu VM dashboard)

Step A — Start tunnel on a fresh port (18889)

On your PC PowerShell:

ssh -N -L 18889:127.0.0.1:18789 openclaw@192.168.112.128

#

Important: leave that PowerShell window open. If it closes or prints an error, the tunnel is not running.

Step B — Verify the tunnel is up (no guessing)

Open a second PowerShell window on your PC:

Test-NetConnection 127.0.0.1 -Port 18889

If it says TcpTestSucceeded : True → tunnel is up.
If False → the tunnel is not up (we need the exact SSH error).

Step C — Open dashboard through the tunnel

In your PC browser, open:

http://127.0.0.1:18889/

#

Step D — If it says “gateway token missing”

On the VM:

openclaw config get gateway.auth.token

Paste that into the dashboard settings “Gateway Token” field.

Tell me just one thing and I’ll pinpoint it

What does this show on your PC?

Test-NetConnection 127.0.0.1 -Port 18889

#

(Just paste the output.)

dusty rune Feb 19, 2026, 3:28 AM

#

no tunnel is working - i have tried like 5 of them

tough charmBOT Feb 19, 2026, 3:30 AM

#

You’re not the only one — but the tunnel part is very binary: either the SSH command is still running (then it works), or it exited (then the browser gets “connection refused”).

Also: earlier you got 1008 … gateway token missing — that actually means the tunnel was working at that moment. So we’re close.

Make the tunnel succeed 100% (Windows PC → Ubuntu VM)

On your PC (PowerShell prompt should look like PS C:\...>, not openclaw@...$), run:

ssh -v -o ExitOnForwardFailure=yes -N -L 18889:127.0.0.1:18789 openclaw@192.168.112.128

Leave that window open. If it exits, paste what it printed.

In a second PowerShell window, verify the port is actually listening:

#

Test-NetConnection 127.0.0.1 -Port 18889

If TcpTestSucceeded : True → open http://127.0.0.1:18889/
If False → the tunnel is not up (we need the SSH output from the first window)

If the page loads but says “gateway token missing”

That’s expected with a remote setup. On the VM, run:

openclaw config get gateway.auth.token

Then paste it into the dashboard Settings (gear icon) → Gateway Token.

One key question

#

When you run the tunnel command on the PC, does it stay open (no prompt), or does it return to the prompt with an error? If it errors, paste the error line(s).

dusty rune Feb 19, 2026, 3:33 AM

#

ComputerName : 127.0.0.1
RemoteAddress : 127.0.0.1
RemotePort : 18889
InterfaceAlias : Loopback Pseudo-Interface 1
SourceAddress : 127.0.0.1
TcpTestSucceeded : True

tough charmBOT Feb 19, 2026, 3:34 AM

#

Nice — that means the tunnel is working right now. So you’re past the hard part.

Now do this:

1) Open the dashboard through the tunnel

On your PC browser, go to:

http://127.0.0.1:18889/

2) If you see `1008: gateway token missing`

That’s normal. Grab the token on the VM:

openclaw config get gateway.auth.token

Then on the dashboard page (the Control UI):

#

open Settings (gear icon)
paste into Gateway Token
connect/reload

3) If you instead see `pairing required`

Approve it on the VM:

openclaw devices list
openclaw devices approve <requestId>

Tell me what exact disconnect/error message you see now when you open http://127.0.0.1:18889/ (token missing vs pairing required vs something else).

dusty rune Feb 19, 2026, 3:35 AM

#

omg we did it!

tough charmBOT Feb 19, 2026, 3:36 AM

#

Hell yeah. The key pieces were:

run the SSH tunnel on the PC (not inside the VM)
use a free local port (18889)
then paste the gateway token when the UI complained

If you want to help the next person: the “tunnel is actually up” check is:

Test-NetConnection 127.0.0.1 -Port 18889

If this solved it, please mark the solution message (right‑click → Apps → ✅ Mark Solution) so Answer Overflow indexes it.

#trying to access the dashboard

Recommended (works in basically every setup): SSH tunnel

Alternative (LAN access, less safe): bind to LAN

About the “https bit”

What “bridged + NAT” means for dashboard access

NAT adapter

Bridged adapter

Best option (works regardless of NAT/bridged, and avoids HTTPS headaches): SSH tunnel

If you want to access it directly via bridged IP (less recommended)

Quick question so I can pinpoint it

The big gotcha: remote over plain HTTP is blocked by default

Fix options (pick one)

Option A (recommended): SSH tunnel → open on localhost

Option B (recommended): HTTPS via Tailscale Serve

Option C (workaround): allow insecure HTTP (downgrades security)

Quick check

Fix 1 (best / fastest): SSH tunnel, then use localhost

Fix 2 (nice UX): Tailscale Serve (HTTPS)

Fix 3 (not recommended, but works): allow insecure auth over HTTP

What risk it adds

When it’s low-ish risk

When it’s a bad idea

My recommendation

Easiest fix (usually): reset the browser’s saved device identity

If you see “pairing required”: approve the new device on the VM

Alternative (also good): use an SSH tunnel so it counts as “localhost”

1) Clear the browser’s stored device token (fastest)

2) If it then says “pairing required”, approve it on the VM

3) If it still says “device token mismatch”, revoke the old device entry

Chrome / Edge (Windows)

Firefox (Windows)

Then clear the site data (to fix the device token mismatch)

Open DevTools in Brave (Windows)

Clear the saved device token / site data (fixes the mismatch)

If you can’t find “Application”

1) First: what URL are you opening?

2) If you’re trying the SSH tunnel, use this exact flow

3) If the page loads but disconnects: paste the new disconnect reason

4) Quick question so I can land this:

If you want the SSH-tunnel path (recommended)

If you don’t want SSH tunnels

Quick thing to paste so I can pinpoint it

Step A (on the VM): revoke the paired operator device(s)

Step B (on your PC / Brave): actually clear the site data for the right origin

Step C: reconnect → you should get “pairing required”

1) Run revoke and paste the command output

2) Re-list to confirm it’s revoked

3) After it’s revoked: fix the browser side

1) Let’s verify whether the revoke command is actually succeeding

2) Easiest way to stop fighting device tokens: use an SSH tunnel

1) The device entry will NOT disappear

2) The browser still has an old token cached → that’s why you keep getting “device token mismatch”

The clean fix (recommended): use an SSH tunnel so the UI is “localhost”

If you insist on opening http://192.168.112.128:18789/

What you’re actually stuck on

Fix (do this exact sequence)

Even simpler (recommended): SSH tunnel

What your devices list --json is telling us

The “device token mismatch” you see in Brave is a browser-side cache problem

Option A (recommended): SSH tunnel so the UI is localhost

Option B: wipe Brave’s storage for the exact URL you’re using

One question to unblock this fast

Fix: make 127.0.0.1 on your PC forward to the VM (SSH tunnel)

If that still fails, the usual cause is: local port already in use

Quick check

1) Get the token on the VM

2) Paste it into the Control UI on your PC

In the dashboard page (http://127.0.0.1:18789/)

If you still can’t find it

Step 1: open the dashboard via an SSH tunnel (recommended)

Step 2: easiest way to avoid hunting for the token field

If you still see gateway token missing

1) First check: can you SSH into the VM at all?

2) If SSH works, start the tunnel (and keep the window open)

3) Common Windows gotcha: local port already in use

Tell me this (so I can pinpoint it)

Do this instead

Option A (recommended): run the tunnel on your PC

Option B: if you want to test the tunnel from the VM anyway, use a different local port

Quick check

If you insist on opening `http://192.168.112.128:18789/`

What your `devices list --json` is telling us

If you still see `gateway token missing`

2) If you see `1008: gateway token missing`

3) If you instead see `pairing required`