Схвалення виконання — розширені налаштування

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

​

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

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

​

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

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

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

​

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

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

• 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). Ключі профілю окремого агента перевизначають глобальні ключі.
• Записи списку дозволених зберігаються в локальному для хоста файлі схвалень під 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 у режимі безпечного бінарного файла, тому jq -n env не може вивантажити середовище процесу хоста без явного шляху списку дозволених або запиту на схвалення.

​

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

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

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

Коли потрібні схвалення, інструмент exec негайно повертає id схвалення. Використовуйте цей id, щоб зіставляти пізніші системні події схваленого запуску (Exec finished і Exec running, коли налаштовано). Якщо рішення не надходить до timeout, запит трактується як timeout схвалення й показується як термінальна відмова host-command. Для асинхронних схвалень основного агента з початковою сесією OpenClaw також поновлює цю сесію внутрішнім followup, щоб агент бачив, що команда не запускалася, замість пізнішого виправлення відсутнього результату.

​

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

Після завершення схваленого асинхронного exec OpenClaw надсилає followup agent turn до тієї самої сесії. Відхилені асинхронні схвалення використовують той самий шлях followup основної сесії для статусу відмови, але вони не реєструють підвищені runtime handoffs і не запускають команду. Відмови без поновлюваної основної сесії або пригнічуються, або повідомляються через безпечний прямий маршрут, коли він існує.

• Якщо існує дійсна зовнішня ціль доставки (доставний канал плюс ціль to), доставка followup використовує цей канал.
• У потоках лише webchat або внутрішніх сесій без зовнішньої цілі доставка 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. Увімкнення або вимкнення одного не впливає на інше. Щодо поведінки авторингу Plugin, полів запиту та семантики рішень див. Запити дозволів Plugin. OC_I18N_900003 Форма конфігурації ідентична до approvals.exec: enabled, mode, agentFilter, sessionFilter і targets працюють так само. Канали, що підтримують спільні інтерактивні відповіді, відображають ті самі кнопки схвалення для схвалень exec і Plugin. Канали без спільного інтерактивного UI повертаються до простого тексту з інструкціями /approve. Запити на схвалення Plugin можуть обмежувати доступні рішення. Поверхні схвалення використовують оголошений у запиті набір рішень, а Gateway відхиляє спроби надіслати рішення, якого не було запропоновано.

​

Схвалення в тому самому чаті на будь-якому каналі

Коли запит на схвалення exec або Plugin походить із доставної чат-поверхні, той самий чат тепер може схвалити його за допомогою /approve за замовчуванням. Це стосується таких каналів, як Slack, Matrix і Microsoft Teams, на додачу до наявних потоків Web UI і термінального UI. Цей спільний шлях текстових команд використовує звичайну модель автентифікації каналу для цієї розмови. Якщо початковий чат уже може надсилати команди й отримувати відповіді, запитам на схвалення більше не потрібен окремий нативний адаптер доставлення лише для того, щоб залишатися в очікуванні. Discord і Telegram також підтримують same-chat /approve, але ці канали все одно використовують свій вирішений список схвалювачів для авторизації, навіть коли нативне доставлення схвалень вимкнене. Для Telegram та інших нативних клієнтів схвалень, які викликають Gateway напряму, цей резервний механізм навмисно обмежений помилками “схвалення не знайдено”. Справжня відмова/помилка схвалення exec не повторюється непомітно як схвалення plugin.

​

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

Деякі канали також можуть працювати як нативні клієнти схвалень. Нативні клієнти додають DM схвалювачам, fanout до початкового чату та специфічний для каналу інтерактивний UX схвалення поверх спільного same-chat потоку /approve. Коли доступні нативні картки/кнопки схвалення, цей нативний UI є основним шляхом для агента. Агент не повинен також дублювати просту чат-команду /approve, якщо результат інструмента не каже, що чат-схвалення недоступні або ручне схвалення є єдиним рештою доступним шляхом. Якщо нативний клієнт схвалень налаштовано, але для початкового каналу немає активного нативного runtime, OpenClaw залишає видимим локальний детермінований prompt /approve. Якщо нативний runtime активний і намагається доставити повідомлення, але жодна ціль не отримує картку, OpenClaw надсилає fallback-повідомлення в той самий чат з точною командою /approve <id> <decision>, щоб запит усе ще можна було вирішити. Загальна модель:

