Підтвердження виконання — розширені налаштування

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

Безпечні виконувані файли (лише stdin)

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

Стандартні безпечні виконувані файли:

cut, uniq, head, tail, tr, wc

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

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

Перевірка детерміновано виконується лише за формою argv (без перевірок існування файлів у файловій системі хоста), що запобігає використанню відмінностей між дозволом і забороною як оракула існування файлів. Для стандартних безпечних виконуваних файлів заборонено параметри, орієнтовані на файли; довгі параметри перевіряються за принципом безпечної відмови (невідомі прапорці та неоднозначні скорочення відхиляються). Розпізнані булеві прапорці лише для читання стандартних виконуваних файлів (наприклад, wc -l, tr -d, uniq -c) приймаються, а нерозпізнані короткі прапорці відхиляються за принципом безпечної відмови й передаються на ручне схвалення.

Заборонені прапорці за профілями безпечних виконуваних файлів:

• 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
• tail: --follow, --retry, -F, -f
• wc: --files0-from

Безпечні виконувані файли також примусово трактують токени argv як буквальний текст під час виконання (без розгортання шаблонів і без розгортання $VARS) для сегментів лише зі stdin, тому шаблони на кшталт * або $HOME/... не можна використати для прихованого читання файлів. awk, sed і jq завжди заборонені як безпечні виконувані файли, оскільки неможливо перевірити, що їхня семантика обмежується stdin: jq може читати дані середовища та завантажувати код jq з модулів або файлів запуску. Для цих інструментів використовуйте явний запис у списку дозволів або запит на схвалення замість safeBins.

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

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

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

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

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

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

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

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

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

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

• 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> як {} (після цього перегляньте й посильте обмеження). Виконувані файли інтерпретаторів/середовищ виконання автоматично не створюються.

Приклад користувацького профілю:

{  tools: {    exec: {      safeBins: ["myfilter"],      safeBinProfiles: {        myfilter: {          minPositional: 0,          maxPositional: 0,          allowedValueFlags: ["-n", "--limit"],          deniedFlags: ["-f", "--file", "-c", "--command"],        },      },    },  },}

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

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

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

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

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

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

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

Пересилання схвалень до каналів чату

Запити на схвалення виконання можна пересилати до будь-якого каналу чату (включно з каналами Plugin) і схвалювати їх за допомогою /approve. Для цього використовується звичайний конвеєр вихідної доставки.

Конфігурація:

{  approvals: {    exec: {      enabled: true,      mode: "session", // "session" | "targets" | "both"      agentFilter: ["main"],      sessionFilter: ["discord"], // substring or regex      targets: [        { channel: "slack", to: "U12345678" },        { channel: "telegram", to: "123456789" },      ],    },  },}

Відповідь у чаті:

/approve <id> allow-once/approve <id> allow-always/approve <id> deny

Команда /approve обробляє як схвалення виконання, так і схвалення плагінів. Якщо ідентифікатор не відповідає схваленню виконання, що очікує на розгляд, вона автоматично перевіряє натомість схвалення плагінів. Цей резервний механізм обмежений помилками «схвалення не знайдено»; фактична відмова чи помилка схвалення виконання не спричиняє непомітної повторної спроби як схвалення плагіна.

Переспрямування схвалень плагінів

Переспрямування схвалень плагінів використовує той самий конвеєр доставлення, що й схвалення виконання, але має власну незалежну конфігурацію в approvals.plugin. Увімкнення або вимкнення одного не впливає на інше. Відомості про поведінку під час розроблення плагінів, поля запитів і семантику рішень див. у розділі Запити плагінів на дозволи.

{  approvals: {    plugin: {      enabled: true,      mode: "targets",      agentFilter: ["main"],      targets: [        { channel: "slack", to: "U12345678" },        { channel: "telegram", to: "123456789" },      ],    },  },}

Структура конфігурації ідентична approvals.exec: enabled, mode, agentFilter, sessionFilter і targets працюють так само.

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

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

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

Discord, Telegram і QQ bot також підтримують /approve у тому самому чаті, але ці канали й надалі використовують свій визначений список осіб, уповноважених схвалювати, для авторизації, навіть якщо нативне доставлення схвалень вимкнено.

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

Деякі канали також можуть діяти як нативні клієнти схвалення: Discord, Slack, Telegram, Matrix і QQ bot. Нативні клієнти додають приватні повідомлення особам, уповноваженим схвалювати, розсилання у вихідний чат і специфічний для каналу інтерактивний інтерфейс схвалення поверх спільного потоку /approve у тому самому чаті.

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

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

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

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

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

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

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

Поширене запитання: Чому існують дві конфігурації схвалення виконання для схвалень у чаті?

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

Маршрутизація, специфічна для нативних клієнтів:

• Telegram за замовчуванням використовує приватні повідомлення особам, уповноваженим схвалювати (target: "dm"). Перейдіть на channel або both, щоб також показувати запрошення до схвалення у вихідному чаті або темі Telegram. Для тем форуму Telegram OpenClaw зберігає тему для запрошення до схвалення та подальшого повідомлення після схвалення.
• Осіб, уповноважених схвалювати в Discord і Telegram, можна вказати явно (execApprovals.approvers) або визначити з commands.ownerAllowFrom; схвалювати або відхиляти можуть лише визначені особи.
• Осіб, уповноважених схвалювати в Slack, можна вказати явно (execApprovals.approvers) або визначити з commands.ownerAllowFrom. Приватні повідомлення про схвалення плагінів Slack використовують осіб, уповноважених схвалювати плагіни Slack, з allowFrom і типову маршрутизацію облікового запису, а не осіб, уповноважених схвалювати виконання в Slack. Нативні кнопки Slack зберігають тип ідентифікатора схвалення, тому ідентифікатори plugin: можуть вирішувати схвалення плагінів без другого локального резервного рівня Slack.
• Нативні картки Google Chat зберігають ручний резервний варіант /approve у тексті повідомлення, але зворотні виклики кнопок картки передають лише непрозорі маркери дій; ідентифікатор схвалення та рішення відновлюються зі стану очікування на сервері.
• Схвалення за допомогою емодзі WhatsApp обробляють запрошення як для виконання, так і для плагінів, коли відповідне сімейство переспрямування верхнього рівня спрямовує їх у WhatsApp. Запрошення з нативного джерела прив'язуються безпосередньо; доставлення у спільному режимі цілей прив'язує ті самі типізовані метадані схвалення до підтвердження отримання повідомлення WhatsApp.
• Схвалення реакціями Signal обробляють запрошення як для виконання, так і для плагінів, лише коли відповідне сімейство переспрямування верхнього рівня ввімкнено й спрямовує їх у Signal. Прямі схвалення виконання Signal у тому самому чаті можуть приховувати локальний резервний варіант /approve без явно вказаних осіб, уповноважених схвалювати; для вирішення через реакції Signal усе одно потрібні явно вказані особи, уповноважені схвалювати в Signal, з channels.signal.allowFrom або defaultTo.
• Нативна маршрутизація Matrix у приватні повідомлення або канали та швидкі дії реакціями обробляють схвалення як виконання, так і плагінів; авторизація плагінів і надалі надходить із channels.matrix.dm.allowFrom. Нативні запрошення Matrix містять вміст користувацької події com.openclaw.approval у першій події запрошення, щоб клієнти Matrix, сумісні з OpenClaw, могли читати структурований стан схвалення, а стандартні клієнти зберігали текстовий резервний варіант /approve.
• Нативні кнопки схвалення Discord і Telegram передають явний тип власника — виконання або плагін — у приватних для транспорту даних зворотного виклику та вирішують запит лише для цього власника. Старі елементи керування /approve, що не мають типу, залишаються обмеженим шляхом сумісності: вони перевіряють лише ті типи власників, для яких суб'єкт може схвалювати, продовжують лише після результату «схвалення не знайдено» й ніколи не визначають власника з ідентифікатора схвалення.
• Особа, яка подала запит, не мусить бути уповноваженою схвалювати.
• Якщо жоден операторський інтерфейс або налаштований клієнт схвалення не може прийняти запит, запрошення переходить до askFallback.

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

Див.:

• Discord
• Telegram
• QQ bot

Офіційні мобільні операторські застосунки

Офіційні застосунки для iOS і Android також можуть переглядати схвалення виконання, що очікують на розгляд і належать Gateway, коли використовується з'єднання operator.admin або коли запит явно спрямовано на їхній спарений пристрій operator.approvals. Вони читають той самий очищений довговічний запис, який використовує інтерфейс керування, надсилають рішення з урахуванням типу та відображають канонічний результат першої відповіді від Gateway. Apple Watch віддзеркалює ці запрошення до схвалення через спарений iPhone, надаючи дії одноразового дозволу та відмови. Прямий режим Gateway на Watch не дає змоги переглядати схвалення.

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

Потік IPC у macOS

Gateway -> Служба Node (WS)                 |  IPC (UDS + токен + HMAC + TTL)                 v             Застосунок Mac (інтерфейс + схвалення + system.run)

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

• Режим сокета Unix 0600, токен зберігається в exec-approvals.json.
• Перевірка однорангового процесу з тим самим UID.
• Виклик-відповідь (одноразове значення + токен HMAC + хеш запиту) + короткий TTL.

Поширені запитання

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

Використовуйте accountId, коли канал має кілька налаштованих ідентичностей і запрошення до схвалення має надсилатися через один конкретний обліковий запис. Використовуйте threadId, коли місце призначення підтримує теми або ланцюжки й запрошення має залишатися в цьому ланцюжку, а не в чаті верхнього рівня.

Конкретний приклад для Telegram — операційна супергрупа з темами форуму та двома обліковими записами ботів Telegram. Значення to визначає супергрупу, accountId вибирає обліковий запис бота, а threadId вибирає тему форуму:

{  approvals: {    exec: {      enabled: true,      mode: "targets",      targets: [        {          channel: "telegram",          to: "-1001234567890",          accountId: "ops-bot",          threadId: "77",        },      ],    },  },  channels: {    telegram: {      accounts: {        default: {          name: "Primary bot",          botToken: "env:TELEGRAM_PRIMARY_BOT_TOKEN",        },        "ops-bot": {          name: "Operations bot",          botToken: "env:TELEGRAM_OPS_BOT_TOKEN",        },      },    },  },}

За такого налаштування переспрямовані схвалення виконання публікуються обліковим записом Telegram ops-bot у темі 77 чату -1001234567890. Ціль без accountId використовує типовий обліковий запис каналу, а ціль без threadId публікує повідомлення в місці призначення верхнього рівня.

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

Ні. Доставка до сеансу лише визначає, де з’являється запит. Вона сама по собі не надає кожному учаснику цього чату права схвалювати.

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

Деякі канали мають суворіші правила. Власні приватні повідомлення для схвалення в Discord, Telegram, Matrix і Slack, а також подібні власні клієнти схвалення використовують свої визначені списки уповноважених осіб для авторизації схвалення. Наприклад, запит на схвалення в темі форуму Telegram може бути видимим усім учасникам теми, але схвалити або відхилити його можуть лише користувачі з числовими ідентифікаторами Telegram, визначеними з channels.telegram.execApprovals.approvers або commands.ownerAllowFrom.

Пов’язані матеріали

• Схвалення виконання — основна політика та процес схвалення
• Інструмент виконання
• Режим підвищених привілеїв
• Skills — поведінка автоматичного дозволу на основі навичок