Sub-agents gateway pairing issue | Friends of the Crustacean 🦞🤝 | Page 1

tawny wedgeBOT Feb 23, 2026, 10:08 PM

#

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

halcyon raptor Feb 28, 2026, 6:17 AM

#

What about unable to access local dashboard even after resetting passwords several times?

mighty terraceBOT Feb 28, 2026, 6:19 AM

#

That “disconnected (1008): pairing required” is almost always device pairing, not “your gateway token/password is wrong”.

So two separate things are getting mixed together:

Gateway auth (token/password) → proves you know the secret
Device pairing → one-time approval for a new browser / new worker / new node that’s trying to connect

Fix for Dashboard “1008 pairing required”

On the gateway host, run:

openclaw devices list
openclaw devices approve <requestId>

Then reload the dashboard.

#

Docs: https://docs.openclaw.ai/web/control-ui (section “Device pairing (first connection)”)

Common gotchas:

If you cleared browser storage / switched browser profiles, it creates a new device id → you must approve again.
If you’re opening the UI via LAN / Tailnet / remote IP, pairing is expected. (127.0.0.1 is auto-approved.)
In the dashboard settings there are two auth fields (token + password). If your gateway is in token mode, “resetting passwords” won’t help—you need to paste the gateway token.

Dashboard/token docs: https://docs.openclaw.ai/web/dashboard

Fix for “sub-agents / specialists bootstrapping” + pairing required

Those “specialists” are also “devices” (or nodes) from the gateway’s POV, so they can get blocked by the same pairing gate.

Do this on the gateway host:

Check for pending device approvals (often the culprit):

#

openclaw devices list

If they’re actually nodes, they may show up here instead:

openclaw nodes pending
openclaw nodes approve <requestId>

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

If you approve them and they immediately reappear as “new” every restart, it usually means the workers are running with an ephemeral state dir (container/tmp) so their device identity keeps changing.

If you “can’t access local dashboard” even after auth/pairing

A few fast checks that explain most cases:

#

Make sure you’re really using local:
- On the gateway machine: http://127.0.0.1:18789/
- If the gateway is remote: use an SSH tunnel or Tailscale Serve (HTTPS) (plain http://<lan-ip> can trigger “device identity required” issues in some setups)
Verify the gateway is healthy + what auth mode it expects:

openclaw gateway status
openclaw logs --follow

Troubleshooting runbook: https://docs.openclaw.ai/gateway/troubleshooting

If you paste the exact disconnect line you see in the dashboard (1008 pairing required vs device identity required vs unauthorized) and the output of:

openclaw --version
openclaw devices list (redact ids if you want)

#

…I can tell you which branch you’re on in one step.

halcyon raptor Feb 28, 2026, 6:30 AM

#

This is what I got:

Expanded Security Maintenance for Applications is not enabled.
17 updates can be applied immediately.
16 of these updates are standard security updates.
To see these additional updates run: apt list --upgradable
Enable ESM Apps to receive additional future security updates.
See https://ubuntu.com/esm or run: sudo pro status
Last login: Fri Feb 27 17:17;31 2026 from 136.158.27.186
root@srv1425092:# su -clawd
bash: line 1: lawd: command not found root@srv1425092:# su - clawd

mighty terraceBOT Feb 28, 2026, 6:30 AM

#

su -clawd failed because there’s a missing space — su interpreted it as -c lawd (run command “lawd”), hence lawd: command not found.

Use:

su - clawd

(or if that user doesn’t exist, you need the actual user your gateway service runs as — often openclaw.)

The key thing: approve pairing as the SAME user/state dir as the running gateway

Device pairing approvals are stored under the gateway state dir (default ~/.openclaw). If you run openclaw devices list as root but the gateway daemon runs as clawd (or openclaw), you’ll be looking at the wrong state store → you’ll never see/approve the pending requests the gateway cares about.

On the gateway host, run (as root is fine for the first command):

#

openclaw --version
openclaw gateway status --deep

Paste the output, especially the lines that show Config (service) / State dir (or similar).

Then switch to that user and approve:

su - <that-user>
openclaw devices list
openclaw devices approve <requestId>

If your “sub-agents” are actually nodes/workers showing up as node pairing:

#

openclaw nodes pending
openclaw nodes approve <requestId>

For the dashboard auth specifically

If the dashboard shows 1008 pairing required, that’s device pairing, not “wrong password”. Resetting the password won’t fix it unless you’re actually in gateway.auth.mode="password".

Docs (pairing): https://docs.openclaw.ai/web/control-ui
Docs (dashboard/token): https://docs.openclaw.ai/web/dashboard

Next info that will unblock this fast

Reply with:

openclaw --version
openclaw gateway status --deep (redact hostnames/IPs if you want)
and whether you’re opening the dashboard via 127.0.0.1 or via a remote IP/tailnet URL

#

From there I can tell you exactly which user to run approvals under and why the sub-agents are stuck “bootstrapping”.

halcyon raptor Feb 28, 2026, 6:32 AM

#

After entering the terminal, but when I get to dashboard it says permission denied

mighty terraceBOT Feb 28, 2026, 6:32 AM

#

“Permission denied” on the dashboard usually means you’re hitting the wrong thing (wrong URL/port), not tunneling to the gateway, or you’re authenticating against a different gateway state/user than the daemon is using.

A quick way to make this deterministic (works even on a headless VPS):

1) Don’t open the dashboard via the VPS IP

