Bug report: Control UI re-pairs without operator.read/operator.write, and openclaw devices list closes the connection on local loopback

Summary

On OpenClaw 2026.3.13, two related issues appear during local Gateway/operator auth on a single-machine install:

1. The Control UI / webchat client (clientId: openclaw-control-ui, clientMode: webchat) consistently re-pairs with only:

   • operator.admin
   • operator.approvals
   • operator.pairing

   It does not request or receive:

   • operator.read
   • operator.write

2. The local CLI can connect to the Gateway on loopback, but operator RPCs are broken:

   • openclaw gateway probe connects but reports missing scope: operator.read
   • openclaw devices list fails with WebSocket close 1000 / no close reason

This persisted even after:

• repairing device state on disk
• restarting the gateway
• hard-resetting the Control UI/browser identity
• rotating the gateway auth token

Environment

• OpenClaw version: 2026.3.13 (61d171a)
• Host: Jetson Orin Nano
• OS: Ubuntu 22.04.5 / JetPack 6.2.2
• Gateway service: openclaw-gateway.service via systemd user service
• Gateway bind: loopback
• Tailscale: enabled, Serve mode active
• Tailscale MagicDNS: machinespirit.tail8da86f.ts.net

Expected behavior

Control UI

When the Control UI/webchat client pairs as an operator on a trusted single-user machine, it should either:

• request the normal read/write operator scopes it needs, or
• function correctly with whatever reduced scope set it requests.

At minimum, if it lacks operator.read, the resulting UX should not leave the local system in a broken/contradictory state.

CLI

The local CLI should be able to:

• reuse its paired local device identity/token on loopback
• complete openclaw devices list
• complete openclaw gateway probe without degrading to missing scope: operator.read

Actual behavior

A) Control UI always re-pairs with reduced scopes

After clearing paired/pending state for the UI device and resetting browser storage, the newly paired Control UI came back with:

• operator.admin
• operator.approvals
• operator.pairing

and still missing:

• operator.read
• operator.write

This suggests the UI/client pairing request path itself is requesting the reduced scope set again, rather than stale state causing the issue.

B) CLI local device state looks correct on disk, but runtime behavior does not

The local CLI device state shows full operator scopes on disk:

• operator.read
• operator.write
• operator.admin
• operator.approvals
• operator.pairing

However, runtime behavior still acts as if the CLI is not successfully using that paired device identity/token.

Reproduction

1) Observe CLI degradation on loopback

openclaw gateway probe
openclaw devices list

Observed:

• gateway probe:
  • Reachable: yes
  • RPC: limited - missing scope: operator.read
• devices list:
  • Gateway closes socket with code 1000 normal closure
  • no close reason surfaced

2) Inspect paired device state

Paired devices on disk showed:

• CLI device (clientId: cli) had full scopes
• Control UI (clientId: openclaw-control-ui) had only admin/approvals/pairing

3) Patch UI device scopes on disk + restart gateway

Manually patched the Control UI device in ~/.openclaw/devices/paired.json to add:

• operator.read
• operator.write

Also removed stale pending request from ~/.openclaw/devices/pending.json and restarted the gateway.

Result:

• on-disk state updated successfully
• runtime CLI behavior remained broken

4) Hard reset the UI/browser identity

• removed the paired Control UI device from paired.json
• cleared pending UI requests
• restarted gateway
• cleared browser site data / reopened UI

Result:

• Control UI re-paired successfully
• but again requested/received only:
  • operator.admin
  • operator.approvals
  • operator.pairing

Relevant observed output

openclaw gateway probe

Gateway Status
Reachable: yes
Probe budget: 3000ms

Warning:
- Probe diagnostics are limited by gateway scopes (missing operator.read). Connection succeeded, but status details may be incomplete. Hint: pair device identity or use credentials with operator.read.

Discovery (this machine)
Found 2 gateway(s) via Bonjour (local.)

Targets
Local loopback ws://127.0.0.1:18789
 Connect: ok (27ms) · RPC: limited - missing scope: operator.read

openclaw devices list

gateway connect failed: Error: gateway closed (1000):
[openclaw] Failed to start CLI: Error: gateway closed (1000 normal closure): no close reason
Gateway target: ws://127.0.0.1:18789
Source: local loopback
Config: /home/elvis/.openclaw/openclaw.json
Bind: loopback

Discovery JSON showed duplicate Bonjour beacons, not multiple gateway processes

openclaw gateway probe --json showed:

• one actual active target: localLoopback
• two identical Bonjour beacons with the same host/port/wsUrl

This appears cosmetic and unrelated, but was observed during debugging.

Device state after UI hard reset

Paired CLI device

• clientId: cli
• clientMode: cli
• scopes:
  • operator.read
  • operator.write
  • operator.admin
  • operator.approvals
  • operator.pairing

Paired Control UI device (fresh after reset)

• clientId: openclaw-control-ui
• clientMode: webchat
• scopes:
  • operator.admin
  • operator.approvals
  • operator.pairing

Pending requests

• none

Why this looks like a product bug

• The UI reset did not restore normal scopes; it reproduced the same reduced scope request.
• The CLI device auth on disk appears correct, but the runtime still falls back to a degraded scope view or closes the socket during devices list.
• Supplying the real gateway auth token explicitly changed behavior (it avoided token-mismatch), but devices list still closed normally with no reason.

This suggests one or both of:

• the Control UI/webchat client is requesting the wrong operator scope set during pairing
• the local CLI loopback/device-auth path is not consistently reusing its paired device token/identity for operator RPCs

Impact

• local operator management becomes unreliable
• device approval/listing cannot be trusted from CLI on the affected install
• UI/webchat does not gain expected operator read/write capabilities even after reset
• debugging node pairing/Tailscale issues is much harder because operator tooling is degraded

Suggested areas to inspect

• Control UI/webchat pairing request scope generation
• local CLI auth path on loopback when paired device identity exists in ~/.openclaw/identity/device-auth.json
• scope handling / downgrade behavior in gateway probe
• why devices list closes the socket with code 1000 and no surfaced reason instead of returning a structured auth/scope error

Notes

• Any pasted/shared secrets used during troubleshooting were rotated afterward and are intentionally omitted from this report.