[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`

### 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.admin`
- `operator.approvals`
- `operator.pairing`

It is **not** granted:

- `operator.read`
- `operator.write`

As a result, the dashboard immediately fails on normal read-path RPCs such as:

- `status`
- `system-presence`
- `config.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: `pnpm` global 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)

```json
{
  "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

1. Install/configure OpenClaw locally on macOS with:
   - `gateway.mode: "local"`
   - `gateway.bind: "loopback"`
   - `gateway.auth.mode: "token"`
2. Start the gateway normally.
3. Open the Control UI on:
   - `http://127.0.0.1:18789/`
   - or use `openclaw dashboard --no-open` and open the generated tokenized URL.
4. Let the Control UI auto-pair on loopback.
5. 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.read`
- `operator.write`

So that the dashboard can successfully call:

- `status`
- `system-presence`
- `config.get`
- other standard Control UI read/write methods

### Actual behavior

# Actual behavior

The Control UI device is auto-paired with only:

- `operator.admin`
- `operator.approvals`
- `operator.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

```shell
## 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 openclaw@2026.3.13`

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_

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

[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

Bug type

Summary

Relevant config (redacted)

Steps to reproduce

Reproduction steps

Expected behavior

Expected behavior

Actual behavior

Actual behavior

OpenClaw version

Operating system

Install method

Model

Provider / routing chain

Config file / key location

Additional provider/model setup details

Logs, screenshots, and evidence

Impact and severity

Additional information

Metadata

Assignees

Labels

Type

Fields

Projects

Milestone

Relationships

Development

Uh oh!

[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

Summary

Relevant config (redacted)

Steps to reproduce

Reproduction steps

Expected behavior

Expected behavior

Actual behavior

Actual behavior

OpenClaw version

Operating system

Install method

Model

Provider / routing chain

Config file / key location

Additional provider/model setup details

Logs, screenshots, and evidence

Impact and severity

Additional information

Metadata

Metadata

Assignees

Labels

Type

Fields

Projects

Milestone

Relationships

Development

Issue actions

[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