On your laptop, create an SSH tunnel to the gateway host:

ssh -N -L 18789:127.0.0.1:18789 root@<your-vps>
# (or clawd@<your-vps> / openclaw@<your-vps>, whichever you use)

Then open locally in your browser:

http://127.0.0.1:18789/

This guarantees you’re talking to the real gateway even if it only binds to loopback.

#

2) If the UI asks for auth

Get the token on the gateway host (and importantly: as the same user the gateway runs under):

openclaw config get gateway.auth.token

Paste that into the Control UI settings (token field).

3) If it then says `1008: pairing required`

That’s device pairing. Approve it on the gateway host (same user/state dir as the daemon):

openclaw devices list
openclaw devices approve <requestId>

#

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

Two things I need from you to pinpoint why you’re seeing “permission denied”

The exact URL you’re opening when you see it (redact host if you want).
The output of:

openclaw gateway status --deep

(That tells us bind mode, auth mode, and—crucially—whether your CLI is reading the same config/state as the running service.)

If you can also paste a screenshot of the “permission denied” page (or the exact text), I can tell immediately whether it’s the gateway rejecting you vs some other web server/proxy in front.

halcyon raptor Mar 2, 2026, 12:22 PM

#

sudo: password for clawd

i enter the password and it just keeps asking for the password

mighty terraceBOT Mar 2, 2026, 12:23 PM

#

If sudo keeps re-prompting ([sudo] password for clawd: … and then asks again), that almost always means the password you’re typing is not the correct OS account password for the user clawd.

A few quick checks:

Make sure you’re not mixing up “OpenClaw passwords/tokens” with OS login

sudo wants the system user password for clawd (the account you’re logged into), not your gateway token / API key / anything OpenClaw-related.

Confirm which user you are
Run (no sudo needed):

whoami
id

If it’s not clawd, then the sudo prompt might not match what you think.

If you’re on a VPS / Linux server

Many VPS images don’t even have a password set for the user (SSH keys only), or you’re supposed to use a different default user (often ubuntu, debian, etc.).

#

If you don’t know the OS password for clawd, you typically have to:
- log in as the correct admin user, or
- use your provider’s console/recovery mode to reset the password / fix sudoers.

If you’re on macOS

It’s your Mac login password for that account.
If it keeps failing: double-check keyboard layout / caps lock (macOS won’t show characters while typing—this is normal).

What I need from you to be precise
Paste:

your OS (macOS? Ubuntu? Debian?),
the exact command you ran (e.g. sudo openclaw gateway restart),
and the exact terminal output (including the “Sorry, try again.” lines).

Also: don’t paste any real passwords/tokens—just the error text.

halcyon raptor Mar 2, 2026, 12:24 PM

#

I am not on Mac

#

Also, I checked this in the VPS terminal. I asked whoami and it says “clawd” but i cannot login to clawdbot

mighty terraceBOT Mar 2, 2026, 12:30 PM

#

On Linux, two separate things are getting mixed together here:

1) The `sudo` password loop

If sudo keeps asking again, it means the OS password you typed is wrong (or that user doesn’t have a usable password set). This is not your OpenClaw token/password.

Good news: for most OpenClaw ops you shouldn’t need sudo. Try without it:

openclaw gateway status
openclaw gateway restart
openclaw status --all

If you really need sudo for something, paste the exact output you see (it usually includes Sorry, try again.). Also run:

