Дозволи на виконання — розширені

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

​

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

tools.exec.safeBins визначає невеликий список бінарних файлів лише для stdin (наприклад, cut), які можуть працювати в режимі allowlist без явних записів у allowlist. Безпечні бінарні файли відхиляють позиційні файлові аргументи та токени, схожі на шляхи, тому можуть працювати лише з вхідним потоком. Розглядайте це як вузький швидкий шлях для потокових фільтрів, а не як загальний список довіри. Типові безпечні бінарні файли: cut, uniq, head, tail, tr, wc grep і sort не входять до типового списку. Якщо ви явно вмикаєте їх, зберігайте явні записи allowlist для їхніх сценаріїв не через stdin. Для grep у режимі safe-bin передавайте шаблон через -e/--regexp; позиційна форма шаблону відхиляється, щоб файлові операнди не можна було приховано передати як неоднозначні позиційні аргументи.

​

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

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

• 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

Безпечні бінарні файли також примусово обробляють токени 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

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

• 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-схвалень?

• 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
• Telegram

​

Потік macOS IPC

OC_I18N_900004 Примітки щодо безпеки:

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

​

Пов’язане

• Дозволи на виконання — базова політика та потік схвалення
• Інструмент exec
• Підвищений режим
• Skills — поведінка автодозволу на основі Skills