---
read_when:
    - Ви схвалюєте запити на сполучення пристроїв
    - Потрібно ротувати або відкликати токени пристроїв
summary: Довідка CLI для `openclaw devices` (сполучення пристроїв + ротація/відкликання токенів)
title: Пристрої
x-i18n:
    generated_at: "2026-05-03T00:42:59Z"
    model: gpt-5.5
    provider: openai
    source_hash: fa92fd3ffc671c827fa98870bf9df89f3be90adec167fd8ea32698cf2e69991a
    source_path: cli/devices.md
    workflow: 16
---

# `openclaw devices`

Керуйте запитами на спарювання пристроїв і токенами в межах пристрою.

## Команди

### `openclaw devices list`

Вивести список запитів на спарювання, що очікують, і спарованих пристроїв.

```
openclaw devices list
openclaw devices list --json
```

Вивід запиту, що очікує, показує запитаний доступ поруч із поточним
схваленим доступом пристрою, якщо пристрій уже спаровано. Це робить підвищення
області доступу/ролі явним, а не таким, що виглядає як втрачання спарювання.

### `openclaw devices remove <deviceId>`

Видалити один запис спарованого пристрою.

Коли ви автентифіковані за допомогою токена спарованого пристрою, викликачі без
прав адміністратора можуть видаляти лише запис **свого власного** пристрою.
Видалення іншого пристрою потребує `operator.admin`.

```
openclaw devices remove <deviceId>
openclaw devices remove <deviceId> --json
```

### `openclaw devices clear --yes [--pending]`

Масово очистити спаровані пристрої.

```
openclaw devices clear --yes
openclaw devices clear --yes --pending
openclaw devices clear --yes --pending --json
```

### `openclaw devices approve [requestId] [--latest]`

Схвалити запит на спарювання пристрою, що очікує, за точним `requestId`. Якщо
`requestId` пропущено або передано `--latest`, OpenClaw лише виводить вибраний
запит, що очікує, і завершує роботу; повторно запустіть схвалення з точним ID
запиту після перевірки деталей.

<Note>
Якщо пристрій повторює спробу спарювання зі зміненими деталями автентифікації (роллю, областями доступу або публічним ключем), OpenClaw замінює попередній запис, що очікує, і видає новий `requestId`. Запустіть `openclaw devices list` безпосередньо перед схваленням, щоб використати поточний ID.
</Note>

Якщо пристрій уже спаровано і він запитує ширші області доступу або ширшу роль,
OpenClaw зберігає наявне схвалення та створює новий запит на підвищення, що
очікує. Перегляньте стовпці `Requested` і `Approved` в `openclaw devices list`
або скористайтеся `openclaw devices approve --latest`, щоб попередньо переглянути
точне підвищення перед його схваленням.

Якщо Gateway явно налаштовано з
`gateway.nodes.pairing.autoApproveCidrs`, перші запити `role: node` від
відповідних IP-адрес клієнтів можуть бути схвалені до того, як з’являться в
цьому списку. Цю політику вимкнено за замовчуванням, і вона ніколи не
застосовується до клієнтів оператора/браузера або запитів на підвищення.

```
openclaw devices approve
openclaw devices approve <requestId>
openclaw devices approve --latest
```

### `openclaw devices reject <requestId>`

Відхилити запит на спарювання пристрою, що очікує.

```
openclaw devices reject <requestId>
```

### `openclaw devices rotate --device <id> --role <role> [--scope <scope...>]`

Ротувати токен пристрою для певної ролі (за потреби оновлюючи області доступу).
Цільова роль уже має існувати в схваленому контракті спарювання цього пристрою;
ротація не може створити нову несхвалену роль.
Якщо ви пропустите `--scope`, пізніші повторні підключення зі збереженим
ротованим токеном повторно використовуватимуть кешовані схвалені області доступу
цього токена. Якщо передати явні значення `--scope`, вони стануть збереженим
набором областей доступу для майбутніх повторних підключень із кешованим токеном.
Викликачі зі спарованим пристроєм без прав адміністратора можуть ротувати лише
токен **свого власного** пристрою.
Цільовий набір областей доступу токена має залишатися в межах власних
операторських областей доступу сеансу викликача; ротація не може створити або
зберегти ширший операторський токен, ніж уже має викликач.

```
openclaw devices rotate --device <deviceId> --role operator --scope operator.read --scope operator.write
```

Повертає метадані ротації у форматі JSON. Якщо викликач ротує власний токен,
будучи автентифікованим цим токеном пристрою, відповідь також містить замінний
токен, щоб клієнт міг зберегти його перед повторним підключенням. Спільні або
адміністративні ротації не повертають bearer-токен.