#

whoami
groups

2) Fixing `disconnected (1008): pairing required` (this blocks sub-agents / UI / remote clients)

That error almost always means a device needs approval.

On the gateway host, run:

openclaw devices list
openclaw devices approve <requestId>

Then retry whatever was connecting (Control UI tab / remote client / etc).

#

Docs:

What I need to pinpoint the exact blocker

Please paste (redact nothing except secrets; status --all is safe and redacts tokens):

openclaw --version
openclaw gateway status
openclaw status --all
openclaw devices list

If gateway status shows Config (cli) ≠ Config (service), that’s a very common cause of “main works but other stuff can’t auth”, and the fix is usually:

#

openclaw gateway install --force
openclaw gateway restart

#

If whoami on the VPS says clawd, you’re on the right box — and you generally don’t need sudo for OpenClaw (it’s usually a user service).

The “pairing required” fix (this is almost always it)

That message means: a new device/client (Control UI browser, node, remote client, etc.) tried to connect and the gateway is waiting for you to approve it.

On the VPS (gateway host), run:

openclaw devices list

You should see a pending request with a requestId. Approve it:

openclaw devices approve <requestId>
# or just approve the most recent:

#

openclaw devices approve --latest

Then refresh/retry the thing that was stuck (Control UI tab, node, “sub-agent”, etc.).

Docs: https://docs.openclaw.ai/web/control-ui#device-pairing-first-connection

About “I cannot login to clawdbot”

“Clawdbot” is just the old name — the CLI should be openclaw. What exactly are you trying to “login” to?

If you mean the Control UI in your browser → the fix is openclaw devices approve … above.
If you mean WhatsApp linking → that’s a different flow entirely.

Paste the output of these (safe to share; don’t paste tokens):

#

openclaw --version
openclaw gateway status
openclaw devices list

With that, I can tell you immediately whether it’s (a) a pending device approval, or (b) config mismatch between service vs CLI, etc.

halcyon raptor Mar 2, 2026, 12:35 PM

#

I am not linking anything anymore this is a new topic.

I need help because I cannot access my clawdbot

#

I meant clawdbot control

mighty terraceBOT Mar 2, 2026, 12:37 PM

#

“clawdbot” is just the old name — there isn’t a separate “clawdbot login”. Access usually means one of:

Control UI in your browser can’t connect (often shows disconnected (1008): pairing required)
Your remote client / node / specialist agent can’t connect to the gateway (same error)
Your chat surface (Slack/Telegram/WhatsApp) isn’t responding (different issue)

Given your error is pairing required, fix #1/#2 first:

Fix: approve the pending device (do this on the VPS)

SSH into the VPS (as clawd) and run:

openclaw devices list

You should see a pending request with a requestId. Approve it:

#

openclaw devices approve --latest
# or: openclaw devices approve <requestId>

Then refresh the Control UI / reconnect the client that was failing.

Docs: https://docs.openclaw.ai/web/control-ui#device-pairing-first-connection

If you instead see “unauthorized” (token mismatch)

Get the gateway token on the VPS (don’t paste it here):

openclaw config get gateway.auth.token

#

…and paste that token into the Control UI settings (“Gateway Access”).

Paste these outputs (safe; tokens redacted) so I can tell what’s actually failing

Run on the VPS:

openclaw --version
openclaw gateway status
openclaw status --all
openclaw devices list

Also: when you say “cannot access my clawdbot”, which one is it specifically — Control UI in browser, TUI, or a chat channel?

#

If you mean the Control UI (dashboard) in the browser, and you’re seeing disconnected (1008): pairing required, that’s device pairing, not “gateway token mode” being broken.

You have 2 ways to get back in:

Option A (fastest + avoids pairing): SSH tunnel (recommended)

From your laptop, run (leave it running):

ssh -N -L 18789:127.0.0.1:18789 clawd@<your-vps-host>

Then open in your browser:

http://127.0.0.1:18789/

If it asks for a token, get it on the VPS (don’t paste it here):

#

openclaw config get gateway.auth.token

Paste that into the Control UI “Gateway Access” token field and connect.

Option B (direct access): approve the browser as a device

On the VPS, run:

openclaw devices list
openclaw devices approve --latest

Then refresh the Control UI page.

Note: every new browser profile / incognito / cleared browser storage will look like a new device and need pairing again.

#Sub-agents gateway pairing issue