---
read_when:
    - Налаштування безпечних каталогів bin або користувацьких профілів safe-bin
    - Пересилання запитів на схвалення до Slack/Discord/Telegram або інших каналів чату
    - Реалізація нативного клієнта схвалення для каналу
summary: 'Розширені схвалення exec: безпечні бінарні файли, прив’язка інтерпретатора, передавання схвалень, нативна доставка'
title: Схвалення виконання — розширені
x-i18n:
    generated_at: "2026-04-29T05:41:45Z"
    model: gpt-5.5
    provider: openai
    source_hash: de8a72ca1d23e55dc198ae3c5ad55a57660c2111feebfb89f08d8fa9584e4337
    source_path: tools/exec-approvals-advanced.md
    workflow: 16
---

Розширені теми затвердження exec: швидкий шлях `safeBins`, прив’язування інтерпретатора/середовища виконання
та пересилання затверджень у канали чату (включно з нативною доставкою).
Основну політику та потік затверджень див. у [Затвердженнях exec](/uk/tools/exec-approvals).

## Безпечні бінарні файли (лише stdin)

`tools.exec.safeBins` визначає невеликий список бінарних файлів **лише для stdin** (наприклад
`cut`), які можуть працювати в режимі списку дозволених **без** явних записів
у списку дозволених. Безпечні бінарні файли відхиляють позиційні аргументи файлів і токени, схожі на шляхи, тому вони
можуть працювати лише з вхідним потоком. Розглядайте це як вузький швидкий шлях для
потокових фільтрів, а не як загальний список довіри.

<Warning>
**Не** додавайте інтерпретатори або бінарні файли середовищ виконання (наприклад `python3`, `node`,
`ruby`, `bash`, `sh`, `zsh`) до `safeBins`. Якщо команда може виконувати код,
запускати підкоманди або читати файли за своєю природою, надавайте перевагу явним записам
у списку дозволених і залишайте запити затвердження увімкненими. Користувацькі безпечні бінарні файли мають визначати явний
профіль у `tools.exec.safeBinProfiles.<bin>`.
</Warning>

Типові безпечні бінарні файли:

