Утверждения выполнения — расширенные

Расширенные темы подтверждений exec: быстрый путь safeBins, привязка интерпретатора/runtime и пересылка подтверждений в чат-каналы (включая нативную доставку). Основную политику и поток подтверждений см. в Подтверждения 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, когда бинарные файлы интерпретатора/runtime появляются в safeBins без явных профилей.
• openclaw doctor --fix может создать отсутствующие пользовательские записи safeBinProfiles.<bin> как {} (после этого проверьте и ужесточите). Бинарные файлы интерпретатора/runtime автоматически не создаются.

Пример пользовательского профиля: OC_I18N_900000 Если вы явно включаете jq в safeBins, OpenClaw все равно отклоняет builtin env в режиме безопасного бинарного файла, чтобы jq -n env не мог вывести окружение хост-процесса без явного пути списка разрешений или запроса подтверждения.

Команды интерпретатора/runtime

Запуски интерпретатора/runtime с подтверждением намеренно консервативны:

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

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

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

После завершения одобренного асинхронного exec OpenClaw отправляет followup-ход agent в ту же сессию. Отклоненные асинхронные подтверждения используют тот же путь 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 также поддерживают /approve в том же чате, но эти каналы по-прежнему используют свой разрешенный список одобряющих для авторизации, даже когда нативная доставка одобрений отключена.

Для Telegram и других нативных клиентов одобрений, которые вызывают Gateway напрямую, этот резервный путь намеренно ограничен сбоями "одобрение не найдено". Реальный отказ/ошибка одобрения exec не повторяется незаметно как одобрение Plugin.

Нативная доставка одобрений

Некоторые каналы также могут выступать как нативные клиенты одобрений. Нативные клиенты добавляют личные сообщения одобряющим, рассылку в исходный чат и интерактивный UX одобрения, специфичный для канала, поверх общего потока /approve в том же чате.

Когда доступны нативные карточки/кнопки одобрения, этот нативный UI является основным путем для агента. Агент не должен также дублировать обычную чат-команду /approve, если результат инструмента не говорит, что чат-одобрения недоступны или ручное одобрение остается единственным возможным путем.

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

Общая модель:

• политика exec хоста по-прежнему решает, требуется ли одобрение exec
• approvals.exec управляет пересылкой запросов на одобрение в другие чат-направления
• channels.<channel>.execApprovals управляет тем, включены ли Discord, Slack, Telegram и похожие нативные клиенты, специфичные для канала
• одобрения Plugin Slack могут использовать нативный клиент одобрений Slack, когда запрос поступает из Slack и одобряющие Plugin Slack разрешаются; approvals.plugin также может направлять одобрения Plugin в Slack sessions или targets, даже когда одобрения exec Slack отключены
• нативные карточки одобрения Google Chat обрабатывают одобрения exec и Plugin, которые исходят из пространств или веток 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.

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, чтобы направлять запросы на одобрение в WhatsApp
• Signal: используйте approvals.exec и approvals.plugin, чтобы направлять запросы на одобрение в Signal

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

Общее поведение:

