From 608538cb8cd8768ae6f2610efcc720b1eb737300 Mon Sep 17 00:00:00 2001 From: "openclaw-docs-sync[bot]" Date: Mon, 20 Apr 2026 07:38:53 +0000 Subject: [PATCH] chore(sync): mirror docs from openclaw/openclaw@d63671fce0ce60a87fdf073b2d7a47ac4f9e04ef --- .openclaw-sync/source.json | 4 ++-- docs/channels/pairing.md | 6 ++++++ docs/cli/devices.md | 11 +++++++++-- docs/web/control-ui.md | 5 +++++ 4 files changed, 22 insertions(+), 4 deletions(-) diff --git a/.openclaw-sync/source.json b/.openclaw-sync/source.json index cbab82b00..e6d518a52 100644 --- a/.openclaw-sync/source.json +++ b/.openclaw-sync/source.json @@ -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" } diff --git a/docs/channels/pairing.md b/docs/channels/pairing.md index dd768686d..2ea8b0fae 100644 --- a/docs/channels/pairing.md +++ b/docs/channels/pairing.md @@ -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/`: diff --git a/docs/cli/devices.md b/docs/cli/devices.md index f2387f047..83d295c7b 100644 --- a/docs/cli/devices.md +++ b/docs/cli/devices.md @@ -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 ` @@ -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 diff --git a/docs/web/control-ui.md b/docs/web/control-ui.md index 5ce85d95b..dd9c29238 100644 --- a/docs/web/control-ui.md +++ b/docs/web/control-ui.md @@ -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 --role `. See [Devices CLI](/cli/devices) for token rotation and revocation.