---
read_when:
    - Настройка безопасных корзин или пользовательских профилей безопасных корзин
    - Пересылка подтверждений в Slack/Discord/Telegram или другие каналы чата
    - Реализация нативного клиента одобрений для канала
summary: 'Расширенные подтверждения выполнения команд: безопасные бинарные файлы, привязка интерпретатора, пересылка подтверждений, нативная доставка'
title: Утверждения выполнения — расширенные
x-i18n:
    generated_at: "2026-06-28T23:51:36Z"
    model: gpt-5.5
    postprocess_version: locale-links-v1
    provider: openai
    source_hash: 3d936e1a1567d204981eec7c3262cf11f2af8fc1ed6213182954c2324718a270
    source_path: tools/exec-approvals-advanced.md
    workflow: 16
---

Расширенные темы подтверждений 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