openclaw - 💡(How to fix) Fix [Bug]: GatewayClientRequestError: missing scope: operator.read [1 comments, 2 participants]

 This appears to block first-time local/Docker bootstrapping: the CLI needs operator.read to approve a request that would grant operator.read, but there’s no obvious way for the local CLI to obtain that
 scope first.

 1. Run OpenClaw in Docker.

 2. From an external client, initiate a signed device pairing request against the gateway WebSocket.

    Requested role/scopes:

    text
    role: operator
    scopes: operator.read


    Gateway returns:

    text
    errorCode: PAIRING_REQUIRED
    requestedScopes: operator.read
    pairingRequestId: <requestId>


 3. From the host, try to approve the request inside the OpenClaw container:

    bash
    docker exec -it --user node openclaw bash -lc 'openclaw devices approve <requestId>'


 4. Observe failure:

    text
    GatewayClientRequestError: missing scope: operator.read


 5. Try again while forcing loopback gateway URL inside the container:

    bash
    docker exec -it --user node openclaw bash -lc 'OPENCLAW_GATEWAY_URL=http://127.0.0.1:18789 openclaw devices approve <requestId>'


 6. Observe the same failure:

    text
    GatewayClientRequestError: missing scope: operator.read


 Optional extra check:

 7. Repeat with a broader requested scope set:

    text
    operator.admin,operator.read,operator.write,operator.approvals,operator.pairing


    Approval similarly fails, e.g.:

    text
    GatewayClientRequestError: missing scope: operator.admin

 For a minimal first-time request like:

 text
 role: operator
 scopes: operator.read

 one of these should happen:

 1. openclaw devices approve <requestId> succeeds from a local trusted CLI context; or

 2. the local pairing fallback grants enough authority to approve the first operator.read request; or

 3. the CLI prints a clear remediation explaining the correct bootstrap command/config/token needed to create the first operator-scoped approval.

 It should not deadlock where approving operator.read requires the approving CLI to already have operator.read, with no documented bootstrap path.

 For a minimal request:

 text
 role: operator
 scopes: operator.read

 the gateway returns a valid pending request:

 text
 errorCode: PAIRING_REQUIRED
 message: pairing required: device is not approved yet
 pairingRequestId: <requestId>
 requestedScopes: operator.read

 Then approval from inside the Docker container fails:

 bash
 docker exec -it --user node openclaw bash -lc 'openclaw devices approve <requestId>'

 Output:

 text
 GatewayClientRequestError: missing scope: operator.read

 Forcing loopback inside the container also fails:

 bash
 docker exec -it --user node openclaw bash -lc 'OPENCLAW_GATEWAY_URL=http://127.0.0.1:18789 openclaw devices approve <requestId>'

 Output:

 text
 GatewayClientRequestError: missing scope: operator.read

 A broader request including operator.admin fails similarly with:

 text
 GatewayClientRequestError: missing scope: operator.admin

 So the CLI appears able to reach the pairing approval method, but cannot mint even operator.read unless it already has operator.read.

~/openclaw/data/.openclaw/devices$ docker exec -it --user node openclaw bash -lc 'OPENCLAW_GATEWAY_URL=http://127.0.0.1:18789 openclaw devices approve 7233fa9f-f021-4bca-a233-788d27dd3dcb'

🦞 OpenClaw 2026.5.2 (unknown) — I can't fix your code taste, but I can fix your build and your backlog.

│
◇
[openclaw] Failed to start CLI: GatewayClientRequestError: missing scope: operator.read
    at GatewayClient.handleMessage (file:///app/dist/client-D-i9iMPZ.js:663:25)
    at WebSocket.<anonymous> (file:///app/dist/client-D-i9iMPZ.js:314:35)
    at WebSocket.emit (node:events:508:28)
    at Receiver.receiverOnMessage (/app/node_modules/ws/lib/websocket.js:1225:20)
    at Receiver.emit (node:events:508:28)
    at Receiver.dataMessage (/app/node_modules/ws/lib/receiver.js:596:14)
    at Receiver.getData (/app/node_modules/ws/lib/receiver.js:496:10)
    at Receiver.startLoop (/app/node_modules/ws/lib/receiver.js:167:16)
    at Receiver._write (/app/node_modules/ws/lib/receiver.js:94:10)
    at writeOrBuffer (node:internal/streams/writable:570:12)

 This appears to block first-time or recovery bootstrapping of OpenClaw operator device access in a Docker deployment.

 A new operator device can create a valid pending pairing request, but the local Docker CLI cannot approve it unless the CLI already has the same operator scope the request is trying to grant. For a
 fresh setup or token-drift recovery case, this can deadlock the user out of approving even minimal read-only operator access.

 Affected operations:

 text
 openclaw devices approve <requestId>
 operator device pairing
 operator.read bootstrap
 operator.admin bootstrap / upgrade
 Hermes/OpenClaw gateway integration

 User-visible result:

 text
 GatewayClientRequestError: missing scope: operator.read

 Severity:

 text
 Medium to High

 Why:

 - Not a data-loss issue.
 - Not obviously a security bypass.
 - But it blocks normal local/admin bootstrapping and recovery.
 - It may prevent users from pairing Control UI / Hermes / other operator clients in Docker unless they already have a valid operator-scoped session.
 - The error does not clearly explain the bootstrap path.

 Devices CLI docs say:

 text
 If pairing scope is unavailable on local loopback (and no explicit --url is passed), list/approve can use a local pairing fallback.

 Operator scopes docs say:

 text
 device.pair.approve is reachable with operator.pairing, but approving an operator device can only mint or preserve scopes the caller already holds.

 Observed behavior matches the second rule but seems to leave no clear first-device bootstrap path in Docker.

 The request was intentionally reduced to the minimal useful scope:

 text
 operator.read

 to avoid requiring admin approval, but approval still failed with:

 text
 missing scope: operator.read

 The same device identity was reused across attempts:

 text
 deviceId: 76dbed3c1d94418f0d515c55d89e49ee9283c16223e9c1c210bf91fd3f546a05

 The request ID may rotate if the client retries pairing, so openclaw devices list should be run immediately before approval. However, in the successful “fresh request, immediate approve” attempts, the
 failure was not unknown requestId; it was:

 text
 missing scope: operator.read

 This suggests the request was current and reachable, but approval was blocked by scope containment.