> ## Documentation Index
> Fetch the complete documentation index at: https://docs2.openclaw.ai/llms.txt
> Use this file to discover all available pages before exploring further.

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

Расширенные темы подтверждений exec: быстрый путь `safeBins`, привязка интерпретатора/runtime и пересылка подтверждений в чат-каналы (включая нативную доставку).
Основную политику и поток подтверждений см. в [Подтверждения exec](/ru/tools/exec-approvals).

## Безопасные бинарные файлы (только stdin)

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

<Warning>
  **Не** добавляйте бинарные файлы интерпретаторов или runtime (например, `python3`, `node`, `ruby`, `bash`, `sh`, `zsh`) в `safeBins`. Если команда по своей природе может выполнять код, запускать подкоманды или читать файлы, предпочитайте явные записи списка разрешений и оставляйте запросы подтверждения включенными. Пользовательские безопасные бинарные файлы должны задавать явный профиль в `tools.exec.safeBinProfiles.<bin>`.
</Warning>

Безопасные бинарные файлы по умолчанию:

[//]: # "SAFE_BIN_DEFAULTS:START"

`cut`, `uniq`, `head`, `tail`, `tr`, `wc`

[//]: # "SAFE_BIN_DEFAULTS:END"

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

### Проверка argv и запрещенные флаги

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

Запрещенные флаги по профилям безопасных бинарных файлов:

[//]: # "SAFE_BIN_DENIED_FLAGS:START"

* `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`

[//]: # "SAFE_BIN_DENIED_FLAGS:END"

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

### Безопасные бинарные файлы и список разрешений

| Тема               | `tools.exec.safeBins`                                                          | Список разрешений (`exec-approvals.json`)                                                                |
| ------------------ | ------------------------------------------------------------------------------ | -------------------------------------------------------------------------------------------------------- |
| Цель               | Авторазрешение узких фильтров stdin                                            | Явно доверять конкретным исполняемым файлам                                                              |
| Тип сопоставления  | Имя исполняемого файла + политика argv безопасного бинарного файла             | Glob разрешенного пути исполняемого файла или glob голого имени команды для команд, вызванных через PATH |
| Область аргументов | Ограничена профилем безопасного бинарного файла и правилами буквальных токенов | По умолчанию сопоставление пути; необязательный `argPattern` может ограничивать разобранный argv         |
| Типичные примеры   | `head`, `tail`, `tr`, `wc`                                                     | `jq`, `python3`, `node`, `ffmpeg`, пользовательские CLI                                                  |
| Лучшее применение  | Низкорисковые текстовые преобразования в пайплайнах                            | Любой инструмент с более широким поведением или побочными эффектами                                      |

Расположение конфигурации:

* `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](/plugins/plugin-permission-requests).
**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?](/help/faq-first-run#why-are-there-two-exec-approval-configs-for-chat-approvals)

* 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](/channels/discord)
* [Telegram](/channels/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](/ru/tools/exec-approvals) — основная политика и поток подтверждения
* [Инструмент exec](/ru/tools/exec)
* [Режим повышенных прав](/ru/tools/elevated)
* [Skills](/ru/tools/skills) — поведение автоматического разрешения на основе Skills