[//]: # "SAFE_BIN_DEFAULTS:START"

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

[//]: # "SAFE_BIN_DEFAULTS:END"

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

### Перевірка argv і заборонені прапорці

Перевірка є детермінованою лише за формою argv (без перевірок існування
файлів у файловій системі хоста), що запобігає поведінці оракула існування файлів через
відмінності дозволу/заборони. Файлово-орієнтовані опції заборонені для типових безпечних бінарних файлів; довгі
опції перевіряються за принципом fail-closed (невідомі прапорці та неоднозначні скорочення
відхиляються).

Заборонені прапорці за профілем безпечного бінарного файлу:

[//]: # "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"

Безпечні бінарні файли також примусово обробляють токени argv як **буквальний текст** під час виконання
(без globbing і без розгортання `$VARS`) для сегментів лише stdin, тому шаблони
на кшталт `*` або `$HOME/...` не можна використати для прихованого читання файлів.

### Довірені каталоги бінарних файлів

Безпечні бінарні файли мають резолвитися з довірених каталогів бінарних файлів (системні типові значення плюс
необов’язкові `tools.exec.safeBinTrustedDirs`). Записи `PATH` ніколи не вважаються довіреними автоматично.
Типові довірені каталоги навмисно мінімальні: `/bin`, `/usr/bin`. Якщо
ваш виконуваний файл безпечного бінарного файлу розташований у шляхах менеджера пакетів/користувача (наприклад
`/opt/homebrew/bin`, `/usr/local/bin`, `/opt/local/bin`, `/snap/bin`), додайте їх
явно до `tools.exec.safeBinTrustedDirs`.

### Ланцюжки shell, обгортки та мультиплексори

Ланцюжки shell (`&&`, `||`, `;`) дозволені, коли кожен сегмент верхнього рівня
задовольняє список дозволених (включно з безпечними бінарними файлами або автоматичним дозволом skill). Перенаправлення
залишаються непідтримуваними в режимі списку дозволених. Підстановка команд (`$()` / зворотні лапки)
відхиляється під час розбору списку дозволених, зокрема всередині подвійних лапок; використовуйте одинарні
лапки, якщо вам потрібен буквальний текст `$()`.

У затвердженнях супровідного застосунку macOS сирий текст shell, що містить керівні або
синтаксичні конструкції розгортання shell (`&&`, `||`, `;`, `|`, `` ` ``, `$`, `<`, `>`, `(`, `)`),
вважається промахом списку дозволених, якщо сам бінарний файл shell не додано до списку дозволених.

Для обгорток shell (`bash|sh|zsh ... -c/-lc`) перевизначення env у межах запиту
звужуються до невеликого явного списку дозволених (`TERM`, `LANG`, `LC_*`, `COLORTERM`,
`NO_COLOR`, `FORCE_COLOR`).

Для рішень `allow-always` у режимі списку дозволених відомі обгортки диспетчеризації (`env`,
`nice`, `nohup`, `stdbuf`, `timeout`) зберігають шлях до внутрішнього виконуваного файлу замість
шляху обгортки. Мультиплексори shell (`busybox`, `toybox`) розгортаються для
аплетів shell (`sh`, `ash` тощо) так само. Якщо обгортку або мультиплексор
не можна безпечно розгорнути, жоден запис списку дозволених не зберігається автоматично.

Якщо ви додаєте інтерпретатори на кшталт `python3` або `node` до списку дозволених, надавайте перевагу
`tools.exec.strictInlineEval=true`, щоб inline eval все одно вимагав явного
затвердження. У строгому режимі `allow-always` усе ще може зберігати безпечні
виклики інтерпретатора/скрипта, але носії inline-eval не зберігаються
автоматично.

### Безпечні бінарні файли проти списку дозволених

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

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

- `safeBins` надходить із конфігурації (`tools.exec.safeBins` або per-agent `agents.list[].tools.exec.safeBins`).
- `safeBinTrustedDirs` надходить із конфігурації (`tools.exec.safeBinTrustedDirs` або per-agent `agents.list[].tools.exec.safeBinTrustedDirs`).
- `safeBinProfiles` надходить із конфігурації (`tools.exec.safeBinProfiles` або per-agent `agents.list[].tools.exec.safeBinProfiles`). Ключі профілю per-agent перевизначають глобальні ключі.
- Записи списку дозволених зберігаються в локальному для хоста `~/.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_900000__
Якщо ви явно додаєте `jq` до `safeBins`, OpenClaw усе одно відхиляє вбудовану `env` у режимі safe-bin,
щоб `jq -n env` не міг вивантажити середовище процесу хоста без явного шляху списку дозволених
або запиту затвердження.

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

Виконання інтерпретатора/середовища виконання, підкріплене затвердженням, навмисно консервативне:

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

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

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

Після завершення затвердженого async exec OpenClaw надсилає followup turn `agent` до тієї самої сесії.

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

## Пересилання затверджень у канали чату

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

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

### Пересилання затверджень Plugin

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

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

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

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

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

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

Для Telegram та інших нативних клієнтів затвердження, які викликають Gateway напряму,
цей fallback навмисно обмежений помилками "approval not found". Справжня
відмова/помилка затвердження exec не виконує непомітну повторну спробу як затвердження plugin.

### Нативна доставка затверджень

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

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

Якщо нативний клієнт підтвердження налаштовано, але для вихідного каналу не активне
жодне нативне середовище виконання, OpenClaw залишає видимим локальний детермінований
запит `/approve`. Якщо нативне середовище виконання активне й намагається доставити запит, але жодна
ціль не отримує картку, OpenClaw надсилає резервне повідомлення в той самий чат із
точною командою `/approve <id> <decision>`, щоб запит усе ще можна було обробити.

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

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

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

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

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

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

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

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

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

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

Чутливі групові команди лише для власника, такі як `/diagnostics` і `/export-trajectory`, використовують приватну
маршрутизацію власника для запитів підтвердження та фінальних результатів. OpenClaw спершу намагається використати приватний маршрут на тій
самій поверхні, де власник виконав команду. Якщо ця поверхня не має приватного маршруту власника, він
переходить до першого доступного маршруту власника з `commands.ownerAllowFrom`, тож групова команда Discord
усе ще може надіслати підтвердження й результат у Telegram DM власника, коли Telegram є налаштованим
основним приватним інтерфейсом. Груповий чат отримує лише коротке підтвердження.

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

Див.:

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

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

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

## Пов’язане

- [Підтвердження виконання](/uk/tools/exec-approvals) — основна політика та потік підтвердження
- [Інструмент виконання](/uk/tools/exec)
- [Підвищений режим](/uk/tools/elevated)
- [Skills](/uk/tools/skills) — поведінка автоматичного дозволу на основі Skills