### `openclaw devices revoke --device <id> --role <role>`

Відкликати токен пристрою для певної ролі.

Викликачі зі спарованим пристроєм без прав адміністратора можуть відкликати лише
токен **свого власного** пристрою. Відкликання токена іншого пристрою потребує
`operator.admin`.
Цільовий набір областей доступу токена також має вкладатися у власні
операторські області доступу сеансу викликача; викликачі лише зі спарюванням не
можуть відкликати адміністративні або записувальні операторські токени.

```
openclaw devices revoke --device <deviceId> --role node
```

Повертає результат відкликання у форматі JSON.

## Поширені параметри

- `--url <url>`: URL WebSocket для Gateway (за замовчуванням `gateway.remote.url`, якщо налаштовано).
- `--token <token>`: токен Gateway (якщо потрібен).
- `--password <password>`: пароль Gateway (автентифікація паролем).
- `--timeout <ms>`: тайм-аут RPC.
- `--json`: вивід JSON (рекомендовано для сценаріїв).

<Warning>
Коли ви задаєте `--url`, CLI не повертається до облікових даних із конфігурації або середовища. Передайте `--token` або `--password` явно. Відсутність явних облікових даних є помилкою.
</Warning>

## Примітки

- Ротація токена повертає новий токен (чутливий). Поводьтеся з ним як із секретом.
- Ці команди потребують області доступу `operator.pairing` (або `operator.admin`). Деякі
  схвалення також потребують, щоб викликач мав операторські області доступу, які
  цільовий пристрій створить або успадкує; див. [Операторські області доступу](/uk/gateway/operator-scopes).
- `gateway.nodes.pairing.autoApproveCidrs` — це opt-in політика Gateway лише для
  свіжого спарювання вузлових пристроїв; вона не змінює повноваження схвалення CLI.
- Ротація та відкликання токенів залишаються всередині схваленого набору ролей
  спарювання та схваленої базової лінії областей доступу для цього пристрою.
  Випадковий кешований запис токена не надає ціль для керування токенами.
- Для сеансів із токеном спарованого пристрою керування між пристроями доступне
  лише адміністратору: `remove`, `rotate` і `revoke` працюють лише для власного
  пристрою, якщо викликач не має `operator.admin`.
- Мутація токена також обмежена областями доступу викликача: сеанс лише зі
  спарюванням не може ротувати або відкликати токен, який наразі має
  `operator.admin` або `operator.write`.
- `devices clear` навмисно захищено прапорцем `--yes`.
- Якщо область доступу спарювання недоступна на local loopback (і явний `--url` не передано), list/approve можуть використати локальний резервний механізм спарювання.
- `devices approve` потребує явного ID запиту перед створенням токенів; пропущений `requestId` або переданий `--latest` лише попередньо показує найновіший запит, що очікує.

## Контрольний список відновлення після розсинхронізації токенів

Використовуйте це, коли Control UI або інші клієнти продовжують завершуватися з помилкою `AUTH_TOKEN_MISMATCH` або `AUTH_DEVICE_TOKEN_MISMATCH`.

1. Підтвердьте поточне джерело токена gateway:

```bash
openclaw config get gateway.auth.token
```

2. Виведіть список спарованих пристроїв і визначте ID ураженого пристрою:

```bash
openclaw devices list
```

3. Ротуйте операторський токен для ураженого пристрою:

```bash
openclaw devices rotate --device <deviceId> --role operator
```

4. Якщо ротації недостатньо, видаліть застаріле спарювання та схваліть знову:

```bash
openclaw devices remove <deviceId>
openclaw devices list
openclaw devices approve <requestId>
```

5. Повторіть підключення клієнта з поточним спільним токеном/паролем.

Примітки:

- Звичайний пріоритет автентифікації під час повторного підключення: спочатку явний спільний токен/пароль, потім явний `deviceToken`, потім збережений токен пристрою, потім bootstrap-токен.
- Довірене відновлення після `AUTH_TOKEN_MISMATCH` може тимчасово надіслати разом і спільний токен, і збережений токен пристрою для однієї обмеженої повторної спроби.

Пов’язано:

- [Усунення проблем з автентифікацією Dashboard](/uk/web/dashboard#if-you-see-unauthorized-1008)
- [Усунення проблем Gateway](/uk/gateway/troubleshooting#dashboard-control-ui-connectivity)

## Пов’язано

- [Довідник CLI](/uk/cli)
- [Вузли](/uk/nodes)
