---
read_when:
    - Налаштування підтверджень виконання або списків дозволених дій
    - Реалізація UX підтвердження виконання в застосунку для macOS
    - Перегляд запитів на вихід із пісочниці та їхніх наслідків
summary: Запити на підтвердження виконання, списки дозволених дій і запити на вихід із пісочниці
title: Підтвердження виконання
x-i18n:
    generated_at: "2026-04-10T06:17:33Z"
    model: gpt-5.4
    provider: openai
    source_hash: 5f4a2e2f1f3c13a1d1926c9de0720513ea8a74d1ca571dbe74b188d8c560c14c
    source_path: tools/exec-approvals.md
    workflow: 15
---

# Підтвердження виконання

Підтвердження виконання — це **захисний механізм companion app / хоста вузла** для того, щоб дозволити агенту в пісочниці запускати
команди на реальному хості (`gateway` або `node`). Думайте про це як про захисне блокування:
команди дозволяються лише тоді, коли політика + список дозволених дій + (необов’язкове) підтвердження користувача збігаються.
Підтвердження виконання діють **додатково** до політики інструментів і шлюзу підвищених прав (якщо тільки для elevated не встановлено `full`, що пропускає підтвердження).
Ефективна політика — це **суворіша** з `tools.exec.*` і типових налаштувань підтверджень; якщо поле підтверджень пропущене, використовується значення `tools.exec`.
Виконання на хості також використовує локальний стан підтверджень на цій машині. Локальне для хоста
`ask: "always"` у `~/.openclaw/exec-approvals.json` і далі показуватиме запити, навіть якщо
сеанс або типові налаштування конфігурації вимагають `ask: "on-miss"`.
Використовуйте `openclaw approvals get`, `openclaw approvals get --gateway` або
`openclaw approvals get --node <id|name|ip>`, щоб переглянути запитану політику,
джерела політики хоста та ефективний результат.
Для локальної машини `openclaw exec-policy show` показує той самий об’єднаний вигляд, а
`openclaw exec-policy set|preset` може синхронізувати запитану локальну політику з
локальним файлом підтверджень хоста за один крок. Коли локальна область видимості запитує `host=node`,
`openclaw exec-policy show` під час виконання повідомляє про цю область як таку, що керується вузлом, замість того
щоб удавати, ніби локальний файл підтверджень є ефективним джерелом істини.

Якщо UI companion app **недоступний**, будь-який запит, що потребує підтвердження,
обробляється через **резервну поведінку ask** (типово: deny).

Власні клієнти підтвердження в чаті також можуть показувати специфічні для каналу елементи керування в
повідомленні про очікуване підтвердження. Наприклад, Matrix може додавати швидкі реакції до
запиту на підтвердження (`✅` дозволити один раз, `❌` заборонити та `♾️` дозволити завжди, якщо доступно),
при цьому залишаючи команди `/approve ...` у повідомленні як резервний варіант.

## Де це застосовується

Підтвердження виконання примусово застосовуються локально на хості виконання:

- **хост gateway** → процес `openclaw` на машині gateway
- **хост node** → runner вузла (companion app для macOS або headless-хост вузла)

Примітка щодо моделі довіри:

- Виклики, автентифіковані через Gateway, вважаються довіреними операторами для цього Gateway.
- Спарені вузли розширюють цю можливість довіреного оператора на хост вузла.
- Підтвердження виконання зменшують ризик випадкового виконання, але не є межею автентифікації на рівні користувача.
- Підтверджені запуски на хості вузла прив’язують канонічний контекст виконання: канонічний cwd, точний argv, прив’язку env,
  коли вона присутня, і зафіксований шлях до виконуваного файла, коли це застосовно.
- Для shell-скриптів і прямого виклику файлів через інтерпретатор/середовище виконання OpenClaw також намагається прив’язати
  один конкретний локальний файловий операнд. Якщо цей прив’язаний файл зміниться після підтвердження, але до виконання,
  запуск буде заборонено замість виконання зміненого вмісту.
- Ця прив’язка файла навмисно є механізмом best-effort, а не повною семантичною моделлю для кожного
  шляху завантаження інтерпретатора/середовища виконання. Якщо режим підтвердження не може визначити рівно один конкретний локальний
  файл для прив’язки, він відмовляється створювати запуск на основі підтвердження, а не удає повне покриття.

Поділ у macOS:

- **сервіс хоста вузла** пересилає `system.run` до **застосунку macOS** через локальний IPC.
- **застосунок macOS** примусово застосовує підтвердження + виконує команду в контексті UI.

## Налаштування та зберігання

Підтвердження зберігаються в локальному JSON-файлі на хості виконання:

`~/.openclaw/exec-approvals.json`

Приклад схеми:

```json
{
  "version": 1,
  "socket": {
    "path": "~/.openclaw/exec-approvals.sock",
    "token": "base64url-token"
  },
  "defaults": {
    "security": "deny",
    "ask": "on-miss",
    "askFallback": "deny",
    "autoAllowSkills": false
  },
  "agents": {
    "main": {
      "security": "allowlist",
      "ask": "on-miss",
      "askFallback": "deny",
      "autoAllowSkills": true,
      "allowlist": [
        {
          "id": "B0C8C0B3-2C2D-4F8A-9A3C-5A4B3C2D1E0F",
          "pattern": "~/Projects/**/bin/rg",
          "lastUsedAt": 1737150000000,
          "lastUsedCommand": "rg -n TODO",
          "lastResolvedPath": "/Users/user/Projects/.../bin/rg"
        }
      ]
    }
  }
}
```

## Режим "YOLO" без підтвердження

Якщо ви хочете, щоб виконання на хості працювало без запитів на підтвердження, потрібно відкрити **обидва** рівні політики:

- запитана політика виконання в конфігурації OpenClaw (`tools.exec.*`)
- локальна політика підтверджень хоста в `~/.openclaw/exec-approvals.json`

Тепер це типова поведінка хоста, якщо ви явно її не зробите суворішою:

- `tools.exec.security`: `full` на `gateway`/`node`
- `tools.exec.ask`: `off`
- хост `askFallback`: `full`

Важливе розрізнення:

- `tools.exec.host=auto` вибирає, де виконується exec: у пісочниці, якщо вона доступна, інакше на gateway.
- YOLO вибирає, як підтверджується виконання на хості: `security=full` плюс `ask=off`.
- У режимі YOLO OpenClaw не додає окремий евристичний шлюз підтвердження для обфускації команд поверх налаштованої політики виконання на хості.
- `auto` не робить маршрутизацію через gateway безкоштовним способом обходу із сеансу в пісочниці. Запит `host=node` на рівні окремого виклику дозволений із `auto`, а `host=gateway` дозволений із `auto` лише тоді, коли активне середовище виконання в пісочниці відсутнє. Якщо вам потрібне стабільне нетипове значення замість auto, установіть `tools.exec.host` або явно використовуйте `/exec host=...`.

Якщо вам потрібніше більш консервативне налаштування, зробіть суворішим будь-який із рівнів назад до `allowlist` / `on-miss`
або `deny`.

Постійне налаштування "ніколи не запитувати" для хоста gateway:

```bash
openclaw config set tools.exec.host gateway
openclaw config set tools.exec.security full
openclaw config set tools.exec.ask off
openclaw gateway restart
```

Потім установіть відповідний файл підтверджень хоста:

```bash
openclaw approvals set --stdin <<'EOF'
{
  version: 1,
  defaults: {
    security: "full",
    ask: "off",
    askFallback: "full"
  }
}
EOF
```

Локальний ярлик для тієї самої політики хоста gateway на поточній машині:

```bash
openclaw exec-policy preset yolo
```

Цей локальний ярлик оновлює обидва:

- локальні `tools.exec.host/security/ask`
- локальні типові значення `~/.openclaw/exec-approvals.json`

Він навмисно працює лише локально. Якщо вам потрібно змінити підтвердження для хоста gateway або хоста вузла
віддалено, і далі використовуйте `openclaw approvals set --gateway` або
`openclaw approvals set --node <id|name|ip>`.

Для хоста вузла застосуйте той самий файл підтверджень на цьому вузлі:

```bash
openclaw approvals set --node <id|name|ip> --stdin <<'EOF'
{
  version: 1,
  defaults: {
    security: "full",
    ask: "off",
    askFallback: "full"
  }
}
EOF
```

Важливе локальне обмеження:

- `openclaw exec-policy` не синхронізує підтвердження вузла
- `openclaw exec-policy set --host node` відхиляється
- підтвердження виконання вузла отримуються з вузла під час виконання, тож оновлення, націлені на вузол, потрібно робити через `openclaw approvals --node ...`

Ярлик лише для сеансу:

- `/exec security=full ask=off` змінює лише поточний сеанс.
- `/elevated full` — це аварійний ярлик, який також пропускає підтвердження виконання для цього сеансу.

Якщо файл підтверджень хоста залишається суворішим, ніж конфігурація, суворіша політика хоста все одно має пріоритет.

## Параметри політики

### Security (`exec.security`)

- **deny**: блокувати всі запити на виконання на хості.
- **allowlist**: дозволяти лише команди зі списку дозволених дій.
- **full**: дозволяти все (еквівалент elevated).

### Ask (`exec.ask`)

- **off**: ніколи не показувати запит.
- **on-miss**: показувати запит лише тоді, коли список дозволених дій не збігається.
- **always**: показувати запит для кожної команди.
- тривала довіра `allow-always` не пригнічує запити, коли ефективний режим ask — `always`

### Ask fallback (`askFallback`)

Якщо потрібен запит, але UI недосяжний, резервна поведінка визначає результат:

- **deny**: блокувати.
- **allowlist**: дозволяти лише за збігу зі списком дозволених дій.
- **full**: дозволяти.

### Посилення inline eval інтерпретаторів (`tools.exec.strictInlineEval`)

Коли `tools.exec.strictInlineEval=true`, OpenClaw розглядає форми inline eval коду як такі, що потребують лише підтвердження, навіть якщо сам двійковий файл інтерпретатора є у списку дозволених.

Приклади:

- `python -c`
- `node -e`, `node --eval`, `node -p`
- `ruby -e`
- `perl -e`, `perl -E`
- `php -r`
- `lua -e`
- `osascript -e`

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

- ці команди все одно потребують явного підтвердження;
- `allow-always` не зберігає для них нові записи списку дозволених автоматично.

## Список дозволених дій (для кожного агента)

Списки дозволених дій — **окремі для кожного агента**. Якщо існує кілька агентів, перемкніть агента,
якого редагуєте, у застосунку macOS. Шаблони — це **нечутливі до регістру glob-збіги**.
Шаблони мають вказувати на **шляхи до двійкових файлів** (записи лише з базовою назвою ігноруються).
Застарілі записи `agents.default` під час завантаження мігрують до `agents.main`.
Ланцюжки shell-команд на кшталт `echo ok && pwd` усе одно вимагають, щоб кожен сегмент верхнього рівня відповідав правилам списку дозволених дій.

Приклади:

- `~/Projects/**/bin/peekaboo`
- `~/.local/bin/*`
- `/opt/homebrew/bin/rg`

Кожен запис списку дозволених дій відстежує:

- **id** стабільний UUID, що використовується для ідентичності в UI (необов’язково)
- **last used** часову мітку
- **last used command**
- **last resolved path**

## Автодозвіл для CLI Skills

Коли ввімкнено **Автодозвіл для CLI Skills**, виконувані файли, на які посилаються відомі Skills,
вважаються такими, що є у списку дозволених дій на вузлах (вузол macOS або headless-хост вузла). Для цього використовується
`skills.bins` через Gateway RPC, щоб отримати список двійкових файлів Skills. Вимкніть це, якщо вам потрібні суворі ручні списки дозволених дій.

Важливі примітки щодо довіри:

- Це **неявний зручний список дозволених дій**, окремий від ручних записів списку дозволених шляхів.
- Він призначений для довірених операторських середовищ, де Gateway і вузол перебувають у межах однієї моделі довіри.
- Якщо вам потрібна сувора явна довіра, залиште `autoAllowSkills: false` і використовуйте лише ручні записи списку дозволених шляхів.

## Safe bins (лише stdin)

