Description

The Control UI (webchat) crashes and becomes unresponsive after a WebSocket reconnect. The gateway logs show repeated missing scope: operator.read errors when the frontend attempts to call config.get and other operator-level APIs.

Steps to Reproduce

1. Open the Control UI dashboard via openclaw dashboard
2. Have an active session with multiple tool calls (browser operations, sub-agent spawns, etc.)
3. The WebSocket connection drops or the page is refreshed
4. The page becomes unresponsive — the chat input cannot be selected, and eventually a "Page Unresponsive" dialog appears

Expected Behavior

The Control UI should either:

• Include operator.read scope in the dashboard token automatically, or
• Gracefully degrade when operator-level APIs return permission errors (instead of entering a retry loop that freezes the page)

Actual Behavior

The frontend repeatedly retries config.get requests that fail with missing scope: operator.read, eventually causing the page to freeze.

Logs

⇄ res ✗ config.get 0ms errorCode=INVALID_REQUEST errorMessage=missing scope: operator.read conn=d19179af…05ce
webchat connected conn=92eae5c4... remote=127.0.0.1 client=openclaw-control-ui webchat v2026.3.13
webchat disconnected code=1001 reason=n/a conn=def4fe61...

Environment

• OpenClaw v2026.3.13 (61d171a)
• macOS 15.7.5 (arm64)
• Node v22.19.0
• Gateway mode: local, bind: loopback
• Auth mode: token
• Browser: Chrome (latest)