---
read_when:
    - Налаштування контролю доступу до прямих повідомлень
    - Сполучення нового iOS/Android Node
    - Огляд стану безпеки OpenClaw
summary: 'Огляд сполучення: затвердьте, хто може надсилати вам особисті повідомлення + які вузли можуть приєднуватися'
title: Сполучення
x-i18n:
    generated_at: "2026-05-10T19:23:23Z"
    model: gpt-5.5
    provider: openai
    source_hash: 0e26bfd98d9de3b834b737be1aa70eb2272267b3cb9cf6d66b030629111a12fc
    source_path: channels/pairing.md
    workflow: 16
---

"Сполучення" є явним кроком OpenClaw для підтвердження доступу.
Воно використовується у двох місцях:

1. **Сполучення DM** (кому дозволено спілкуватися з ботом)
2. **Сполучення Node** (яким пристроям/Node дозволено приєднуватися до мережі Gateway)

Контекст безпеки: [Безпека](/uk/gateway/security)

## 1) Сполучення DM (вхідний доступ до чату)

Коли канал налаштовано з політикою DM `pairing`, невідомі відправники отримують короткий код, а їхнє повідомлення **не обробляється**, доки ви не надасте підтвердження.

Типові політики DM задокументовано тут: [Безпека](/uk/gateway/security)

`dmPolicy: "open"` є публічною лише тоді, коли ефективний список дозволених DM містить `"*"`.
Налаштування й перевірка потребують цього wildcard для публічно відкритих конфігурацій. Якщо наявний
стан містить `open` із конкретними записами `allowFrom`, під час виконання все одно допускаються
лише ці відправники, а підтвердження в сховищі сполучень не розширюють доступ `open`.

Коди сполучення:

- 8 символів, великі літери, без неоднозначних символів (`0O1I`).
- **Закінчуються через 1 годину**. Бот надсилає повідомлення про сполучення лише тоді, коли створюється новий запит (приблизно раз на годину для кожного відправника).
- Очікувані запити на сполучення DM типово обмежені **3 на канал**; додаткові запити ігноруються, доки один із них не закінчиться або не буде підтверджений.

### Підтвердити відправника

```bash
openclaw pairing list telegram
openclaw pairing approve telegram <CODE>
```

Якщо власника команд ще не налаштовано, підтвердження коду сполучення DM також ініціалізує
`commands.ownerAllowFrom` для підтвердженого відправника, наприклад `telegram:123456789`.
Це дає першому налаштуванню явного власника для привілейованих команд і запитів на підтвердження
exec. Після появи власника наступні підтвердження сполучення надають лише доступ DM;
вони не додають нових власників.

Підтримувані канали: `discord`, `feishu`, `googlechat`, `imessage`, `irc`, `line`, `matrix`, `mattermost`, `msteams`, `nextcloud-talk`, `nostr`, `openclaw-weixin`, `signal`, `slack`, `synology-chat`, `telegram`, `twitch`, `whatsapp`, `zalo`, `zalouser`.

### Багаторазові групи відправників

Використовуйте верхньорівневі `accessGroups`, коли той самий набір довірених відправників має застосовуватися до
кількох каналів повідомлень або одночасно до списків дозволених DM і груп.

Статичні групи використовують `type: "message.senders"` і на них посилаються через
`accessGroup:<name>` зі списків дозволених каналів:

```json5
{
  accessGroups: {
    operators: {
      type: "message.senders",
      members: {
        discord: ["discord:123456789012345678"],
        telegram: ["987654321"],
        whatsapp: ["+15551234567"],
      },
    },
  },
  channels: {
    telegram: { dmPolicy: "allowlist", allowFrom: ["accessGroup:operators"] },
    whatsapp: { groupPolicy: "allowlist", groupAllowFrom: ["accessGroup:operators"] },
  },
}
```

Групи доступу докладно задокументовано тут: [Групи доступу](/uk/channels/access-groups)

### Де зберігається стан

Зберігається в `~/.openclaw/credentials/`:

- Очікувані запити: `<channel>-pairing.json`
- Сховище підтвердженого списку дозволених:
  - Типовий обліковий запис: `<channel>-allowFrom.json`
  - Не типовий обліковий запис: `<channel>-<accountId>-allowFrom.json`

Поведінка прив’язки до облікового запису:

- Не типові облікові записи читають/записують лише свій файл списку дозволених.
- Типовий обліковий запис використовує не прив’язаний до облікового запису файл списку дозволених каналу.

Вважайте ці дані чутливими (вони контролюють доступ до вашого асистента).

<Note>
Сховище списку дозволених для сполучення призначене для доступу DM. Авторизація груп є окремою.
Підтвердження коду сполучення DM не надає цьому відправнику автоматичного дозволу виконувати групові
команди або керувати ботом у групах. Початкова ініціалізація першого власника є окремим станом конфігурації
в `commands.ownerAllowFrom`, а доставка групових чатів і надалі дотримується списків дозволених груп каналу
(наприклад `groupAllowFrom`, `groups` або перевизначень для окремих груп
чи тем, залежно від каналу).
</Note>

## 2) Сполучення пристроїв Node (iOS/Android/macOS/headless Node)

Nodes підключаються до Gateway як **пристрої** з `role: node`. Gateway
створює запит на сполучення пристрою, який потрібно підтвердити.

### Сполучення через Telegram (рекомендовано для iOS)