• політика host exec і далі вирішує, чи потрібне схвалення exec
• approvals.exec керує пересиланням prompt схвалення до інших чат-призначень
• channels.<channel>.execApprovals керує тим, чи ввімкнені Discord, Slack, Telegram та подібні нативні клієнти, специфічні для каналу
• схвалення Slack plugin можуть використовувати нативний клієнт схвалень Slack, коли запит надходить зі Slack і схвалювачі Slack plugin визначені; approvals.plugin також може маршрутизувати схвалення plugin до Slack сесій або цілей, навіть коли схвалення Slack exec вимкнені
• нативні картки схвалення Google Chat обробляють схвалення exec і plugin, які походять із просторів або threads Google Chat, коли стабільні схвалювачі users/<id> визначаються з dm.allowFrom або defaultTo; вони не використовують події реакцій для рішень
• доставлення схвалень реакціями WhatsApp і Signal керується approvals.exec та approvals.plugin; вони не мають блоків channels.<channel>.execApprovals

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

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

Установіть enabled: false, щоб явно вимкнути нативний клієнт схвалень. Установіть enabled: true, щоб примусово ввімкнути його, коли схвалювачі визначаються. Доставлення до публічного початкового чату лишається явним через channels.<channel>.execApprovals.target. FAQ: Чому існують дві конфігурації схвалення exec для чат-схвалень?

• Discord: channels.discord.execApprovals.*
• Slack: channels.slack.execApprovals.*
• Telegram: channels.telegram.execApprovals.*
• Google Chat: налаштуйте стабільних схвалювачів за допомогою channels.googlechat.dm.allowFrom або channels.googlechat.defaultTo; блок execApprovals не потрібен
• WhatsApp: використовуйте approvals.exec і approvals.plugin, щоб маршрутизувати prompt схвалення до WhatsApp
• Signal: використовуйте approvals.exec і approvals.plugin, щоб маршрутизувати prompt схвалення до Signal

Ці нативні клієнти схвалень додають маршрутизацію DM і необов’язковий channel fanout поверх спільного same-chat потоку /approve і спільних кнопок схвалення. Спільна поведінка:

• Slack, Matrix, Microsoft Teams і подібні доставні чати використовують звичайну модель автентифікації каналу для same-chat /approve
• коли нативний клієнт схвалень автоматично вмикається, типовою нативною ціллю доставлення є DM схвалювачам
• для Discord і Telegram схвалювати або відхиляти можуть лише визначені схвалювачі
• схвалювачі Discord можуть бути явними (execApprovals.approvers) або виведеними з commands.ownerAllowFrom
• схвалювачі Telegram можуть бути явними (execApprovals.approvers) або виведеними з commands.ownerAllowFrom
• схвалювачі Slack можуть бути явними (execApprovals.approvers) або виведеними з commands.ownerAllowFrom
• DM для схвалень Slack plugin використовують схвалювачів Slack plugin з allowFrom і типову маршрутизацію облікового запису, а не схвалювачів Slack exec
• нативні кнопки Slack зберігають тип id схвалення, тому id plugin: можуть вирішувати схвалення plugin без другого Slack-local fallback-шару
• нативні картки Google Chat зберігають ручний fallback /approve у тексті повідомлення, але callbacks кнопок картки передають лише непрозорі токени дій; id схвалення й рішення відновлюються зі стану очікування на боці сервера
• emoji-схвалення WhatsApp обробляють prompt як exec, так і plugin лише коли відповідна top-level forwarding family ввімкнена й маршрутизує до WhatsApp; target-only forwarding WhatsApp лишається на спільному forwarding-шляху, якщо не збігається з тією самою нативною початковою ціллю
• схвалення реакціями Signal обробляють prompt як exec, так і plugin лише коли відповідна top-level forwarding family ввімкнена й маршрутизує до Signal. Прямі same-chat схвалення Signal exec можуть пригнічувати локальний fallback /approve без явних схвалювачів; вирішення реакцій Signal усе ще потребує явних схвалювачів Signal із channels.signal.allowFrom або defaultTo.
• нативна маршрутизація Matrix DM/channel і shortcuts реакцій обробляють як схвалення exec, так і plugin; авторизація plugin усе ще походить із channels.matrix.dm.allowFrom
• нативні prompt Matrix містять кастомний вміст події com.openclaw.approval у першій події prompt, щоб Matrix-клієнти, обізнані з OpenClaw, могли читати структурований стан схвалення, тоді як стандартні клієнти зберігають plain-text fallback /approve
• запитувач не мусить бути схвалювачем
• початковий чат може схвалювати напряму через /approve, коли цей чат уже підтримує команди й відповіді
• нативні кнопки схвалення Discord маршрутизують за типом id схвалення: id plugin: йдуть прямо до схвалень plugin, усе інше йде до схвалень exec
• нативні кнопки схвалення Telegram дотримуються такого самого обмеженого fallback exec-to-plugin, як /approve
• коли нативний target вмикає доставлення до початкового чату, prompt схвалення містять текст команди
• очікувані схвалення exec за замовчуванням спливають через 30 хвилин
• якщо жоден operator UI або налаштований клієнт схвалень не може прийняти запит, prompt fallback переходить до askFallback

