--- read_when: - Настройка подтверждений выполнения или списков разрешений - Реализация интерфейса подтверждения выполнения команд в приложении для macOS - Анализ промптов для выхода из песочницы и их последствий sidebarTitle: Exec approvals summary: 'Подтверждения выполнения команд на хосте: параметры политики, списки разрешений и рабочий процесс YOLO/strict' title: Подтверждения выполнения команд x-i18n: generated_at: "2026-07-13T18:48:44Z" model: gpt-5.6 postprocess_version: locale-links-v1 prompt_version: 24 provider: openai source_hash: b44efdfe5a6c9f3cc978baef91d80d1f75d39627d3a16f5971800809a642a72c source_path: tools/exec-approvals.md workflow: 16 --- Подтверждения выполнения — это **защитный механизм приложения-компаньона / хоста Node**, позволяющий изолированному агенту запускать команды на реальном хосте (`gateway` или `node`). Команды выполняются, только если политика, список разрешений и необязательное подтверждение пользователя согласованы. Подтверждения применяются **поверх** политики инструментов и проверки повышенных привилегий (повышенный режим `full` обходит их). Обзор режимов `deny`, `allowlist`, `ask`, `auto`, `full`, сопоставления Codex Guardian и разрешений среды ACPX см. в разделе [Режимы разрешений](/ru/tools/permission-modes). Эффективной является **более строгая** из политики `tools.exec.*` и значений подтверждений по умолчанию: подтверждения могут только ужесточать параметры безопасности и запросов, полученные из конфигурации, но не ослаблять их. Если поле подтверждений не указано, используется значение `tools.exec`. Выполнение на хосте также учитывает локальное состояние подтверждений на этом компьютере: локальное для хоста значение `ask: "always"` в файле подтверждений хоста выполнения продолжает запрашивать подтверждение, даже если значения сеанса или конфигурации по умолчанию задают `ask: "on-miss"`. ## Область применения Подтверждения выполнения применяются локально на хосте выполнения: - **Хост Gateway** -> процесс `openclaw` на компьютере Gateway. - **Хост Node** -> исполнитель Node (приложение-компаньон macOS или безголовый хост Node). ### Модель доверия - Вызывающие стороны, прошедшие аутентификацию Gateway, считаются доверенными операторами этого Gateway. - Сопряжённые узлы распространяют возможности доверенного оператора на хост Node. - Подтверждения снижают риск случайного выполнения, но **не** являются границей аутентификации отдельных пользователей или политикой доступа к файловой системе только для чтения. - После подтверждения команда может изменять файлы в соответствии с выбранными разрешениями файловой системы хоста или песочницы. - Подтверждённые запуски на хосте Node привязываются к каноническому контексту выполнения: рабочему каталогу, точному массиву аргументов, привязке окружения при её наличии и зафиксированному пути к исполняемому файлу, когда это применимо. - Для сценариев оболочки и прямых вызовов файлов интерпретатором или средой выполнения OpenClaw также пытается привязать один конкретный локальный файловый операнд. Если этот файл изменится после подтверждения, но до выполнения, запуск будет отклонён вместо выполнения изменившегося содержимого. - Привязка файла выполняется по мере возможности и не является полной моделью всех путей загрузки интерпретаторов и сред выполнения. Если невозможно определить ровно один конкретный локальный файл, OpenClaw отказывается создавать запуск на основе подтверждения, а не имитирует полное покрытие. ### Разделение ответственности в macOS - **Служба хоста Node** пересылает `system.run` в **приложение macOS** через локальный IPC. - **Приложение macOS** применяет подтверждения и выполняет команду в контексте пользовательского интерфейса. ## Просмотр эффективной политики | Команда | Что она показывает | | ---------------------------------------------------------------- | -------------------------------------------------------------------------------------- | | `openclaw approvals get` / `--gateway` / `--node ` | Запрошенную политику, источники политики хоста и эффективный результат. | | `openclaw exec-policy show` | Объединённое представление для локального компьютера. | | `openclaw exec-policy set` / `preset` | Одноэтапную синхронизацию локальной запрошенной политики с локальным файлом подтверждений хоста. | Переопределения `/exec` для отдельных сеансов не включены. Выполните `/exec` в соответствующем сеансе, чтобы просмотреть его текущие значения по умолчанию. См. [переопределения сеанса](/ru/tools/exec#session-overrides-exec). Полный справочник CLI (флаги, вывод JSON, добавление и удаление элементов списка разрешений): [CLI подтверждений](/ru/cli/approvals). Когда локальная область запрашивает `host=node`, `exec-policy show` сообщает, что во время выполнения эта область управляется узлом, вместо того чтобы считать локальный файл подтверждений источником истины. Если пользовательский интерфейс приложения-компаньона **недоступен**, любой запрос, который обычно требовал бы подтверждения, обрабатывается согласно **резервному режиму запроса** (по умолчанию: `deny`). Нативные клиенты подтверждений в чатах могут добавлять зависящие от канала средства взаимодействия к сообщению об ожидающем подтверждении. Matrix добавляет быстрые реакции (`✅` — разрешить один раз, `♾️` — разрешать всегда, `❌` — отклонить), сохраняя `/approve ...` в сообщении как резервный вариант. ## Настройки и хранение Подтверждения хранятся в локальном файле JSON на хосте выполнения. Когда задана переменная `OPENCLAW_STATE_DIR`, файл размещается в указанном ею каталоге состояния; в противном случае используется стандартный каталог состояния OpenClaw: ```text $OPENCLAW_STATE_DIR/exec-approvals.json # в противном случае ~/.openclaw/exec-approvals.json ``` Стандартный сокет подтверждений использует тот же корневой каталог: `$OPENCLAW_STATE_DIR/exec-approvals.sock` или `~/.openclaw/exec-approvals.sock`, если переменная не задана. В выпусках до 2026.6.6 файл всегда хранился в `~/.openclaw`. Если `OPENCLAW_STATE_DIR` указывает на другое расположение, а файл подтверждений всё ещё существует в стандартном каталоге, один раз напрямую выполните `openclaw doctor --fix`, чтобы импортировать его в каталог состояния (исходный файл архивируется с суффиксом `.migrated`). Интерактивный doctor также позволяет предварительно просмотреть и подтвердить импорт. Автоматические обновления и запуски восстановления наблюдателем Gateway никогда не импортируют данные между каталогами состояния: временный или промежуточный каталог состояния не должен перехватывать подтверждения стандартной установки. Та же граница применяется к импорту устаревших данных `plugin-binding-approvals.json` в общее состояние SQLite. Пример схемы: ```json { "version": 1, "socket": { "path": "~/.openclaw/exec-approvals.sock", "token": "base64url-token" }, "defaults": { "security": "deny", "ask": "on-miss", "askFallback": "deny", "autoAllowSkills": false }, "agents": { "main": { "security": "allowlist", "ask": "on-miss", "askFallback": "deny", "autoAllowSkills": true, "allowlist": [ { "id": "B0C8C0B3-2C2D-4F8A-9A3C-5A4B3C2D1E0F", "pattern": "~/Projects/**/bin/rg", "source": "allow-always", "lastUsedAt": 1737150000000, "lastUsedCommand": "rg -n TODO", "lastResolvedPath": "/Users/user/Projects/.../bin/rg" } ] } } } ``` ## Параметры политики ### `tools.exec.mode` `tools.exec.mode` — предпочтительный нормализованный интерфейс политики для выполнения на хосте: | Значение | Поведение | | ----------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `deny` | Блокировать выполнение на хосте. | | `allowlist` | Выполнять без запроса только команды из списка разрешений. | | `ask` | Использовать политику списка разрешений и запрашивать подтверждение при несовпадении. | | `auto` | Использовать политику списка разрешений, напрямую выполнять детерминированные совпадения, а при несовпадениях отправлять запрос нативному автоматическому рецензенту OpenClaw, прежде чем переходить к подтверждению человеком. | | `full` | Выполнять команды на хосте без запросов подтверждения. | Устаревшие `tools.exec.security` / `tools.exec.ask` по-прежнему поддерживаются и применяются везде, где `mode` не задан для соответствующей области. ### `exec.security` - `deny` — блокировать все запросы выполнения на хосте. - `allowlist` — разрешать только команды из списка разрешений. - `full` — разрешать всё (эквивалентно повышенному режиму). Значение по умолчанию для хостов Gateway/Node — `full`; для хоста `sandbox` по умолчанию вместо него используется `deny`. ### `exec.ask` Настроенная политика запросов для выполнения на хосте. Управляет базовым поведением запросов подтверждения из `tools.exec.ask` и стандартных настроек подтверждений хоста. Значение по умолчанию — `off`. Параметр инструмента `ask` для отдельного вызова (см. [Инструмент выполнения](/ru/tools/exec#parameters)) может только ужесточить эту базовую политику, а вызовы модели из каналов игнорируют его, когда эффективное значение запроса хоста — `off`. - `off` — никогда не запрашивать подтверждение. - `on-miss` — запрашивать подтверждение только при отсутствии совпадения со списком разрешений. - `always` — запрашивать подтверждение для каждой команды. Постоянное доверие `allow-always` **не** подавляет запросы, когда эффективный режим запроса — `always`. ### `askFallback` Способ обработки, когда подтверждение необходимо, но пользовательский интерфейс недоступен или время ожидания запроса истекло. Если значение не указано, по умолчанию используется `deny`. - `deny` — блокировать. - `allowlist` — разрешать только при совпадении со списком разрешений. - `full` — разрешать. ### `tools.exec.strictInlineEval` Когда задано `true`, формы встроенного вычисления кода требуют подтверждения, даже если сам исполняемый файл интерпретатора находится в списке разрешений. Это дополнительная эшелонированная защита для загрузчиков интерпретаторов, которые невозможно однозначно сопоставить с одним неизменным файловым операндом. Примеры, которые выявляет строгий режим: `python -c`, `node -e`/`--eval`/`-p`, `ruby -e`, `perl -e`/`-E`, `php -r`, `lua -e`, `osascript -e` (а также встроенные формы `awk`, `sed`, `make`, `find -exec` и `xargs`). В строгом режиме эти команды требуют проверки рецензентом или явного подтверждения. При `tools.exec.mode: "auto"` рецензент может разрешить одно выполнение с низким риском, если для команды существует принудительно исполняемый план; в противном случае OpenClaw запрашивает подтверждение человека. Подтверждения команд `Codex app-server`, переданные резервному рецензенту, требуют участия человека, поскольку их запросы подтверждения не предоставляют принудительно исполняемый разрешённый исполняемый файл. `allow-always` не сохраняет новые элементы списка разрешений для команд со встроенным вычислением. ### `tools.exec.commandHighlighting` Влияет только на отображение: когда параметр включён, OpenClaw может прикреплять определённые синтаксическим анализатором диапазоны команд, чтобы веб-интерфейс подтверждения мог выделять токены команд. Это **не** изменяет `security`, `ask`, сопоставление со списком разрешений, поведение строгого встроенного вычисления, пересылку подтверждений или выполнение команд. Задайте параметр глобально в `tools.exec.commandHighlighting` или для отдельного агента в `agents.list[].tools.exec.commandHighlighting`. ## Режим YOLO (без подтверждений) Чтобы выполнять команды на хосте без запросов подтверждения, откройте **оба** уровня политики: запрошенную политику выполнения в конфигурации OpenClaw (`tools.exec.*`) **и** локальную политику подтверждений в файле подтверждений хоста выполнения. Если `askFallback` не указано, по умолчанию используется `deny`. Явно задайте для хоста `askFallback` значение `full`, если при отсутствии пользовательского интерфейса запрос подтверждения должен резервно разрешать выполнение. | Уровень | Настройка YOLO | | --------------------- | -------------------------- | | `tools.exec.security` | `full` для `gateway`/`node` | | `tools.exec.ask` | `off` | | Хост `askFallback` | `full` | **Важные различия:** - `tools.exec.host=auto` определяет, **где** выполняется exec: в песочнице, если она доступна, иначе — на Gateway. - YOLO определяет, **как** одобряется выполнение на хосте: `security=full` вместе с `ask=off`. - YOLO **не** добавляет поверх настроенной политики выполнения на хосте отдельную эвристическую проверку одобрения обфусцированных команд или уровень предварительного отклонения скриптов. - `auto` не превращает маршрутизацию через Gateway в свободно переопределяемый параметр из сеанса в песочнице. Запрос `host=node` для отдельного вызова разрешён из `auto`; `host=gateway` разрешён из `auto` только при отсутствии активной среды выполнения песочницы. Чтобы задать стабильное значение по умолчанию без автоматического выбора, установите `tools.exec.host` или явно используйте `/exec host=...`. Провайдеры на базе CLI, предоставляющие собственный неинтерактивный режим разрешений, могут следовать этой политике. Claude CLI добавляет `--permission-mode bypassPermissions`, когда фактическая политика exec OpenClaw имеет значение YOLO. Для управляемых OpenClaw интерактивных сеансов Claude фактическая политика exec OpenClaw имеет приоритет над собственным режимом разрешений Claude: YOLO нормализует запуск интерактивных сеансов до `--permission-mode bypassPermissions`, а ограничительная фактическая политика exec нормализует запуск интерактивных сеансов до `--permission-mode default`, даже если необработанные аргументы бэкенда Claude задают другой режим. Если вам нужна более консервативная конфигурация, снова ужесточите политику exec OpenClaw до `allowlist` / `on-miss` или `deny`. ### Постоянная настройка «никогда не запрашивать» для хоста Gateway ```bash openclaw config set tools.exec.host gateway openclaw config set tools.exec.security full openclaw config set tools.exec.ask off openclaw gateway restart ``` ```bash openclaw approvals set --stdin <<'EOF' { version: 1, defaults: { security: "full", ask: "off", askFallback: "full" } } EOF ``` ### Локальная сокращённая команда ```bash openclaw exec-policy preset yolo ``` Обновляет как локальный `tools.exec.host/security/ask`, так и значения по умолчанию в локальном файле одобрений (включая `askFallback: "full"`). Она намеренно действует только локально. Чтобы удалённо изменить одобрения хоста Gateway или хоста Node, используйте `openclaw approvals set --gateway` или `openclaw approvals set --node `. Другие встроенные предустановки: `cautious` (`host=gateway`, `security=allowlist`, `ask=on-miss`, `askFallback=deny`) и `deny-all` (`host=gateway`, `security=deny`, `ask=off`, `askFallback=deny`). Применяйте их так же: `openclaw exec-policy preset cautious`. Чтобы задать отдельные поля вместо полной предустановки, используйте `openclaw exec-policy set --host --security --ask --ask-fallback ` с любым подмножеством этих флагов. ### Хост Node Вместо этого примените тот же файл одобрений на Node: ```bash openclaw approvals set --node --stdin <<'EOF' { version: 1, defaults: { security: "full", ask: "off", askFallback: "full" } } EOF ``` **Ограничения локального режима:** - `openclaw exec-policy` не синхронизирует одобрения Node. - `openclaw exec-policy set --host node` отклоняется. - Одобрения exec для Node извлекаются с Node во время выполнения, поэтому для обновлений, предназначенных для Node, необходимо использовать `openclaw approvals --node ...`. ### Сокращённая команда только для сеанса - `/exec security=full ask=off` изменяет только текущий сеанс. - `/elevated full` — это аварийная сокращённая команда, которая пропускает одобрения exec только тогда, когда и запрошенная политика, и файл одобрений хоста разрешаются в `security: "full"` и `ask: "off"`. При более строгом файле хоста, например `ask: "always"`, запрос всё равно отображается. Если файл одобрений хоста остаётся строже конфигурации, более строгая политика хоста по-прежнему имеет приоритет. ## Список разрешений (для каждого агента) Списки разрешений задаются **для каждого агента**. Если существует несколько агентов, выберите агента, которого редактируете в приложении macOS. Шаблоны сопоставляются как glob-шаблоны. Шаблонами могут быть glob-шаблоны разрешённых путей к исполняемым файлам или glob-шаблоны простых имён команд. Простые имена соответствуют только командам, вызванным через `PATH`, поэтому `rg` может соответствовать `/opt/homebrew/bin/rg`, когда команда имеет вид `rg`, но **не** `./rg` или `/tmp/rg`. Используйте glob-шаблон пути, чтобы доверять исполняемому файлу только в конкретном расположении. Устаревшие записи `agents.default` при загрузке переносятся в `agents.main`. Для цепочек команд оболочки, таких как `echo ok && pwd`, каждый сегмент верхнего уровня по-прежнему должен соответствовать правилам списка разрешений. Примеры: - `rg` - `~/Projects/**/bin/peekaboo` - `~/.local/bin/*` - `/opt/homebrew/bin/rg` ### Ограничение аргументов с помощью argPattern Добавьте `argPattern`, если запись списка разрешений должна соответствовать исполняемому файлу и определённой структуре аргументов. OpenClaw использует семантику регулярных выражений ECMAScript (JavaScript) на каждом хосте и применяет выражение к разобранным аргументам команды, исключая токен исполняемого файла (`argv[0]`). Для записей, созданных вручную, аргументы объединяются одним пробелом, поэтому, если требуется точное соответствие, используйте якоря в шаблоне. ```json { "version": 1, "agents": { "main": { "allowlist": [ { "pattern": "python3", "argPattern": "^safe\\.py$" } ] } } } ``` Эта запись разрешает `python3 safe.py`; `python3 other.py` не соответствует списку разрешений. Если также присутствует запись только с путём для того же исполняемого файла, несоответствующие аргументы всё ещё могут обрабатываться этой записью только с путём. Не добавляйте запись только с путём, если цель — ограничить исполняемый файл указанными аргументами. Записи, сохранённые процессами одобрения, используют внутренний формат разделителей для точного сопоставления argv. Для повторного создания таких записей предпочтительно использовать интерфейс или процесс одобрения, а не редактировать закодированное значение вручную. Если OpenClaw не удаётся разобрать argv для сегмента команды, записи с `argPattern` не соответствуют ему. Каждая запись списка разрешений поддерживает: | Поле | Значение | | ------------------ | ---------------------------------------------------- | | `pattern` | Glob-шаблон разрешённого пути к исполняемому файлу или простого имени команды | | `argPattern` | Необязательное регулярное выражение ECMAScript для argv; отсутствие означает соответствие только по пути | | `id` | Стабильный непрозрачный идентификатор; при отсутствии создаётся как UUID | | `source` | Источник записи, например `allow-always` | | `commandText` | Устаревший ввод в виде обычного текста; удаляется при загрузке | | `lastUsedAt` | Временная метка последнего использования | | `lastUsedCommand` | Последняя соответствовавшая команда | | `lastResolvedPath` | Последний разрешённый путь к исполняемому файлу | ## Автоматическое разрешение CLI из Skills Когда параметр **Автоматически разрешать CLI из Skills** (`autoAllowSkills`) включён, исполняемые файлы, на которые ссылаются известные навыки, считаются включёнными в список разрешений на узлах (Node macOS или хосте Node без графического интерфейса). Для получения списка двоичных файлов навыков через RPC Gateway используется `skills.bins`. Отключите этот параметр, если вам нужны строго ручные списки разрешений. - Это **неявный список разрешений для удобства**, отдельный от записей ручного списка разрешённых путей. - Он предназначен для доверенных операторских сред, в которых Gateway и Node находятся в одной границе доверия. - Если требуется строгое явное доверие, сохраняйте `autoAllowSkills: false` и используйте только записи ручного списка разрешённых путей. ## Безопасные исполняемые файлы и перенаправление одобрений Сведения о безопасных исполняемых файлах (быстрый путь только через stdin), привязке интерпретатора и перенаправлении запросов одобрения в Slack/Discord/Telegram (или их запуске в качестве собственных клиентов одобрения) см. в разделе [Расширенные настройки одобрений exec](/ru/tools/exec-approvals-advanced). ## Редактирование в Control UI Используйте карточку **Control UI -> Nodes -> Exec approvals**, чтобы редактировать значения по умолчанию, переопределения для отдельных агентов и списки разрешений. Выберите область (Defaults или агент), измените политику, добавьте или удалите шаблоны списка разрешений, затем нажмите **Save**. Интерфейс показывает для каждого шаблона метаданные последнего использования, помогая поддерживать список в порядке. Селектор цели выбирает **Gateway** (локальные одобрения) или **Node**. Узлы должны объявлять `system.execApprovals.get/set` (приложение macOS или хост Node без графического интерфейса). Если Node ещё не объявляет поддержку одобрений exec, отредактируйте его локальный файл одобрений напрямую. Некоторые хосты Node, включая сопутствующее приложение Windows, используют другой формат политики одобрений. Control UI показывает такие собственные политики хоста только для чтения. Чтобы изменить их, используйте сопутствующее приложение или `openclaw approvals set --node ` с собственным форматом политики; см. [CLI одобрений](/ru/cli/approvals). CLI: `openclaw approvals` поддерживает редактирование Gateway или Node — см. [CLI одобрений](/ru/cli/approvals). ## Процесс одобрения Когда требуется запрос, Gateway передаёт `exec.approval.requested` операторским клиентам. Control UI и приложение macOS разрешают его через `exec.approval.resolve`, после чего Gateway перенаправляет одобренный запрос хосту Node. Для `host=node` запросы одобрения включают каноническую полезную нагрузку `systemRunPlan`. Gateway использует этот план как авторитетный контекст команды/cwd/сеанса при перенаправлении одобренных запросов `system.run`: - Путь exec на Node заранее подготавливает один канонический план. - Запись одобрения хранит этот план и метаданные его привязки. - После одобрения итоговый перенаправленный вызов `system.run` повторно использует сохранённый план, а не доверяет последующим изменениям вызывающей стороны. - Если вызывающая сторона изменяет `command`, `rawCommand`, `cwd`, `agentId` или `sessionKey` после создания запроса одобрения, Gateway отклоняет перенаправленный запуск из-за несоответствия одобрению. ## Системные события и отказы После того как Node сообщает о завершении, жизненный цикл exec публикует системное сообщение `Exec finished` в сеансе агента. OpenClaw также может отправить уведомление о выполнении после предоставления одобрения, когда истечёт `tools.exec.approvalRunningNoticeMs` (по умолчанию `10000`, `0` отключает его). Отказ в одобрении exec окончателен для команды хоста: команда не выполняется. - Для асинхронных одобрений основного агента с исходным сеансом OpenClaw публикует отказ обратно в этот сеанс как внутреннее последующее сообщение, чтобы агент прекратил ожидание асинхронной команды и не запускал восстановление отсутствующего результата. - Если сеанса нет или его невозможно возобновить, OpenClaw всё равно может отправить краткое сообщение об отказе оператору или в прямой маршрут чата. - Отказы для сеансов субагентов и Cron не публикуются обратно в этот сеанс. Одобрения exec на хосте Gateway создают такое же событие жизненного цикла завершения. Для exec, требующих одобрения, идентификатор одобрения повторно используется, чтобы связать ожидающий запрос с сообщением о его завершении или отказе (`Exec finished (gateway id=...)` / `Exec denied (gateway id=...)`). ## Последствия - **`full`** предоставляет широкие возможности; по возможности предпочитайте списки разрешений. - **`ask`** позволяет вам сохранять контроль и при этом быстро предоставлять одобрения. - Списки разрешений для отдельных агентов предотвращают распространение одобрений одного агента на других. - Одобрения применяются только к запросам exec на хосте от **авторизованных отправителей**. Неавторизованные отправители не могут вызывать `/exec`. - `/exec security=full` — это удобная функция уровня сеанса для авторизованных операторов, которая намеренно пропускает одобрения. Чтобы полностью заблокировать exec на хосте, установите безопасность одобрений в `deny` или запретите инструмент `exec` с помощью политики инструментов. ## Связанные материалы Безопасные исполняемые файлы, привязка интерпретатора и перенаправление запросов на подтверждение в чат. Инструмент выполнения команд оболочки. Аварийный механизм, который также пропускает подтверждения. Режимы изоляции и доступ к рабочей области. Модель безопасности и усиление защиты. Когда следует использовать каждый из механизмов управления. Автоматическое разрешение на основе Skills.