Gateway pairing failure | Friends of the Crustacean 🦞🤝 | Page 1

teal hollow Apr 16, 2026, 4:11 AM

#

12:11:16+00:00 error gateway/channels/telegram {"subsystem":"gateway/channels/telegram"} failed to start native approval handler: GatewayClientRequestError: pairing required
12:11:16+00:00 warn gateway/ws {"subsystem":"gateway/ws"} {"cause":"pairing-required","handshake":"failed","durationMs":16,"lastFrameType":"req","lastFrameMethod":"connect","lastFrameId":"<GUID>","host":"<IP_ADDRESS>:<PORT>","remoteAddr":"<IP_ADDRESS>","remotePort":<PORT>,"localAddr":"<IP_ADDRESS>","localPort":<PORT>,"endpoint":"<IP_ADDRESS>:<PORT>-><IP_ADDRESS>:<PORT>","deviceId":"<DEVICE_ID>","requestId":"<GUID>","reason":"scope-upgrade"} closed before connect conn=<GUID> peer=<IP_ADDRESS>:<PORT>-><IP_ADDRESS>:<PORT> remote=<IP_ADDRESS> fwd=n/a origin=n/a host=<IP_ADDRESS>:<PORT> ua=n/a code=1008 reason=pairing required
12:11:16+00:00 warn gateway {"subsystem":"gateway"} security audit: device access upgrade requested reason=scope-upgrade device=<DEVICE_ID> ip=unknown-ip auth=token roleFrom=operator roleTo=operator scopesFrom=operator.read scopesTo=operator.admin,operator.approvals,operator.pairing,operator.read,operator.talk.secrets,operator.write client=cli conn=<GUID>
12:11:16+00:00 error gateway connect failed: GatewayClientRequestError: pairing required
12:11:16+00:00 error gateway connect failed: GatewayClientRequestError: pairing required

snow jacinthBOT Apr 16, 2026, 4:12 AM

#

This looks like a scope upgrade pairing request, not a Telegram-specific breakage.

Your log says the device currently has only operator.read, but the approval handler is now requesting broader scopes (operator.approvals, operator.write, operator.pairing, etc.), so the gateway closes with 1008: pairing required.

Try this first:

openclaw --version
openclaw devices list
openclaw devices approve <requestId>

If you're on Docker:

docker compose run --rm openclaw-cli devices list

#

docker compose run --rm openclaw-cli devices approve <requestId>

Two important gotchas:

If the pending request changed, the old requestId is stale, so run openclaw devices list again right before approving.
After approval, reconnect/restart the client that was failing.

Docs:

If it still loops after approval, paste:

openclaw --version
openclaw devices list

#

whether this is bare-metal or Docker

teal hollow Apr 16, 2026, 4:46 AM

#

openclaw --version
OpenClaw 2026.4.12 (1c0672b)

openclaw devices list

:lobster: OpenClaw 2026.4.12 (1c0672b) — Your AI assistant, now without the $3,499 headset.

