openclaw devices
デバイスのpairingリクエストと、デバイス単位のトークンを管理します。
コマンド
openclaw devices list
保留中のpairingリクエストと、pairing済みデバイスを一覧表示します。
openclaw devices remove <deviceId>
pairing済みデバイスのエントリーを1つ削除します。
pairing済みデバイストークンで認証されている場合、adminでない呼び出し元は自分自身のデバイスエントリーのみ削除できます。他のデバイスを削除するにはoperator.adminが必要です。
openclaw devices clear --yes [--pending]
pairing済みデバイスを一括削除します。
openclaw devices approve [requestId] [--latest]
保留中のデバイスpairingリクエストを承認します。requestIdを省略した場合、OpenClawは最新の保留中リクエストを自動承認します。
注記: デバイスが変更された認証詳細（role/scopes/public key）でpairingを再試行すると、OpenClawは以前の保留中エントリーを置き換え、新しいrequestIdを発行します。現在のIDを使うため、承認直前にopenclaw devices listを実行してください。
openclaw devices reject <requestId>
保留中のデバイスpairingリクエストを拒否します。
openclaw devices rotate --device <id> --role <role> [--scope <scope...>]
特定のroleに対するデバイストークンをローテーションします（必要に応じてscopesも更新します）。
対象roleは、そのデバイスの承認済みpairing契約内にすでに存在している必要があります。ローテーションで新しい未承認roleを発行することはできません。
--scopeを省略すると、保存済みのローテーション後トークンで後から再接続した際に、そのトークンのキャッシュ済み承認scopesが再利用されます。明示的な--scope値を渡した場合、それらが今後のキャッシュ済みトークン再接続用の保存scopeセットになります。
adminでないpairing済みデバイスの呼び出し元は、自分自身のデバイストークンのみローテーションできます。また、明示的な--scope値はすべて、呼び出し元セッション自身のoperator scopes内に収まっている必要があります。ローテーションによって、呼び出し元がすでに持っているより広いoperatorトークンを発行することはできません。
openclaw devices revoke --device <id> --role <role>
特定のroleに対するデバイストークンを失効します。
adminでないpairing済みデバイスの呼び出し元は、自分自身のデバイストークンのみ失効できます。他のデバイスのトークンを失効するにはoperator.adminが必要です。
共通オプション
--url <url>: Gateway WebSocket URL（設定されている場合はデフォルトでgateway.remote.url）。--token <token>: Gatewayトークン（必要な場合）。--password <password>: Gatewayパスワード（パスワード認証）。--timeout <ms>: RPCタイムアウト。--json: JSON出力（スクリプト向けに推奨）。
--urlを設定した場合、CLIはconfigや環境の認証情報にはフォールバックしません。
--tokenまたは--passwordを明示的に渡してください。明示的な認証情報がない場合はエラーになります。
注記
- トークンローテーションは新しいトークンを返します（機微情報）。シークレットとして扱ってください。
- これらのコマンドには
operator.pairing（またはoperator.admin）scopeが必要です。 - トークンローテーションは、そのデバイスに対して承認されたpairing roleセットと承認済みscopeベースラインの範囲内にとどまります。迷い込んだキャッシュ済みトークンエントリーが新しいローテーション対象を付与することはありません。
- pairing済みデバイストークンセッションでは、デバイス横断の管理はadmin専用です。
remove、rotate、revokeは、呼び出し元にoperator.adminがない限り自分自身にのみ許可されます。 devices clearは意図的に--yesでゲートされています。- local loopbackでpairing scopeが利用できない場合（かつ明示的な
--urlが渡されていない場合）、list/approveはローカルpairingフォールバックを使用できます。 devices approveは、requestIdを省略した場合または--latestを渡した場合に、最新の保留中リクエストを自動選択します。
トークンドリフト回復チェックリスト
Control UIや他のクライアントがAUTH_TOKEN_MISMATCHまたはAUTH_DEVICE_TOKEN_MISMATCHで失敗し続ける場合に使用してください。
- 現在のGatewayトークンソースを確認します。
- pairing済みデバイスを一覧表示し、影響を受けているdevice idを特定します。
- 影響を受けているデバイスのoperatorトークンをローテーションします。
- ローテーションだけでは不十分な場合は、古いpairingを削除して再承認します。
- 現在の共有トークン/パスワードでクライアント接続を再試行します。
- 通常の再接続認証の優先順位は、明示的な共有トークン/パスワード、次に明示的な
deviceToken、次に保存済みデバイストークン、最後にブートストラップトークンです。 - 信頼済みの
AUTH_TOKEN_MISMATCH回復では、1回に限った制限付き再試行のために、共有トークンと保存済みデバイストークンの両方を一時的に一緒に送信できます。