openclaw device list always has a new pending request | Friends of the Crustacean 🦞🤝 | Page 1

cyan raptor Apr 29, 2026, 6:27 PM

#

as title states and i always get an error like
"gateway connect failed: GatewayClientRequestError: scope upgrade pending approval (requestId: xxxxx)"

zealous locustBOT Apr 29, 2026, 6:27 PM

#

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

shy ridgeBOT Apr 29, 2026, 6:28 PM

#

That error usually means the device is already paired, but is now asking for broader scopes, so OpenClaw creates a pending upgrade instead of silently approving it. Only approve it if you recognize the device. (docs.openclaw.ai)

First, can you paste:

openclaw --version
openclaw devices list

Then approve the current request ID shown by devices list:

openclaw devices approve <requestId>

Important: run devices list immediately before approving — reconnects can supersede the old pending request and create a new requestId. Current docs also say approve --latest previews rather than minting tokens, so use the exact ID. (docs.openclaw.ai)

OpenClaw

Devices - OpenClaw

#

If it comes back again right after approval, check whether the Requested scopes are larger than Approved, or whether the public key/device details keep changing. That usually means the client is repeatedly reconnecting with different auth details, not that the approval command failed.

cyan raptor Apr 29, 2026, 6:31 PM

#

i did openclaw device list and copied the pending request id and did openclaw devices approve <id> but it returns
"
│
gateway connect failed: GatewayClientRequestError: scope upgrade pending approval (requestId: 36fdee9a-dd93-4f49-8218-f5fcb03574f1)
◇
Direct scope access failed; using local fallback.
unknown requestId"

shy ridgeBOT Apr 29, 2026, 6:31 PM

#

That combo is the clue:

Direct scope access failed; using local fallback + unknown requestId

Usually means you’re approving from a client/local tunnel that can’t use the gateway RPC scope, then the CLI falls back to local files and can’t find that request there. In other words: likely wrong machine/context, or the request ID got superseded.

Do this from the machine actually running the Gateway:

openclaw --version
openclaw devices list
openclaw devices approve <current-request-id-from-that-list>

If your Gateway is remote, SSH into the Gateway host and run it there. Or pass explicit Gateway auth so it doesn’t rely on the paired device token:

#

openclaw devices list --url <gateway-ws-url> --token <gateway-token>
openclaw devices approve <requestId> --url <gateway-ws-url> --token <gateway-token>

If it still says unknown requestId, run openclaw devices list again immediately — request IDs can be replaced when the device reconnects with changed scopes/details.

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

cyan raptor Apr 29, 2026, 6:34 PM

#

my gateway is not remote, its on my wsl tho i have restart the wsl a few times and i think its on background service

shy ridgeBOT Apr 29, 2026, 6:35 PM

#

Ah, WSL + background service makes this more likely to be a split-brain/state mismatch: the Gateway service may be running with a different profile/state dir than the CLI you’re using.

From inside WSL — not PowerShell — run:

openclaw --version
openclaw gateway status
openclaw status --all
openclaw doctor

In openclaw gateway status, look specifically for whether Config (cli) and Config (service) differ, and whether Connectivity probe is ok.

Then try the clean sequence:

#

openclaw gateway restart
openclaw devices list
openclaw devices approve <current-request-id>

If it still says Direct scope access failed; using local fallback + unknown requestId, paste the redacted output of:

openclaw gateway status
openclaw devices list

That should tell us if the service is using a different config/home/profile than your shell. Docs for this exact class of issue: https://docs.openclaw.ai/start/faq

cyan raptor Apr 29, 2026, 6:37 PM

#

output of gateway status:
Service: systemd (enabled)
File logs: /tmp/openclaw/openclaw-2026-04-30.log
Command: /usr/bin/node /home/evy/.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=loopback (127.0.0.1), port=18789 (service args)
Probe target: ws://127.0.0.1:18789
Dashboard: http://127.0.0.1:18789/
Probe note: Loopback-only gateway; only local clients can connect.

Runtime: running (pid 1188, state active, sub running, last exit 0, reason 0)
Connectivity probe: ok
Capability: read-only

Listening: 127.0.0.1:18789
Troubles: run openclaw status
Troubleshooting: https://docs.openclaw.ai/troubleshooting
evy@PCbaubs:~$ openclaw devices list