gateway connect failed: GatewayClientRequestError: pairing required◇  
Direct scope access failed; using local fallback.
Pending (1)
┌──────────────────────────────────────┬───────────────────────────────────────┬──────────┬──────────────────────────────────────────────────────────────────────────────────────────────────────────────┬────────────┬──────────┬────────┐
│ Request                              │ Device                                │ Role     │ Scopes                                                                                                       │ IP         │ Age      │ Flags  │
├──────────────────────────────────────┼───────────────────────────────────────┼──────────┼──────────────────────────────────────────────────────────────────────────────────────────────────────────────┼────────────┼──────────┼────────┤
│ a1a2 │ Telegram Native Approvals (default)   │ operator │ operator.approvals, operator.admin, operator.read, operator.write, operator.pairing, operator.talk.secrets   │            │ just now │ repair │
└──────────────────────────────────────┴───────────────────────────────────────┴──────────┴──────────────────────────────────────────────────────────────────────────────────────────────────────────────┴────────────┴──────────┴────────┘
Paired (2)
┌─────────────────────────────────────────────────────────────────────────────┬───────────────────────┬───────────────────────────────────────────────────────────────────────────────────────────────┬──────────────────────┬────────────┐
│ Device                                                                      │ Roles                 │ Scopes                                                                                        │ Tokens               │ IP         │
├─────────────────────────────────────────────────────────────────────────────┼───────────────────────┼───────────────────────────────────────────────────────────────────────────────────────────────┼──────────────────────┼────────────┤
│ b1b2            │ operator              │ operator.admin, operator.read, operator.write, operator.approvals, operator.pairing           │ operator             │            │
│ c1c2           │ operator              │ operator.read                                                                                 │ operator             │            │
└─────────────────────────────────────────────────────────────────────────────┴───────────────────────┴───────────────────────────────────────────────────────────────────────────────────────────────┴──────────────────────┴────────────┘
-bash: syntax error near unexpected token `newline'

openclaw devices approve a1a2

:lobster: OpenClaw 2026.4.12 (1c0672b) — I'm like tmux: confusing at first, then suddenly you can't live without me.

gateway connect failed: GatewayClientRequestError: pairing required
  
Direct scope access failed; using local fallback.
unknown requestId

snow jacinthBOT Apr 16, 2026, 4:47 AM

#

Nice, this narrows it down a lot.

A couple things stand out:

2026.4.12 is recent enough that this should work.
The pending entry is marked repair, which means OpenClaw sees this as an upgrade of an already-known device.
unknown requestId usually means the pending request changed under you or the ID used wasn’t the exact current one.

I’d try this next:

openclaw devices approve --latest

That should print the current exact request ID and the exact approve command to run. Then run that command immediately.

If you want the raw exact ID without table formatting:

#

openclaw devices list --json

and grab .pending[0].requestId.

Also, your paired list already shows one stale-looking operator device with only operator.read:

c1c2 → operator.read

That’s very likely the one trying to “repair” itself up to full scopes.

If approve keeps coming back with unknown requestId, I’d clean up that stale entry and re-pair it fresh:

openclaw devices remove c1c2

#

openclaw devices list
openclaw devices approve <newRequestId>

Then restart/retry the gateway client.

Also, the -bash: syntax error near unexpected token 'newline' part is just from pasting a fenced block into bash, not part of the pairing problem.

If you want, paste the output of:

openclaw devices approve --latest

and I’ll tell you the safest next move.

teal hollow Apr 16, 2026, 4:55 AM

#

> openclaw devices approve --latest

🦞 OpenClaw 2026.4.12 (1c0672b) — Type the command with confidence—nature will provide the stack trace if needed.


gateway connect failed: GatewayClientRequestError: pairing required

Direct scope access failed; using local fallback.
Selected pending device request f89c2f2a-ea51-46cb-83c1-5c81ccd55dda
  Device: Telegram Native Approvals (default)
  Role:   operator
  Scopes: operator.approvals, operator.admin, operator.read, operator.write, operator.pairing, operator.talk.secrets
Approve this exact request with: openclaw devices approve f89c2f2a-ea51-46cb-83c1-5c81ccd55dda

> openclaw devices approve f89c2f2a-ea51-46cb-83c1-5c81ccd55dda

:lobster: OpenClaw 2026.4.12 (1c0672b) — I'll do the boring stuff while you dramatically stare at the logs like it's cinema.


gateway connect failed: GatewayClientRequestError: pairing required
 
Direct scope access failed; using local fallback.
unknown requestId

snow jacinthBOT Apr 16, 2026, 4:57 AM

#

Yeah, that looks stuck, not just user error.

Since approve --latest finds the request, but approving the exact ID immediately says unknown requestId, I’d stop fighting the repair flow and do a clean re-pair of the stale device.

From your list, the suspicious one is the paired operator device that only has:

operator.read

I’d remove that paired device entry, not the full-scope one.

openclaw devices remove <deviceId-that-only-has-operator.read>
openclaw gateway restart
openclaw devices list

#

openclaw devices approve <newRequestId>

Why I’m recommending that: the docs’ recovery path for pairing/token drift is basically “remove stale pairing, then re-approve”, and your repair request looks like an old read-scoped device trying to widen itself but getting superseded/raced.

Docs:

If the new request still churns after that, I’d treat it as a likely bug in 2026.4.12 repair handling. In that case, paste:

openclaw devices list --json
openclaw doctor

#

and if it still reproduces after a clean re-pair, it’s probably GitHub-issue territory.

teal hollow Apr 16, 2026, 5:30 AM

#

> openclaw devices remove c1c2

🦞 OpenClaw 2026.4.12 (1c0672b) — I've read more man pages than any human should—so you don't have to.
 
[openclaw] Failed to start CLI: Error: gateway timeout after 10000ms
Gateway target: ws://127.0.0.1:18789
Source: local loopback
Config: /root/.openclaw/openclaw.json
Bind: lan
    at Timeout.<anonymous> (file:///usr/lib/node_modules/openclaw/dist/call-DMdUDtab.js:255:9)
    at listOnTimeout (node:internal/timers:585:17)
    at process.processTimers (node:internal/timers:521:7)

snow jacinthBOT Apr 16, 2026, 5:31 AM

#

Ah, that helps.

This timeout is a different problem from the pairing one:

devices list and devices approve can use the local pairing fallback
devices remove cannot, so it has to talk to the gateway RPC directly

So right now the gateway itself looks unhealthy or wedged.

I’d check this next:

openclaw gateway status
openclaw status

If either shows the RPC probe failing, do:

#

openclaw gateway restart

Then retry:

openclaw devices list

If the stale operator.read device is still there after the restart, then retry the cleanup/re-pair path.

If restart does not fix the timeout, paste:

openclaw gateway status --deep

#

openclaw logs --follow

Docs:

So, short version: I don’t think devices remove is the wrong idea, I think the gateway RPC is currently sick, and that’s the blocker now.

naive acorn Apr 16, 2026, 7:27 AM

#

teal hollow 12:11:16+00:00 error gateway/channels/telegram {"subsystem":"gateway/channels/te...

your gateway isn’t running, that’s why it’s timing out.

start it first with: openclaw gateway start

then check: openclaw gateway status

if it still fails, make sure gateway.mode is set to local in your config

snow jacinthBOT Apr 16, 2026, 7:27 AM

#

Yep, openclaw gateway status is the right next check, but I wouldn’t assume “not running” yet.

A timeout can mean either:

Runtime is stopped → openclaw gateway start
Runtime is running but RPC probe is failing/wedged → openclaw gateway restart

So I’d use this flow:

openclaw gateway status

If it says stopped:

#Gateway pairing failure