Чутливі owner-only групові команди, такі як /diagnostics і /export-trajectory, використовують приватну маршрутизацію власника для prompt схвалення та фінальних результатів. OpenClaw спершу пробує приватний маршрут на тій самій поверхні, де власник запустив команду. Якщо ця поверхня не має приватного маршруту власника, він переходить до першого доступного маршруту власника з commands.ownerAllowFrom, тож групова команда Discord усе ще може надіслати схвалення й результат у Telegram DM власника, коли Telegram є налаштованим основним приватним інтерфейсом. Груповий чат отримує лише коротке підтвердження. Telegram за замовчуванням використовує DM схвалювачам (target: "dm"). Ви можете перемкнутися на channel або both, коли хочете, щоб prompt схвалення також з’являлися в початковому Telegram-чаті/темі. Для форумних тем Telegram OpenClaw зберігає тему для prompt схвалення та follow-up після схвалення. Дивіться:

• Discord
• Telegram

​

macOS IPC flow

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

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

​

FAQ

​

Коли accountId і threadId використовуються в цілі схвалення?

Використовуйте accountId, коли канал має кілька налаштованих ідентичностей і prompt схвалення має вийти через один конкретний обліковий запис. Використовуйте threadId, коли призначення підтримує topics або threads і prompt має залишатися всередині цього thread, а не в top-level чаті. Конкретний випадок Telegram — це operations supergroup з forum topics і двома обліковими записами Telegram bot. Значення to називає supergroup, accountId вибирає bot account, а threadId вибирає forum topic: OC_I18N_900005 З таким налаштуванням переслані схвалення exec публікуються обліковим записом Telegram ops-bot у topic 77 чату -1001234567890. Ціль без accountId використовує типовий обліковий запис каналу, а ціль без threadId публікує в top-level призначення.

​

Коли схвалення надсилаються до сесії, чи може будь-хто в цій сесії їх схвалити?

Ні. Доставлення до сесії лише керує тим, де з’являється prompt. Саме по собі воно не авторизує кожного учасника цього чату на схвалення. Для загального same-chat /approve відправник уже має бути авторизований для команд у цій сесії каналу. Якщо канал надає явних схвалювачів схвалень, ці схвалювачі можуть авторизувати дію /approve, навіть коли вони інакше не авторизовані для команд у цій сесії. Деякі канали суворіші. Discord, Telegram, Matrix, нативні DM схвалень Slack і подібні нативні клієнти схвалень використовують свої визначені списки схвалювачів для авторизації схвалень. Наприклад, prompt схвалення в Telegram forum-topic може бути видимим усім у topic, але лише числові Telegram user IDs, визначені з channels.telegram.execApprovals.approvers або commands.ownerAllowFrom, можуть схвалити або відхилити його.

​

Пов’язане

• Схвалення exec — основна політика та потік схвалення
• Інструмент exec
• Режим підвищених прав
• Skills — поведінка auto-allow на основі skill