English简体中文繁體中文日本語EspañolPortuguês (BR)한국어DeutschFrançaisالعربيةItalianoTiếng ViệtNederlandsTürkçeУкраїнськаBahasa IndonesiaPolskiفارسیไทย

Tools

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

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

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

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

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

cut, uniq, head, tail, tr, wc

grep і sort не входять до типового списку. Якщо ви явно вмикаєте їх, залишайте явні записи allowlist для їхніх сценаріїв не зі 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 (&&, ||, ;) дозволені, коли кожен сегмент верхнього рівня задовольняє allowlist (включно з безпечними бінарними файлами або автоматичним дозволом 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 безпечного бінарного файлу Glob розв’язаного шляху виконуваного файлу або glob голого імені команди для команд, викликаних через PATH
Область аргументів Обмежена профілем безпечного бінарного файлу та правилами літеральних токенів За замовчуванням збіг за шляхом; необов’язковий argPattern може обмежити розібраний argv
Типові приклади head, tail, tr, wc jq, python3, node, ffmpeg, користувацькі CLI
Найкраще використання Низькоризикові текстові перетворення в конвеєрах Будь-який інструмент із ширшою поведінкою або побічними ефектами

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

  • safeBins надходить із конфігурації (tools.exec.safeBins або per-agent agents.list[].tools.exec.safeBins).
  • safeBinTrustedDirs надходить із конфігурації (tools.exec.safeBinTrustedDirs або per-agent agents.list[].tools.exec.safeBinTrustedDirs).
  • safeBinProfiles надходить із конфігурації (tools.exec.safeBinProfiles або per-agent agents.list[].tools.exec.safeBinProfiles). Ключі профілю per-agent перевизначають глобальні ключі.
  • Записи 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 у режимі безпечного бінарного файлу, щоб jq -n env не міг вивантажити середовище процесу хоста без явного шляху allowlist або запиту на затвердження.

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

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

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

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

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

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

  • Якщо існує дійсна зовнішня ціль доставки (deliverable channel плюс target to), followup delivery використовує цей канал.
  • У webchat-only або внутрішніх session flows без зовнішньої цілі followup delivery залишається лише в сесії (deliver: false).
  • Якщо caller явно запитує сувору зовнішню доставку без розв’язуваного зовнішнього каналу, запит завершується помилкою INVALID_REQUEST.
  • Якщо bestEffortDeliver увімкнено й зовнішній канал неможливо розв’язати, доставка понижується до session-only замість помилки.

Пересилання затверджень до чат-каналів

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

Конфігурація: 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. Запити затвердження Plugin можуть обмежувати доступні рішення. Поверхні затвердження використовують оголошений набор рішень запиту, а Gateway відхиляє спроби надіслати рішення, яке не було запропоноване.

Затвердження в тому самому чаті на будь-якому каналі

Коли запит затвердження exec або Plugin походить із доставної чат-поверхні, той самий чат тепер може затвердити його через /approve за замовчуванням. Це застосовується до каналів, як-от Slack, Matrix і Microsoft Teams, на додачу до наявних потоків Web UI і terminal UI.

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

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

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

Нативна доставка затверджень

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

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

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

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

  • політика виконання хоста й надалі вирішує, чи потрібне затвердження exec
  • approvals.exec керує пересиланням запитів затвердження до інших чат-призначень
  • 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.*

Ці нативні клієнти затвердження додають маршрутизацію DM і необов’язкове розсилання в канал поверх спільного потоку /approve у тому самому чаті та спільних кнопок затвердження.

Спільна поведінка:

  • Slack, Matrix, Microsoft Teams і подібні доставні чати використовують звичайну модель автентифікації каналу для /approve у тому самому чаті
  • коли нативний клієнт затвердження вмикається автоматично, стандартною нативною ціллю доставки є DM затверджувачів
  • для Discord і Telegram лише визначені затверджувачі можуть затвердити або відхилити
  • затверджувачі Discord можуть бути явними (execApprovals.approvers) або виведеними з commands.ownerAllowFrom
  • затверджувачі Telegram можуть бути явними (execApprovals.approvers) або виведеними з commands.ownerAllowFrom
  • затверджувачі 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

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

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

Дивіться:

Потік IPC у macOS

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

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

Пов’язане