---
read_when:
    - Налаштування безпечних бінарних файлів або користувацьких профілів safe-bin
    - Переспрямування схвалень до Slack/Discord/Telegram або інших чат-каналів
    - Реалізація нативного клієнта схвалення для каналу
summary: 'Розширені дозволи на виконання: безпечні бінарні файли, прив’язка інтерпретатора, переспрямування схвалення, нативна доставка'
title: Дозволи на виконання — розширені
x-i18n:
    generated_at: "2026-04-23T23:27:49Z"
    model: gpt-5.4
    provider: openai
    source_hash: 8a24a3539126b0f0fd11696c31efc8a6a9a4262fe4cd89bf456ff92a4f05c36c
    source_path: tools/exec-approvals-advanced.md
    workflow: 15
---

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

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

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

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

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

[//]: # "SAFE_BIN_DEFAULTS:START"

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

[//]: # "SAFE_BIN_DEFAULTS:END"

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

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

Перевірка є детермінованою лише за формою argv (без перевірок існування у файловій системі хоста),
що запобігає поведінці оракула існування файлів через відмінності allow/deny.
Опції, орієнтовані на файли, заборонені для типових 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"

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

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

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

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

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

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

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

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

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

### Safe bins проти allowlist

| Тема             | `tools.exec.safeBins`                                  | Allowlist (`exec-approvals.json`)                            |
| ---------------- | ------------------------------------------------------ | ------------------------------------------------------------ |
| Мета             | Автодозвіл для вузьких stdin-фільтрів                  | Явна довіра до конкретних виконуваних файлів                 |
| Тип відповідності | Ім’я виконуваного файла + політика argv safe-bin      | Глоб-шаблон шляху до визначеного виконуваного файла          |
| Область аргументів | Обмежена профілем 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_900000__
Якщо ви явно додаєте `jq` до `safeBins`, OpenClaw усе одно відхиляє builtin `env` у режимі safe-bin,
тому `jq -n env` не зможе вивантажити середовище процесу хоста без явного шляху в allowlist
або підказки схвалення.

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

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

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

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

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

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

- Якщо існує дійсна зовнішня ціль доставки (канал, придатний до доставки, плюс цільовий `to`), followup-доставка використовує цей канал.
- У потоках лише webchat або internal-session без зовнішньої цілі 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 також підтримують `/approve` у тому самому чаті, але ці канали все ще використовують свій
визначений список approver для авторизації, навіть коли нативну доставку схвалень вимкнено.

Для Telegram та інших нативних клієнтів схвалення, які напряму викликають Gateway,
цей fallback навмисно обмежено збоями типу «схвалення не знайдено». Справжня
відмова/помилка exec-схвалення не повторюється мовчки як схвалення Plugin.

### Нативна доставка схвалень

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

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

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

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

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

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

Установіть `enabled: false`, щоб явно вимкнути нативний клієнт схвалень. Установіть `enabled: true`, щоб примусово
увімкнути його, коли approver визначаються. Публічна доставка до чату-джерела й надалі явно задається через
`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 для approver
- для Discord і Telegram лише визначені approver можуть схвалювати або відхиляти
- approver у Discord можуть бути явними (`execApprovals.approvers`) або визначатися з `commands.ownerAllowFrom`
- approver у Telegram можуть бути явними (`execApprovals.approvers`) або визначатися з наявної конфігурації owner (`allowFrom`, а також `defaultTo` для direct-message, де це підтримується)
- approver у Slack можуть бути явними (`execApprovals.approvers`) або визначатися з `commands.ownerAllowFrom`
- нативні кнопки Slack зберігають тип id схвалення, тож id `plugin:` можуть визначати схвалення Plugin
  без другого локального fallback-рівня Slack
- нативна DM/канальна маршрутизація Matrix і скорочення через реакції обробляють і exec-схвалення, і схвалення Plugin;
  авторизація Plugin і надалі походить з `channels.matrix.dm.allowFrom`
- запитувач не зобов’язаний бути approver
- чат-джерело може схвалити запит напряму через `/approve`, якщо цей чат уже підтримує команди та відповіді
- нативні кнопки схвалення Discord маршрутизують за типом id схвалення: id `plugin:` одразу
  спрямовуються до схвалень Plugin, усе інше — до exec-схвалень
- нативні кнопки схвалення Telegram використовують той самий обмежений exec-to-plugin fallback, що й `/approve`
- коли нативний `target` вмикає доставку до чату-джерела, підказки схвалення містять текст команди
- exec-схвалення в очікуванні за замовчуванням спливають через 30 хвилин
- якщо жоден UI оператора або налаштований клієнт схвалень не може прийняти запит, підказка повертається до `askFallback`

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

Див. також:

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

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

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

## Пов’язане

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