chore(sync): mirror docs from openclaw/openclaw@d63671fce0

This commit is contained in:
openclaw-docs-sync[bot] 2026-04-20 07:38:53 +00:00
parent ab75b1d6c6
commit 608538cb8c
4 changed files with 22 additions and 4 deletions

View File

@ -1,5 +1,5 @@
{
"repository": "openclaw/openclaw",
"sha": "a89c1baddc20b6632700b7e174f92d93d61a8e1b",
"syncedAt": "2026-04-20T07:03:50.625Z"
"sha": "d63671fce0ce60a87fdf073b2d7a47ac4f9e04ef",
"syncedAt": "2026-04-20T07:38:53.028Z"
}

View File

@ -100,6 +100,12 @@ If the same device retries with different auth details (for example different
role/scopes/public key), the previous pending request is superseded and a new
`requestId` is created.
Important: an already paired device does not get broader access silently. If it
reconnects asking for more scopes or a broader role, OpenClaw keeps the
existing approval as-is and creates a fresh pending upgrade request. Use
`openclaw devices list` to compare the currently approved access with the newly
requested access before you approve.
### Node pairing state storage
Stored under `~/.openclaw/devices/`:

View File

@ -21,8 +21,9 @@ openclaw devices list
openclaw devices list --json
```
Pending request output includes the requested role and scopes so approvals can
be reviewed before you approve.
Pending request output shows the requested access next to the device's current
approved access when the device is already paired. This makes scope/role
upgrades explicit instead of looking like the pairing was lost.
### `openclaw devices remove <deviceId>`
@ -59,6 +60,12 @@ key), OpenClaw supersedes the previous pending entry and issues a new
`requestId`. Run `openclaw devices list` right before approval to use the
current ID.
If the device is already paired and asks for broader scopes or a broader role,
OpenClaw keeps the existing approval in place and creates a new pending upgrade
request. Review the `Requested` vs `Approved` columns in `openclaw devices list`
or use `openclaw devices approve --latest` to preview the exact upgrade before
approving it.
```
openclaw devices approve
openclaw devices approve <requestId>

View File

@ -58,6 +58,11 @@ If the browser retries pairing with changed auth details (role/scopes/public
key), the previous pending request is superseded and a new `requestId` is
created. Re-run `openclaw devices list` before approval.
If the browser is already paired and you change it from read access to
write/admin access, this is treated as an approval upgrade, not a silent
reconnect. OpenClaw keeps the old approval active, blocks the broader reconnect,
and asks you to approve the new scope set explicitly.
Once approved, the device is remembered and won't require re-approval unless
you revoke it with `openclaw devices revoke --device <id> --role <role>`. See
[Devices CLI](/cli/devices) for token rotation and revocation.