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

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

## Безпечні категорії (лише stdin)

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

<Warning>
**Не** додавайте до `safeBins` інтерпретатори або середовища виконання (наприклад, `python3`, `node`,
`ruby`, `bash`, `sh`, `zsh`). Якщо команда може виконувати код,
запускати підкоманди або читати файли за своєю природою, надавайте перевагу явним записам у 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.
Для типових безпечних категорій файлово-орієнтовані параметри заборонені; довгі
параметри перевіряються за принципом 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 як **літеральний текст** під час виконання
(без globbing і без розгортання `$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 bins або автоматичним дозволом Skills). Перенаправлення
як і раніше не підтримуються в режимі allowlist. Підстановка команд (`$()` / зворотні лапки) 
відхиляється під час розбору allowlist, зокрема всередині подвійних лапок; використовуйте одинарні
лапки, якщо вам потрібен буквальний текст `$()`.

У схваленнях companion-app на macOS сирий текст shell-команди, що містить керуючий синтаксис 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 і далі вимагав явного
схвалення. У строгому режимі `allow-always` усе ще може зберігати нешкідливі
виклики інтерпретатора/скрипта, але носії inline-eval автоматично не зберігаються.

### Безпечні категорії проти allowlist

| Тема             | `tools.exec.safeBins`                                  | Allowlist (`exec-approvals.json`)                                                  |
| ---------------- | ------------------------------------------------------ | ---------------------------------------------------------------------------------- |
| Мета             | Автодозвіл для вузьких stdin-фільтрів                  | Явна довіра до конкретних виконуваних файлів                                       |
| Тип збігу        | Ім’я виконуваного файла + політика argv safe-bin       | Глоб для шляху до визначеного виконуваного файла або глоб для голого імені команди для команд, викликаних через PATH |
| Область аргументів | Обмежується профілем 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 не може точно визначити рівно один конкретний локальний файл для команди інтерпретатора/середовища виконання (наприклад, package scripts, форми eval, специфічні для середовища виконання ланцюжки loader або неоднозначні багатофайлові форми), виконання, підкріплене схваленням, забороняється замість того, щоб заявляти про семантичне покриття, якого насправді немає.
- Для таких сценаріїв надавайте перевагу sandboxing, окремій межі хоста або явному довіреному allowlist/повному сценарію, де оператор приймає ширшу семантику середовища виконання.

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

### Поведінка доставки подальших повідомлень

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

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

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

Ви можете переспрямовувати запити на 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` у тому самому чаті, але ці канали все одно використовують свій
визначений список апруверів для авторизації, навіть якщо нативну доставку схвалень вимкнено.

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

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

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

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

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

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

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

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

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

FAQ: [Чому для чат-схвалень є дві конфігурації exec approval?](/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 і необов’язковий 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:` можуть визначати схвалення Plugin
  без другого локального резервного шару Slack
- нативна DM/канальна маршрутизація Matrix і скорочення через реакції обробляють і exec-, і Plugin-схвалення;
  авторизація Plugin, як і раніше, надходить із `channels.matrix.dm.allowFrom`
- нативні запити Matrix включають власний вміст події `com.openclaw.approval` у першій події запиту,
  щоб Matrix-клієнти з підтримкою OpenClaw могли читати структурований стан схвалення, тоді як стандартні клієнти
  зберігають резервний варіант у вигляді звичайного тексту `/approve`
- запитувач не обов’язково має бути апрувером
- чат-джерело може схвалити безпосередньо через `/approve`, якщо цей чат уже підтримує команди та відповіді
- нативні кнопки схвалення Discord маршрутизують за типом ID схвалення: ID `plugin:` одразу
  передаються до схвалень Plugin, усе інше — до exec-схвалень
- нативні кнопки схвалення Telegram використовують той самий обмежений резервний перехід від exec до Plugin, що й `/approve`
- коли нативний `target` вмикає доставку до чату-джерела, запити на схвалення містять текст команди
- очікувальні exec-схвалення типово спливають через 30 хвилин
- якщо жоден UI оператора або налаштований клієнт схвалення не може прийняти запит, запит переходить до `askFallback`

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

Див. також:

- [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