`tools.exec.safeBins` визначає невеликий список **двійкових файлів лише для stdin** (наприклад, `cut`),
які можуть працювати в режимі allowlist **без** явних записів у списку дозволених дій. Safe bins відхиляють
позиційні файлові аргументи та токени, схожі на шляхи, тож вони можуть працювати лише з вхідним потоком.
Сприймайте це як вузький швидкий шлях для потокових фільтрів, а не як загальний список довіри.
**Не** додавайте двійкові файли інтерпретаторів або середовищ виконання (наприклад, `python3`, `node`, `ruby`, `bash`, `sh`, `zsh`) до `safeBins`.
Якщо команда за своєю природою може виконувати eval коду, запускати підкоманди або читати файли, надавайте перевагу явним записам у списку дозволених дій і залишайте запити на підтвердження ввімкненими.
Користувацькі safe bins мають визначати явний профіль у `tools.exec.safeBinProfiles.<bin>`.
Перевірка є детермінованою лише за формою argv (без перевірок існування у файловій системі хоста), що
запобігає поведінці oracle щодо існування файлів через відмінності allow/deny.
Опції, орієнтовані на файли, заборонені для типових safe bins (наприклад, `sort -o`, `sort --output`,
`sort --files0-from`, `sort --compress-program`, `sort --random-source`,
`sort --temporary-directory`/`-T`, `wc --files0-from`, `jq -f/--from-file`,
`grep -f/--file`).
Safe bins також примусово застосовують явну політику прапорців для кожного двійкового файла для опцій, які порушують
поведінку лише через stdin (наприклад, `sort -o/--output/--compress-program` і рекурсивні прапорці grep).
Довгі опції в режимі safe-bin перевіряються за fail-closed принципом: невідомі прапорці та неоднозначні
скорочення відхиляються.
Заборонені прапорці за профілем safe-bin:

