[Bug]:ontrol UI auto-pairs on loopback but is granted only admin/approvals/pairing scopes, then fails all read RPCs with missing scope: operator.read #46689
Description
Bug type
Behavior bug (incorrect output/state without crash)
Summary
n a macOS local-loopback install, the OpenClaw Control UI/dashboard successfully connects and is auto-paired as an operator device, but the paired device is granted only these scopes:
operator.adminoperator.approvalsoperator.pairing
It is not granted:
operator.readoperator.write
As a result, the dashboard immediately fails on normal read-path RPCs such as:
statussystem-presenceconfig.get
with errors like:
-
missing scope: operator.read
The CLI on the same machine gets the correct operator scopes, so this appears to be specific to the Control UI / webchat pairing path.# Environment -
OpenClaw version:
2026.3.13 -
Install method:
pnpmglobal install -
OS:
macOS 26.1 (arm64) -
Node:
22.22.1 -
Gateway mode:
local -
Gateway bind:
loopback -
Gateway auth:
token -
Dashboard URL:
http://127.0.0.1:18789/ -
Browser: Chrome on the local Mac mini
Relevant config (redacted)
{
"commands": {
"allowFrom": {
"discord": [
"user:654359695682961418"
]
}
},
"channels": {
"discord": {
"enabled": true,
"token": "REDACTED",
"groupPolicy": "allowlist",
"guilds": {
"1482145574177476620": {
"channels": {
"1482145575582302301": {
"allow": true
}
},
"users": [
"654359695682961418"
]
}
},
"streaming": "off"
}
},
"gateway": {
"port": 18789,
"mode": "local",
"bind": "loopback",
"auth": {
"mode": "token",
"token": "REDACTED"
},
"tailscale": {
"mode": "off",
"resetOnExit": false
}
}
}Steps to reproduce
Reproduction steps
- Install/configure OpenClaw locally on macOS with:
gateway.mode: "local"gateway.bind: "loopback"gateway.auth.mode: "token"
- Start the gateway normally.
- Open the Control UI on:
http://127.0.0.1:18789/- or use
openclaw dashboard --no-openand open the generated tokenized URL.
- Let the Control UI auto-pair on loopback.
- Observe that the UI connects, but subsequent RPCs fail.
Expected behavior
Expected behavior
The Control UI should receive the normal operator scope bundle required for dashboard usage, including at least:
operator.readoperator.write
So that the dashboard can successfully call:
statussystem-presenceconfig.get- other standard Control UI read/write methods
Actual behavior
Actual behavior
The Control UI device is auto-paired with only:
operator.adminoperator.approvalsoperator.pairing
and then all standard read RPCs fail with:
missing scope: operator.read
OpenClaw version
OpenClaw 2026.3.13
Operating system
macOS 26.1 (25B78)
Install method
npm global install
Model
openai-codex/gpt-5.4
Provider / routing chain
Discord → OpenClaw gateway (local, loopback) → main agent → openai-codex → gpt-5.4
Config file / key location
No response
Additional provider/model setup details
No response
Logs, screenshots, and evidence
## Evidence
### `openclaw status --all`
Shows gateway degraded/unreachable for detail RPC due to missing `operator.read`:
Gateway local · ws://127.0.0.1:18789 (local loopback) · unreachable (missing scope: operator.read)
### Paired devices
The Control UI devices repeatedly pair with the wrong scope baseline:
{
"deviceId": "7580e92bacc1fa8c87f2c164148dd26935cfcbc14e2036d99391aaf088bfca51",
"clientId": "openclaw-control-ui",
"clientMode": "webchat",
"role": "operator",
"scopes": [
"operator.admin",
"operator.approvals",
"operator.pairing"
]
}
Meanwhile the local CLI device on the same machine gets the expected scopes:
{
"clientId": "cli",
"clientMode": "cli",
"role": "operator",
"scopes": [
"operator.read",
"operator.admin",
"operator.write",
"operator.approvals",
"operator.pairing"
]
}
### Gateway log lines
Examples:
[ws] webchat connected ... client=openclaw-control-ui webchat v2026.3.13
[ws] ⇄ res ✗ status 0ms errorCode=INVALID_REQUEST errorMessage=missing scope: operator.read
[ws] ⇄ res ✗ system-presence 0ms errorCode=INVALID_REQUEST errorMessage=missing scope: operator.read
[ws] ⇄ res ✗ config.get 0ms errorCode=INVALID_REQUEST errorMessage=missing scope: operator.read
And fresh browser/device re-pair attempts still auto-approve with the wrong scope set.
## Troubleshooting already attempted
The following were all tried and did **not** fix the issue:
1. Clearing browser site data for `127.0.0.1:18789`
2. Closing/reopening dashboard tabs
3. Using fresh tokenized dashboard URLs
4. Removing and re-pairing the Control UI device
5. Rotating the Control UI device token to include read/write
6. Restarting the gateway after token rotation
7. Full OpenClaw reinstall via `pnpm add -g [email protected]`
After reinstall, the issue persisted unchanged.
## Why this appears to be a bug/regression
Recent OpenClaw changelog entries suggest the Control UI / operator scope path is intended to include read/write behavior for Control UI clients, and there have been multiple recent fixes in this area around:
- Control UI auth / bypass behavior
- requested operator scope preservation
- default operator connect scope bundles across CLI / Control UI / macOS clients
In this case, the behavior still appears wrong specifically for `openclaw-control-ui` on loopback.
## Impact
- Discord and CLI continue to work
- Gateway itself is healthy
- But the **local dashboard is effectively unusable** for normal status/config/presence operations
## Request
Please investigate the Control UI pairing/default-scope path for loopback/local dashboard connections on `2026.3.13`, especially why `openclaw-control-ui` is being auto-approved without `operator.read` / `operator.write` while the local CLI gets the expected scope bundle.Impact and severity
No response
Additional information
No response