• Slack, Matrix, Microsoft Teams и похожие доставляемые чаты используют обычную модель авторизации канала для /approve в том же чате
• когда нативный клиент одобрений автоматически включается, целью нативной доставки по умолчанию являются личные сообщения одобряющим
• для Discord и Telegram одобрять или отклонять могут только разрешенные одобряющие
• одобряющие Discord могут быть явными (execApprovals.approvers) или выведенными из commands.ownerAllowFrom
• одобряющие Telegram могут быть явными (execApprovals.approvers) или выведенными из commands.ownerAllowFrom
• одобряющие Slack могут быть явными (execApprovals.approvers) или выведенными из commands.ownerAllowFrom
• личные сообщения с одобрениями Plugin Slack используют одобряющих Plugin Slack из allowFrom и маршрутизацию аккаунта по умолчанию, а не одобряющих exec Slack
• нативные кнопки Slack сохраняют тип идентификатора одобрения, поэтому идентификаторы plugin: могут разрешать одобрения Plugin без второго резервного слоя, локального для Slack
• нативные карточки Google Chat сохраняют ручной резервный путь /approve в тексте сообщения, но обратные вызовы кнопок карточки передают только непрозрачные токены действий; идентификатор одобрения и решение восстанавливаются из серверного ожидающего состояния
• одобрения emoji WhatsApp обрабатывают запросы exec и Plugin только когда соответствующее верхнеуровневое семейство пересылки включено и маршрутизируется в WhatsApp; пересылка WhatsApp только в target остается на общем пути пересылки, если она не совпадает с той же нативной исходной целью
• одобрения реакциями Signal обрабатывают запросы exec и Plugin только когда соответствующее верхнеуровневое семейство пересылки включено и маршрутизируется в Signal. Прямые одобрения exec Signal в том же чате могут подавлять локальный резервный путь /approve без явных одобряющих; разрешение реакций Signal по-прежнему требует явных одобряющих Signal из channels.signal.allowFrom или defaultTo.
• нативная маршрутизация личных сообщений/каналов Matrix и сокращения реакций обрабатывают одобрения exec и Plugin; авторизация Plugin по-прежнему берется из channels.matrix.dm.allowFrom
• нативные запросы Matrix включают пользовательское содержимое события com.openclaw.approval в первом событии запроса, чтобы Matrix-клиенты, понимающие OpenClaw, могли читать структурированное состояние одобрения, а обычные клиенты сохраняли текстовый резервный путь /approve
• запрашивающему не нужно быть одобряющим
• исходный чат может одобрять напрямую с помощью /approve, когда этот чат уже поддерживает команды и ответы
• нативные кнопки одобрения Discord маршрутизируют по типу идентификатора одобрения: идентификаторы plugin: идут напрямую в одобрения Plugin, все остальное идет в одобрения exec
• нативные кнопки одобрения Telegram используют тот же ограниченный резервный переход от exec к Plugin, что и /approve
• когда нативный target включает доставку в исходный чат, запросы на одобрение включают текст команды
• ожидающие одобрения exec по умолчанию истекают через 30 минут
• если ни операторский UI, ни настроенный клиент одобрений не могут принять запрос, запрос возвращается к askFallback

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

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

См.:

• Discord
• Telegram

Поток IPC в macOS

OC_I18N_900004 Примечания по безопасности:

• Режим Unix-сокета 0600, токен хранится в exec-approvals.json.
• Проверка одноранговой стороны с тем же UID.
• Challenge/response (nonce + токен HMAC + хэш запроса) + короткий TTL.

FAQ

Когда accountId и threadId используются в цели подтверждения?

Используйте accountId, когда у канала настроено несколько идентичностей и запрос на подтверждение должен отправляться через конкретную учетную запись. Используйте threadId, когда назначение поддерживает темы или треды и запрос должен оставаться внутри этого треда, а не в чате верхнего уровня.

Конкретный пример Telegram — операционная супергруппа с форумными темами и двумя учетными записями ботов Telegram. Значение to указывает супергруппу, accountId выбирает учетную запись бота, а threadId выбирает форумную тему: OC_I18N_900005 При такой настройке пересланные подтверждения exec публикуются учетной записью Telegram ops-bot в тему 77 чата -1001234567890. Цель без accountId использует учетную запись канала по умолчанию, а цель без threadId публикует в назначение верхнего уровня.

Когда подтверждения отправляются в сеанс, может ли любой участник этого сеанса подтвердить их?

Нет. Доставка в сеанс управляет только тем, где появляется запрос. Сама по себе она не разрешает каждому участнику этого чата подтверждать.

Для универсального /approve в том же чате отправитель уже должен быть авторизован для команд в этом сеансе канала. Если канал предоставляет явных утверждающих для подтверждений, эти утверждающие могут авторизовать действие /approve, даже если в остальном они не авторизованы для команд в этом сеансе.

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

Связанные материалы

• Подтверждения exec — основная политика и поток подтверждения
• Инструмент exec
• Режим повышенных прав
• Skills — поведение автоматического разрешения на основе Skills