output of devicelist:
gateway connect failed: GatewayClientRequestError: scope upgrade pending approval (requestId: 668fe873-2a67-41a7-a500-e7f2562dfd19)
◇
Direct scope access failed; using local fallback.
Pending (1)

shy ridgeBOT Apr 29, 2026, 6:38 PM

#

Yep, this explains it:

Capability: read-only means your CLI can connect, but only with operator.read. openclaw devices list/approve needs operator.pairing, so the CLI itself is creating a scope-upgrade request, then falling back locally.

Use the shared gateway token/password once to approve the upgrade — don’t paste the token here:

TOKEN="$(openclaw config get gateway.auth.token)"

openclaw devices list --token "$TOKEN"
openclaw devices approve <requestId-from-that-list> --token "$TOKEN"

If you use password auth instead:

#

openclaw devices list --password '<gateway-password>'
openclaw devices approve <requestId-from-that-list> --password '<gateway-password>'

Key bit: don’t approve using the ID from the error text yet. First run devices list with --token so it talks to the Gateway with full shared-secret auth instead of the stale read-only paired device token.

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

cyan raptor Apr 29, 2026, 6:44 PM

#

it still says this
gateway connect failed: GatewayClientRequestError: scope upgrade pending approval (requestId: b53b8178-f164-4460-adea-2cd00da53d81)
◇
Direct scope access failed; using local fallback.
unknown requestId

shy ridgeBOT Apr 29, 2026, 6:45 PM

#

Ah — I think I led you into a trap there, sorry 🦐

If you used:

TOKEN="$(openclaw config get gateway.auth.token)"

that likely set TOKEN to __OPENCLAW_REDACTED__, not the real token. Then OpenClaw falls back to the stale read-only device token and you get the same scope-upgrade loop.

Easiest deterministic fix: rotate/set a known gateway token from inside WSL:

NEW_TOKEN="$(openssl rand -hex 32)"

openclaw config set gateway.auth.token "$NEW_TOKEN"

#

openclaw gateway restart

openclaw devices list --token "$NEW_TOKEN"
openclaw devices approve <requestId-from-that-list> --token "$NEW_TOKEN"

After that, reopen the dashboard/Control UI and use the new token if prompted.

If devices list --token "$NEW_TOKEN" still gives the same scope-upgrade error, paste the exact command you ran without the token value, plus:

openclaw config get gateway.auth.mode

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

cyan raptor Apr 29, 2026, 7:11 PM

#

gateway connect failed: GatewayClientRequestError: scope upgrade pending approval (requestId: df3aeaa6-c020-47cf-9c4c-cfae802d56d5)
◇
Direct scope access failed; using local fallback.
unknown requestId

shy ridgeBOT Apr 29, 2026, 7:13 PM

#

That exact output means the command still did not authenticate with the shared gateway token — it’s falling back to the stale read-only device path again.

Let’s force token mode + a fresh token:

openclaw config set gateway.auth.mode token

NEW_TOKEN="$(openssl rand -hex 32)"
openclaw config set gateway.auth.token "$NEW_TOKEN"

openclaw gateway restart

Then approve using that token:

#

openclaw devices approve --latest --token "$NEW_TOKEN"

That should print the exact pending request and an approve command. Then run:

openclaw devices approve <that-request-id> --token "$NEW_TOKEN"

Also: ignore the request ID in the gateway connect failed... error. That ID is from the failed read-only connection path and can be different from the real pending row.

cyan raptor Apr 29, 2026, 7:15 PM

#

evy@PCbaubs:~$ openclaw devices approve e3274d44-e830-4e4c-95ed-66dd936b8eee --token "$NEW_TOKEN"

🦞 OpenClaw 2026.4.22 (00bd2cf) — Gateway online—please keep hands, feet, and appendages inside the shell at all times.

│
gateway connect failed: GatewayClientRequestError: scope upgrade pending approval (requestId: 766a3a0d-d493-48fb-830e-6fb08cda49c3)
◇
Direct scope access failed; using local fallback.
unknown requestId

shy ridgeBOT Apr 29, 2026, 7:16 PM

#

Okay — now I’d stop chasing the request IDs. You’re on OpenClaw 2026.4.22, and this looks like either stale device-token retry behavior or the new token still not being accepted.

First update, then retry:

openclaw update
openclaw gateway restart
openclaw doctor

Then verify your shell variable is actually set — don’t paste the token:

echo "${#NEW_TOKEN}"
openclaw config get gateway.auth.mode

#openclaw device list always has a new pending request