#Infinite Permission/Handshake Loop on v2026.5.7

1 messages · Page 1 of 1 (latest)

candid wraith
#

I've got OpenCLAW running on Oracle Cloud (Ubuntu), Clean install of @2026.5.7

I am stuck in a perpetual "Security Handshake" loop that prevents full access, even after a total system wipe (rm -rf ~/.openclaw, binary uninstall, and reboot).

Symptoms & Failed Steps:

Approval Race Condition: Every time I attempt to approve a requestId generated by a device's rotate command, the CLI handshake itself triggers a new request, which immediately invalidates the previous one ("Unknown Request ID").

Despite using the fresh Master Token generated seconds prior by OpenCLAW onboard, the Gateway intermittently reports a "Mismatch" or "Denied" error during rotation.

UI Dead-Ends: Accessing the Dashboard via SSH tunnel (Port 18789) works, but the Rotate button in the Nodes tab is unresponsive. It fails to apply elevated scopes (operator.admin, etc.) to the terminal device, leaving it stuck in operator.pairing only.

Even with OPENCLAW_GATEWAY_TOKEN exported and OPENCLAW_ALLOW_INSECURE_PRIVATE_WS=1 active, the gateway status fluctuates between connected-no-operator-scope and pairing-pending, never reaching full-access.

The security layer in this version is effectively locking out the administrator. I’ve tried manual approval, --latest flags, and UI overrides. The handshake logic is currently a "snake eating its own tail."

I've even logged into the management console via localhost, and the rotate button does nothing when clicked. Can someone help me with a way to force-approve a device ID via the config file or a --force-admin flag that actually works without requiring a circular network handshake?

gusty sealBOT
#

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

woeful cliffBOT
#

This does sound like the device-pairing/scope-upgrade path eating itself. I checked the current docs/source: there is not a supported --force-admin that blindly grants admin to an arbitrary device, and I would not hand-edit ~/.openclaw/devices/paired.json unless a maintainer gives you an exact recovery script — approval generates scoped device tokens, so a manual JSON edit is easy to make worse.

Two important bits that may unblock you:

  1. If you pass --url, the devices CLI does not fall back to config/env creds. Pass the token explicitly:
TOKEN='paste-current-gateway-token-here'
openclaw devices list --url ws://127.0.0.1:18789 --token "$TOKEN"
openclaw devices approve <current-requestId> --url ws://127.0.0.1:18789 --token "$TOKEN"

Run devices list immediately before approve; pending request IDs expire/supersede when role/scopes/public key change.

  1. For Control UI only, there is a documented break-glass flag:
openclaw config set gateway.controlUi.dangerouslyDisableDeviceAuth true --strict-json
openclaw gateway restart
#

Then open the dashboard through your SSH tunnel, authenticate with the current gateway token, approve/repair the device, and turn it back off immediately:

openclaw config set gateway.controlUi.dangerouslyDisableDeviceAuth false --strict-json
openclaw gateway restart

This is a severe security downgrade while enabled, so don’t leave it on exposed to the internet.

Also please paste these, redacting tokens:

openclaw --version
openclaw status --all
openclaw doctor
openclaw devices list --json

Docs I checked: https://docs.openclaw.ai/cli/devices, https://docs.openclaw.ai/web/control-ui#if-you-see-unauthorized-1008, https://docs.openclaw.ai/gateway/operator-scopes

candid wraith
#

None of those things worked. What did work was manually editing the paired.json file. I know it was advised against, but your security system is essentially broken here. Strangely, the gateway status still shows read-only access, but the devices list shows all permissions/scopes. It functions, but this was over a day's worth of heartache trying to avoid a hard-coded file trick to use your software/CLI/UI to no avail.

woeful cliffBOT
#

Oof — I’m sorry. If the only working recovery was editing paired.json, that’s a real break-glass failure, not “user error”. Thanks for sticking with it long enough to isolate that.

The weird split you’re seeing — devices list shows full scopes but gateway status still says read-only — usually means the status probe is authenticating through a different lane than the device entry you repaired: stale local cached device token, different config/state dir, explicit gateway.remote.*, or the CLI service using a different environment than your shell.

I’d do two things now:

openclaw status --all
openclaw doctor
openclaw devices list --json
openclaw config get gateway.remote.url
openclaw config get gateway.auth.token

Redact tokens, but keep device IDs/request IDs/scopes. If status is still read-only while devices list shows admin scopes, that’s very useful evidence.

And please file this as a GitHub issue: https://github.com/openclaw/openclaw/issues