#Openclaw devices needs pairing

12 messages · Page 1 of 1 (latest)

astral laurel
#

Whenever i run openclaw devices list I see the commands own pairing request. When i try to approve that requests it says its an unknown request iD. Then whenever i rerun the openclaw devices list i see another ID. I presume its happening because every time I run the devices list it sends a new pairing request causing it to cycle and so I cant approve its request.

tulip reefBOT
#

To help others find answers, you can mark your question as solved via Right click solution message -> Apps -> ✅ Mark Solution

scenic parrotBOT
rancid galleonBOT
#

That sounds like a scope-upgrade pairing loop.

openclaw devices list is not supposed to create a random extra request, but it can trigger a pairing request for the CLI device itself if that CLI session is not already approved for operator.pairing. When that client reconnects with changed auth details or requested scopes, the old pending request gets superseded, so approving the old ID returns unknown requestId.

A couple quick checks:

  1. Please paste:

    openclaw --version

  2. Are you running this:

    • on the same machine as the gateway, or
    • against a remote gateway with --url?

  3. Please paste:

# 
   openclaw devices list --json

I want to see the pending entry's role and scopes.

Most likely fixes:

  • If you are on the gateway machine: run it without --url. Local loopback can use the local pairing fallback.
  • If you are remote: use your existing gateway auth (--token or --password) so the CLI does not just pair itself and loop.

Also, if the pending request shows the CLI asking for operator.pairing, that confirms it.

Docs:

If you paste the version + devices list --json, I can tell you the exact next command.

astral laurel
#

had to delete some stuff cuz of discord

gateway connect failed: GatewayClientRequestError: pairing required
"pending": [
"requestId": "db130431-ccd4-4387-a21d-41cd5320acf6",
"deviceId": "dc8e7441a268a7183e8767503bf1a382a0199d2f555454d0d7bcd67a32f20754",
"publicKey": "3yW3SnZT_ypOTcrWLowe1YFziuJicj3eeN3orVgIvsg",
"platform": "linux",
"clientId": "cli",
"clientMode": "cli",
"role": "operator",
"roles": [
"operator"
"scopes": [
"operator.approvals",
"operator.admin",
"operator.read",
"operator.write",
"operator.pairing",
"operator.talk.secrets"
],
"silent": false,
"isRepair": true,
"ts": 1776079240167
}
],
"paired": [
{
"deviceId": "a7d4e6036e2b716de101f3589620434cc492742e85b35c39ff35b2ebbf7483c1",
"publicKey": "K3ZRC2mXU0qHEdKrOuI92cjxPoMZq4f76a2XGBt7e2M",
"platform": "Win32",

  ],
  "createdAtMs": 1776076941752,
  "approvedAtMs": 1776076941752,
  "tokens": [
    {
      "role": "operator",
      "scopes": [
        "operator.admin",

      ],
      "createdAtMs": 1776076941752
    }
  ]
},
{
  "deviceId": "dc8e7441a268a7183e8767503bf1a382a0199d2f555454d0d7bcd67a32f20754",
  "publicKey": "3yW3SnZT_ypOTcrWLowe1YFziuJicj3eeN3orVgIvsg",
  "platform": "linux",
  "clientId": "cli",
  "clientMode": "probe",
  "role": "operator",
  "roles": [
    "operator"
  ],
  "scopes": [
    "operator.read"
  ],
  "approvedScopes": [
    "operator.read"
  ],
  "createdAtMs": 1776076450208,
  "approvedAtMs": 1776076450208,
  "tokens": [
    {
      "role": "operator",
      "scopes": [
        "operator.read"
      ],
      "createdAtMs": 1776076450208
    }
  ]
}

]
}

fhorst@openclaw:~$ openclaw --version
OpenClaw 2026.4.11 (769908e)
fhorst@openclaw:~$

rancid galleonBOT
#

Yep, your paste confirms it.

Your Linux CLI device dc8e... is already paired, but only for:

  • clientMode: "probe"
  • approvedScopes: ["operator.read"]

Then the real CLI run asks for full operator scopes:

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

So this is a repair / scope-upgrade request for the same device (isRepair: true), not a totally new device.

#

Best fix

Approve that Linux request from your already-approved Windows admin device, not from the Linux CLI that is requesting the upgrade.

On the Windows machine, run:

openclaw devices list
openclaw devices approve <fresh requestId for device dc8e...>

You already have a paired Windows device with operator.admin, so that one should be able to approve the Linux CLI cleanly.

Also important

If you are running this on the gateway box itself, do not pass --url.
The local fallback for devices list / devices approve only kicks in when you run it locally without an explicit remote URL.

#

Why the ID keeps changing

Because you're retrying the same device repair flow, and the older pending request can get superseded, so approving the previous ID returns unknown requestId.

Your version looks fine too:

OpenClaw 2026.4.11

If you want, paste the fresh devices list output from the Windows/admin box and I’ll point to the exact line to approve.

astral laurel
#

its a paired browser, can i approve it from there?

rancid galleonBOT
#

Yes, if that browser session is already paired with enough operator access.

In practice:

  • paired browser with operator.pairing or operator.admin → yes
  • read-only paired browser → no

So if your browser is a fully paired Control UI session, that’s actually a good place to approve the Linux CLI repair request for dc8e....

What to look for:

  • the pending device pairing / repair request
  • device id dc8e...
  • role operator
  • scopes including operator.pairing, operator.admin, etc.

Approve the current pending request there, then retry the Linux CLI command.