Якщо ви використовуєте Plugin `device-pair`, перше сполучення пристрою можна повністю виконати з Telegram:

1. У Telegram напишіть своєму боту: `/pair`
2. Бот відповідає двома повідомленнями: повідомленням з інструкціями й окремим повідомленням із **кодом налаштування** (його легко скопіювати/вставити в Telegram).
3. На телефоні відкрийте застосунок OpenClaw для iOS → Налаштування → Gateway.
4. Відскануйте QR-код або вставте код налаштування й підключіться.
5. Поверніться в Telegram: `/pair pending` (перегляньте ID запитів, роль і scopes), потім підтвердьте.

Код налаштування — це закодоване в base64 JSON-навантаження, яке містить:

- `url`: URL WebSocket Gateway (`ws://...` або `wss://...`)
- `bootstrapToken`: короткочасний bootstrap-токен для одного пристрою, який використовується для початкового handshake сполучення

Цей bootstrap-токен містить вбудований bootstrap-профіль сполучення:

- основний переданий токен `node` лишається `scopes: []`
- будь-який переданий токен `operator` лишається обмеженим bootstrap-списком дозволених:
  `operator.approvals`, `operator.read`, `operator.talk.secrets`, `operator.write`
- перевірки bootstrap scopes мають префікс ролі, а не один плаский пул scopes:
  записи scope оператора задовольняють лише запити оператора, а неоператорські ролі
  все одно мають запитувати scopes під власним префіксом ролі
- подальша ротація/відкликання токенів лишається обмеженою як підтвердженим
  контрактом ролі пристрою, так і operator scopes сеансу викликача

Ставтеся до коду налаштування як до пароля, доки він чинний.

Для Tailscale, публічного або іншого віддаленого мобільного сполучення використовуйте Tailscale Serve/Funnel
або інший URL Gateway `wss://`. Відкриті текстові коди налаштування `ws://` приймаються лише
для loopback, приватних адрес LAN, хостів Bonjour `.local` і хоста емулятора
Android. Адреси Tailnet CGNAT, імена `.ts.net` і публічні хости все одно
закриваються з помилкою до видачі QR/коду налаштування.

### Підтвердити пристрій Node

```bash
openclaw devices list
openclaw devices approve <requestId>
openclaw devices reject <requestId>
```

Коли явне підтвердження відхилено, бо сеанс сполученого пристрою, який підтверджує,
було відкрито лише зі scope сполучення, CLI повторює той самий запит із
`operator.admin`. Це дає наявному сполученому пристрою з можливостями адміністратора змогу відновити нове
сполучення Control UI/браузера без ручного редагування `devices/paired.json`. Gateway
все одно перевіряє повторне підключення; токени, які не можуть автентифікуватися
з `operator.admin`, залишаються заблокованими.

Якщо той самий пристрій повторює спробу з іншими даними автентифікації (наприклад іншими
role/scopes/public key), попередній очікуваний запит замінюється, і створюється новий
`requestId`.

<Note>
Уже сполучений пристрій не отримує ширшого доступу непомітно. Якщо він перепідключається із запитом на більше scopes або ширшу роль, OpenClaw зберігає наявне підтвердження без змін і створює новий очікуваний запит на підвищення доступу. Використовуйте `openclaw devices list`, щоб порівняти поточний підтверджений доступ із новим запитаним доступом перед підтвердженням.
</Note>

### Необов’язкове автоматичне підтвердження Node за довіреними CIDR

За замовчуванням сполучення пристроїв лишається ручним. Для суворо контрольованих мереж Node
можна явно ввімкнути автоматичне підтвердження першого сполучення Node за CIDR або точними IP:

```json5
{
  gateway: {
    nodes: {
      pairing: {
        autoApproveCidrs: ["192.168.1.0/24"],
      },
    },
  },
}
```

Це застосовується лише до нових запитів на сполучення `role: node` без запитаних
scopes. Клієнти Operator, браузера, Control UI та WebChat все одно потребують ручного
підтвердження. Зміни ролі, scope, metadata і public-key також потребують ручного
підтвердження.

### Зберігання стану сполучення Node

Зберігається в `~/.openclaw/devices/`:

- `pending.json` (короткочасний; очікувані запити закінчуються)
- `paired.json` (сполучені пристрої + токени)

### Примітки

- Застарілий API `node.pair.*` (CLI: `openclaw nodes pending|approve|reject|remove|rename`) є
  окремим сховищем сполучень, яким володіє Gateway. WS Nodes все одно потребують сполучення пристрою.
- Запис сполучення є тривалим джерелом істини для підтверджених ролей. Активні
  токени пристроїв лишаються обмеженими цим підтвердженим набором ролей; випадковий запис токена
  поза підтвердженими ролями не створює нового доступу.

## Пов’язані документи

- Модель безпеки + prompt injection: [Безпека](/uk/gateway/security)
- Безпечне оновлення (запустіть doctor): [Оновлення](/uk/install/updating)
- Конфігурації каналів:
  - Telegram: [Telegram](/uk/channels/telegram)
  - WhatsApp: [WhatsApp](/uk/channels/whatsapp)
  - Signal: [Signal](/uk/channels/signal)
  - iMessage: [iMessage](/uk/channels/imessage)
  - Discord: [Discord](/uk/channels/discord)
  - Slack: [Slack](/uk/channels/slack)