[//]: # "SAFE_BIN_DENIED_FLAGS:START"

- `grep`: `--dereference-recursive`, `--directories`, `--exclude-from`, `--file`, `--recursive`, `-R`, `-d`, `-f`, `-r`
- `jq`: `--argfile`, `--from-file`, `--library-path`, `--rawfile`, `--slurpfile`, `-L`, `-f`
- `sort`: `--compress-program`, `--files0-from`, `--output`, `--random-source`, `--temporary-directory`, `-T`, `-o`
- `wc`: `--files0-from`

[//]: # "SAFE_BIN_DENIED_FLAGS:END"

Safe bins також примусово обробляють токени argv як **буквальний текст** під час виконання (без globbing
і без розгортання `$VARS`) для сегментів лише зі stdin, тож шаблони на кшталт `*` або `$HOME/...` не можуть
використовуватися для прихованого читання файлів.
Safe bins також мають визначатися з довірених каталогів двійкових файлів (системні типові каталоги плюс необов’язкові
`tools.exec.safeBinTrustedDirs`). Записи `PATH` ніколи не вважаються довіреними автоматично.
Типові довірені каталоги safe-bin навмисно мінімальні: `/bin`, `/usr/bin`.
Якщо ваш виконуваний файл safe-bin розташований у шляхах package manager або користувача (наприклад,
`/opt/homebrew/bin`, `/usr/local/bin`, `/opt/local/bin`, `/snap/bin`), додайте їх явно
до `tools.exec.safeBinTrustedDirs`.
Ланцюжки shell-команд і перенаправлення не дозволяються автоматично в режимі allowlist.

Ланцюжки shell-команд (`&&`, `||`, `;`) дозволені, якщо кожен сегмент верхнього рівня відповідає списку дозволених дій
(включно з safe bins або автодозволом для Skills). Перенаправлення в режимі allowlist, як і раніше, не підтримуються.
Підстановка команд (`$()` / зворотні лапки) відхиляється під час розбору allowlist, зокрема всередині
подвійних лапок; використовуйте одинарні лапки, якщо вам потрібен буквальний текст `$()`.
У підтвердженнях companion app для macOS сирий текст shell, що містить керівні або розгортувальні конструкції shell
(`&&`, `||`, `;`, `|`, `` ` ``, `$`, `<`, `>`, `(`, `)`), розглядається як незбіг зі списком дозволених дій, якщо
сам двійковий файл shell не є у списку дозволених.
Для обгорток shell (`bash|sh|zsh ... -c/-lc`) перевизначення env у межах запиту зводяться до
невеликого явного списку дозволених значень (`TERM`, `LANG`, `LC_*`, `COLORTERM`, `NO_COLOR`, `FORCE_COLOR`).
Для рішень allow-always у режимі allowlist відомі обгортки диспетчеризації
(`env`, `nice`, `nohup`, `stdbuf`, `timeout`) зберігають внутрішні шляхи до виконуваних файлів, а не шляхи
до самих обгорток. Shell-мультиплексори (`busybox`, `toybox`) також розгортаються для shell-аплетів (`sh`, `ash`,
тощо), тож зберігаються внутрішні виконувані файли, а не двійкові файли мультиплексора. Якщо обгортку або
мультиплексор не можна безпечно розгорнути, запис списку дозволених дій автоматично не зберігається.
Якщо ви додаєте інтерпретатори, як-от `python3` або `node`, до списку дозволених, надавайте перевагу `tools.exec.strictInlineEval=true`, щоб inline eval і далі вимагав явного підтвердження. У суворому режимі `allow-always` усе ще може зберігати нешкідливі виклики інтерпретатора/скрипта, але носії inline-eval автоматично не зберігаються.

Типові safe bins:

[//]: # "SAFE_BIN_DEFAULTS:START"

`cut`, `uniq`, `head`, `tail`, `tr`, `wc`

[//]: # "SAFE_BIN_DEFAULTS:END"

`grep` і `sort` не входять до типового списку. Якщо ви явно їх увімкнете, зберігайте явні записи списку дозволених дій для
їхніх сценаріїв, що не обмежуються stdin.
Для `grep` у режимі safe-bin передавайте шаблон через `-e`/`--regexp`; позиційна форма шаблону
відхиляється, щоб файлові операнди не можна було приховати як неоднозначні позиційні аргументи.

### Safe bins у порівнянні зі списком дозволених дій

| Тема             | `tools.exec.safeBins`                                  | Список дозволених дій (`exec-approvals.json`)                |
| ---------------- | ------------------------------------------------------ | ------------------------------------------------------------ |
| Мета             | Автодозвіл для вузьких stdin-фільтрів                  | Явна довіра до конкретних виконуваних файлів                 |
| Тип збігу        | Назва виконуваного файла + політика argv safe-bin      | Glob-шаблон шляху до визначеного виконуваного файла          |
| Область аргументів | Обмежена профілем safe-bin і правилами буквальних токенів | Лише збіг шляху; відповідальність за аргументи інакше на вас |
| Типові приклади  | `head`, `tail`, `tr`, `wc`                             | `jq`, `python3`, `node`, `ffmpeg`, користувацькі CLI         |
| Найкраще застосування | Низькоризикові текстові перетворення в конвеєрах      | Будь-який інструмент із ширшою поведінкою або побічними ефектами |

Розташування конфігурації:

- `safeBins` надходить із конфігурації (`tools.exec.safeBins` або `agents.list[].tools.exec.safeBins` для окремого агента).
- `safeBinTrustedDirs` надходить із конфігурації (`tools.exec.safeBinTrustedDirs` або `agents.list[].tools.exec.safeBinTrustedDirs` для окремого агента).
- `safeBinProfiles` надходить із конфігурації (`tools.exec.safeBinProfiles` або `agents.list[].tools.exec.safeBinProfiles` для окремого агента). Ключі профілю для окремого агента мають пріоритет над глобальними ключами.
- записи allowlist зберігаються в локальному для хоста `~/.openclaw/exec-approvals.json` у `agents.<id>.allowlist` (або через Control UI / `openclaw approvals allowlist ...`).
- `openclaw security audit` показує попередження `tools.exec.safe_bins_interpreter_unprofiled`, коли двійкові файли інтерпретаторів/середовищ виконання з’являються в `safeBins` без явних профілів.
- `openclaw doctor --fix` може створити заготовки відсутніх записів `safeBinProfiles.<bin>` як `{}` (після цього перегляньте й посильте їх). Для двійкових файлів інтерпретаторів/середовищ виконання заготовки автоматично не створюються.

Приклад користувацького профілю:
__OC_I18N_900005__
Якщо ви явно додаєте `jq` до `safeBins`, OpenClaw усе одно відхиляє вбудовану команду `env` у режимі safe-bin,
щоб `jq -n env` не міг вивантажити середовище процесу хоста без явного шляху allowlist
або запиту на підтвердження.

## Редагування в Control UI

Використовуйте картку **Control UI → Nodes → Exec approvals**, щоб редагувати типові налаштування, перевизначення
для окремих агентів і списки дозволених дій. Виберіть область видимості (Defaults або агент), змініть політику,
додайте/видаліть шаблони списку дозволених дій, а потім натисніть **Save**. UI показує метадані **last used**
для кожного шаблону, щоб вам було легше підтримувати список у впорядкованому стані.

Селектор цілі вибирає **Gateway** (локальні підтвердження) або **Node**. Вузли
мають оголошувати `system.execApprovals.get/set` (застосунок macOS або headless-хост вузла).
Якщо вузол ще не оголошує підтвердження виконання, відредагуйте його локальний
`~/.openclaw/exec-approvals.json` безпосередньо.

CLI: `openclaw approvals` підтримує редагування gateway або вузла (див. [CLI підтверджень](/cli/approvals)).

## Потік підтвердження

Коли потрібен запит на підтвердження, gateway транслює `exec.approval.requested` клієнтам операторів.
Control UI і застосунок macOS обробляють його через `exec.approval.resolve`, після чого gateway пересилає
підтверджений запит хосту вузла.

Для `host=node` запити на підтвердження містять канонічне корисне навантаження `systemRunPlan`. Gateway використовує
цей план як авторитетний контекст команди/cwd/сеансу під час пересилання підтверджених запитів `system.run`.

Це важливо для асинхронної затримки підтвердження:

- шлях виконання вузла готує один канонічний план наперед
- запис підтвердження зберігає цей план і його метадані прив’язки
- після підтвердження остаточний пересланий виклик `system.run` повторно використовує збережений план
  замість довіри до пізніших змін викликача
- якщо викликач змінює `command`, `rawCommand`, `cwd`, `agentId` або
  `sessionKey` після створення запиту на підтвердження, gateway відхиляє
  пересланий запуск як невідповідність підтвердженню

## Команди інтерпретатора/середовища виконання

Запуски інтерпретатора/середовища виконання на основі підтвердження навмисно є консервативними:

- Точний контекст argv/cwd/env завжди прив’язується.
- Форми прямого shell-скрипта і прямого файла середовища виконання прив’язуються в режимі best-effort до одного конкретного локального
  знімка файла.
- Поширені форми обгорток package manager, які все ще визначаються в один прямий локальний файл (наприклад,
  `pnpm exec`, `pnpm node`, `npm exec`, `npx`), розгортаються перед прив’язкою.
- Якщо OpenClaw не може визначити рівно один конкретний локальний файл для команди інтерпретатора/середовища виконання
  (наприклад, package scripts, форми eval, специфічні для середовища виконання ланцюжки завантажувачів або неоднозначні форми
  з кількома файлами), виконання на основі підтвердження забороняється замість того, щоб стверджувати семантичне покриття, якого
  насправді немає.
- Для таких робочих процесів надавайте перевагу пісочниці, окремій межі хоста або явному
  довіреному процесу allowlist/full, де оператор приймає ширшу семантику середовища виконання.

Коли потрібні підтвердження, інструмент exec одразу повертає id підтвердження. Використовуйте цей id, щоб
пов’язати подальші системні події (`Exec finished` / `Exec denied`). Якщо жодне рішення не надійде до завершення
часу очікування, запит вважається таким, що перевищив час очікування підтвердження, і показується як причина відмови.

### Поведінка доставлення followup

Після завершення підтвердженого асинхронного exec OpenClaw надсилає followup-хід `agent` у той самий сеанс.

- Якщо існує дійсна зовнішня ціль доставлення (канал доставлення плюс ціль `to`), доставлення followup використовує цей канал.
- У потоках лише з webchat або внутрішнім сеансом без зовнішньої цілі доставлення followup залишається лише в межах сеансу (`deliver: false`).
- Якщо викликач явно запитує суворе зовнішнє доставлення без жодного зовнішнього каналу, що може бути визначений, запит завершується помилкою `INVALID_REQUEST`.
- Якщо ввімкнено `bestEffortDeliver` і не вдається визначити жоден зовнішній канал, доставлення знижується до режиму лише для сеансу замість помилки.

Діалог підтвердження містить:

- команду + аргументи
- cwd
- id агента
- визначений шлях до виконуваного файла
- метадані хоста + політики

Дії:

- **Allow once** → виконати зараз
- **Always allow** → додати до списку дозволених дій + виконати
- **Deny** → заблокувати

## Пересилання підтверджень до чат-каналів

Ви можете пересилати запити на підтвердження exec до будь-якого чат-каналу (включно з каналами плагінів) і підтверджувати
їх за допомогою `/approve`. Для цього використовується звичайний конвеєр вихідного доставлення.

Конфігурація:
__OC_I18N_900006__
Відповідь у чаті:
__OC_I18N_900007__
Команда `/approve` обробляє як підтвердження exec, так і підтвердження плагінів. Якщо ID не збігається з жодним очікуваним підтвердженням exec, вона автоматично перевіряє підтвердження плагінів.

### Пересилання підтверджень плагінів

Пересилання підтверджень плагінів використовує той самий конвеєр доставлення, що й підтвердження exec, але має власну
незалежну конфігурацію в `approvals.plugin`. Увімкнення або вимкнення одного не впливає на інше.
__OC_I18N_900008__
Форма конфігурації ідентична `approvals.exec`: `enabled`, `mode`, `agentFilter`,
`sessionFilter` і `targets` працюють так само.

Канали, що підтримують спільні інтерактивні відповіді, показують однакові кнопки підтвердження як для exec, так і для
підтверджень плагінів. Канали без спільного інтерактивного UI використовують звичайний текст із
інструкціями `/approve`.

### Підтвердження в тому самому чаті на будь-якому каналі

Коли запит на підтвердження exec або плагіна надходить із чату, який підтримує доставлення, цей самий чат
тепер за замовчуванням може підтверджувати його через `/approve`. Це стосується таких каналів, як Slack, Matrix і
Microsoft Teams, а також наявних потоків Web UI і terminal UI.

Цей спільний шлях текстової команди використовує звичайну модель автентифікації каналу для цієї розмови. Якщо вихідний чат
вже може надсилати команди й отримувати відповіді, запитам на підтвердження більше не потрібен
окремий власний адаптер доставлення лише для того, щоб залишатися в очікуванні.

Discord і Telegram також підтримують `/approve` у тому самому чаті, але ці канали все ще використовують свій
визначений список тих, хто може підтверджувати, для авторизації, навіть коли власне доставлення підтверджень вимкнено.

Для Telegram та інших власних клієнтів підтвердження, які викликають Gateway безпосередньо,
цей резервний механізм навмисно обмежено збоями типу "підтвердження не знайдено". Реальна
відмова/помилка підтвердження exec не повторюється мовчки як підтвердження плагіна.

### Власне доставлення підтверджень

Деякі канали також можуть працювати як власні клієнти підтвердження. Власні клієнти додають приватні повідомлення тим, хто може підтверджувати, fanout у вихідний чат
і специфічний для каналу інтерактивний UX підтвердження поверх спільного потоку `/approve` у тому самому чаті.

Коли доступні власні картки/кнопки підтвердження, цей власний UI є основним
шляхом взаємодії для агента. Агент також не повинен дублювати звичайну команду чату
`/approve`, якщо тільки результат інструмента не вказує, що підтвердження через чат недоступні або
ручне підтвердження — це єдиний шлях, що залишився.

Загальна модель:

- політика виконання на хості й далі визначає, чи потрібне підтвердження exec
- `approvals.exec` керує пересиланням запитів на підтвердження в інші чат-призначення
- `channels.<channel>.execApprovals` керує тим, чи цей канал виступає власним клієнтом підтвердження

Власні клієнти підтвердження автоматично вмикають доставлення спочатку в DM, якщо виконуються всі ці умови:

- канал підтримує власне доставлення підтверджень
- тих, хто може підтверджувати, можна визначити з явних `execApprovals.approvers` або з
  задокументованих резервних джерел цього каналу
- `channels.<channel>.execApprovals.enabled` не задано або має значення `"auto"`

Установіть `enabled: false`, щоб явно вимкнути власний клієнт підтвердження. Установіть `enabled: true`, щоб примусово
ввімкнути його, коли тих, хто може підтверджувати, вдається визначити. Доставлення в публічний вихідний чат і далі явно керується через
`channels.<channel>.execApprovals.target`.

FAQ: [Чому для підтверджень exec у чаті існує дві конфігурації?](/help/faq#why-are-there-two-exec-approval-configs-for-chat-approvals)

- Discord: `channels.discord.execApprovals.*`
- Slack: `channels.slack.execApprovals.*`
- Telegram: `channels.telegram.execApprovals.*`

Ці власні клієнти підтвердження додають маршрутизацію в DM і необов’язковий fanout у канал поверх спільного
потоку `/approve` у тому самому чаті та спільних кнопок підтвердження.

Спільна поведінка:

- Slack, Matrix, Microsoft Teams та подібні чати, що підтримують доставлення, використовують звичайну модель автентифікації каналу
  для `/approve` у тому самому чаті
- коли власний клієнт підтвердження автоматично вмикається, типовою ціллю власного доставлення стають DM тим, хто може підтверджувати
- для Discord і Telegram лише визначені особи, які можуть підтверджувати, можуть підтверджувати або відхиляти
- осіб, які можуть підтверджувати в Discord, можна задати явно (`execApprovals.approvers`) або вивести з `commands.ownerAllowFrom`
- осіб, які можуть підтверджувати в Telegram, можна задати явно (`execApprovals.approvers`) або вивести з наявної конфігурації власника (`allowFrom`, а також `defaultTo` для direct-message, де це підтримується)
- осіб, які можуть підтверджувати в Slack, можна задати явно (`execApprovals.approvers`) або вивести з `commands.ownerAllowFrom`
- власні кнопки Slack зберігають тип id підтвердження, тож id `plugin:` можуть визначати підтвердження плагінів
  без другого локального резервного шару Slack
- власна маршрутизація DM/каналу та швидкі реакції Matrix обробляють як підтвердження exec, так і підтвердження плагінів;
  авторизація плагінів і далі походить із `channels.matrix.dm.allowFrom`
- запитувач не обов’язково має бути особою, що може підтверджувати
- вихідний чат може підтверджувати безпосередньо через `/approve`, коли цей чат уже підтримує команди та відповіді
- власні кнопки підтвердження Discord маршрутизують за типом id підтвердження: id `plugin:` одразу переходять
  до підтверджень плагінів, усе інше — до підтверджень exec
- власні кнопки підтвердження Telegram дотримуються того самого обмеженого резервного переходу від exec до плагіна, що й `/approve`
- коли власний `target` вмикає доставлення у вихідний чат, запити на підтвердження містять текст команди
- очікувані підтвердження exec типово протерміновуються через 30 хвилин
- якщо жоден UI оператора або налаштований клієнт підтвердження не може прийняти запит, запит переходить до `askFallback`

Telegram типово використовує DM для тих, хто може підтверджувати (`target: "dm"`). Ви можете переключити це на `channel` або `both`, якщо
хочете, щоб запити на підтвердження також з’являлися у вихідному чаті/темі Telegram. Для тем форуму Telegram
OpenClaw зберігає тему для запиту на підтвердження і follow-up після підтвердження.

Дивіться:

- [Discord](/channels/discord)
- [Telegram](/channels/telegram)

### Потік IPC у macOS
__OC_I18N_900009__
Примітки щодо безпеки:

- Режим Unix socket `0600`, токен зберігається в `exec-approvals.json`.
- Перевірка однотипного UID однорангового процесу.
- Challenge/response (nonce + HMAC token + хеш запиту) + короткий TTL.

## Системні події

Життєвий цикл exec відображається як системні повідомлення:

- `Exec running` (лише якщо команда перевищує поріг сповіщення про виконання)
- `Exec finished`
- `Exec denied`

Вони публікуються в сеанс агента після того, як вузол повідомляє про подію.
Підтвердження exec на хості gateway надсилають ті самі події життєвого циклу, коли команда завершується (і, за потреби, коли вона виконується довше за поріг).
Exec із підтвердженням повторно використовують id підтвердження як `runId` у цих повідомленнях для зручної кореляції.

## Поведінка у разі відхиленого підтвердження

Коли асинхронне підтвердження exec відхилене, OpenClaw не дозволяє агенту повторно використовувати
вивід будь-якого попереднього запуску тієї самої команди в сеансі. Причина відхилення
передається з явною вказівкою, що жодного виводу команди немає, що не дозволяє
агенту стверджувати, що є новий вивід, або повторювати відхилену команду зі
застарілими результатами попереднього успішного запуску.

## Наслідки

- **full** має широкі можливості; за можливості надавайте перевагу спискам дозволених дій.
- **ask** залишає вас у циклі, водночас дозволяючи швидко підтверджувати.
- Окремі для кожного агента списки дозволених дій не дають підтвердженням одного агента потрапляти до інших.
- Підтвердження застосовуються лише до запитів host exec від **авторизованих відправників**. Неавторизовані відправники не можуть виконувати `/exec`.
- `/exec security=full` — це зручний параметр на рівні сеансу для авторизованих операторів, який навмисно пропускає підтвердження.
  Щоб жорстко заборонити host exec, установіть для security підтверджень значення `deny` або забороніть інструмент `exec` через політику інструментів.

Пов’язане:

- [Інструмент Exec](/uk/tools/exec)
- [Режим Elevated](/uk/tools/elevated)
- [Skills](/uk/tools/skills)

## Пов’язане

- [Exec](/uk/tools/exec) — інструмент виконання shell-команд
- [Пісочниця](/uk/gateway/sandboxing) — режими пісочниці та доступ до робочого простору
- [Безпека](/uk/gateway/security) — модель безпеки та посилення захисту
- [Пісочниця vs Політика інструментів vs Elevated](/uk/gateway/sandbox-vs-tool-policy-vs-elevated) — коли що використовувати
