> ## 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 — это **защитный механизм companion app / хоста node**, позволяющий изолированному агенту запускать команды на реальном хосте (`gateway` или `node`). Это предохранитель: команды разрешены только тогда, когда policy + allowlist + (необязательное) подтверждение пользователя согласованы. Подтверждения exec накладываются **поверх** политики инструментов и elevated gating (если только elevated не установлен в `full`, что пропускает подтверждения). Обзор режимов `deny`, `allowlist`, `ask`, `auto`, `full`, сопоставления Codex Guardian и разрешений ACPX harness см. в разделе [Режимы разрешений](/ru/tools/permission-modes). Итоговая policy — **более строгая** из `tools.exec.*` и значений по умолчанию для подтверждений; если поле подтверждений опущено, используется значение `tools.exec`. Host exec также использует локальное состояние подтверждений на этой машине: локальное для хоста `ask: "always"` в файле подтверждений хоста исполнения продолжает запрашивать подтверждение, даже если значения по умолчанию сеанса или конфигурации требуют `ask: "on-miss"`. ## Проверка итоговой policy | Команда | Что показывает | | ---------------------------------------------------------------- | ----------------------------------------------------------------------------------------------- | | `openclaw approvals get` / `--gateway` / `--node ` | Запрошенную policy, источники policy хоста и итоговый результат. | | `openclaw exec-policy show` | Объединенное представление локальной машины. | | `openclaw exec-policy set` / `preset` | Синхронизирует локальную запрошенную policy с локальным файлом подтверждений хоста за один шаг. | Когда локальная область запрашивает `host=node`, `exec-policy show` сообщает, что эта область управляется node во время выполнения, вместо того чтобы делать вид, что локальный файл подтверждений является источником истины. Если UI companion app **недоступен**, любой запрос, который обычно требовал бы подтверждения, разрешается через **ask fallback** (по умолчанию: `deny`). Нативные клиенты подтверждений в чатах могут добавлять к ожидающему сообщению подтверждения канальные удобные действия. Например, Matrix добавляет быстрые реакции (`✅` разрешить один раз, `❌` отклонить, `♾️` разрешать всегда), при этом оставляя команды `/approve ...` в сообщении как резервный вариант. ## Где это применяется Подтверждения exec применяются локально на хосте исполнения: * **Хост Gateway** → процесс `openclaw` на машине gateway. * **Хост Node** → runner node (macOS companion app или headless-хост node). ### Модель доверия * Вызывающие стороны, аутентифицированные через Gateway, считаются доверенными операторами для этого Gateway. * Спаренные nodes расширяют эту возможность доверенного оператора на хост node. * Подтверждения exec снижают риск случайного выполнения, но **не** являются границей аутентификации на пользователя или политикой файловой системы только для чтения. * После подтверждения команда может изменять файлы в соответствии с выбранными разрешениями файловой системы хоста или sandbox. * Подтвержденные запуски на хосте node привязывают канонический контекст исполнения: канонический cwd, точный argv, привязку env при наличии и закрепленный путь к исполняемому файлу, когда применимо. * Для shell-скриптов и прямых вызовов файлов интерпретатора/среды выполнения OpenClaw также пытается привязать один конкретный локальный файловый операнд. Если этот привязанный файл изменится после подтверждения, но до выполнения, запуск будет отклонен вместо выполнения изменившегося содержимого. * Привязка файлов намеренно выполняется по принципу best-effort и **не** является полной семантической моделью каждого пути загрузчика интерпретатора/среды выполнения. Если режим подтверждения не может определить ровно один конкретный локальный файл для привязки, он отказывается создавать запуск, основанный на подтверждении, вместо того чтобы притворяться, что покрытие полное. ### Разделение macOS * **Сервис хоста node** пересылает `system.run` в **приложение macOS** через локальный IPC. * **Приложение macOS** применяет подтверждения и выполняет команду в контексте UI. ## Настройки и хранение Подтверждения хранятся в локальном JSON-файле на хосте исполнения. Когда `OPENCLAW_STATE_DIR` задан, файл следует этому каталогу состояния; иначе используется стандартный каталог состояния OpenClaw: ```text theme={"theme":{"light":"min-light","dark":"min-dark"}} $OPENCLAW_STATE_DIR/exec-approvals.json # otherwise ~/.openclaw/exec-approvals.json ``` Стандартный сокет подтверждений использует тот же корень: `$OPENCLAW_STATE_DIR/exec-approvals.sock` или `~/.openclaw/exec-approvals.sock`, когда переменная не задана. Пример схемы: ```json theme={"theme":{"light":"min-light","dark":"min-dark"}} { "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", "commandText": "rg -n TODO", "lastUsedAt": 1737150000000, "lastUsedCommand": "rg -n TODO", "lastResolvedPath": "/Users/user/Projects/.../bin/rg" } ] } } } ``` ## Ручки policy ### `tools.exec.mode` `tools.exec.mode` — предпочтительная нормализованная поверхность policy для host exec. Значения: * `deny` - блокировать host exec. * `allowlist` - запускать только команды из allowlist без запроса. * `ask` - использовать policy allowlist и спрашивать при промахах. * `auto` - использовать policy allowlist, запускать детерминированные совпадения напрямую и отправлять промахи подтверждения через нативного auto reviewer OpenClaw перед откатом к маршруту подтверждения человеком. * `full` - запускать host exec без запросов подтверждения. Устаревшие `tools.exec.security` / `tools.exec.ask` остаются поддерживаемыми и по-прежнему имеют приоритет, когда заданы в более узкой области сеанса или агента. ### `exec.security` * `deny` - блокировать все запросы host exec. * `allowlist` - разрешать только команды из allowlist. * `full` - разрешать все (эквивалентно elevated). ### `exec.ask` Настроенная policy запросов для host exec. Управляет базовым поведением запроса подтверждения из `tools.exec.ask` и значений по умолчанию подтверждений хоста. Параметр инструмента `ask` для отдельного вызова (см. [Инструмент Exec](/ru/tools/exec#parameters)) может только ужесточить эту базу, а вызовы модели из каналов игнорируют его, когда итоговое значение host ask равно `off`. * `off` - никогда не запрашивать. * `on-miss` - запрашивать только когда allowlist не совпадает. * `always` - запрашивать для каждой команды. Долговременное доверие `allow-always` **не** подавляет запросы, когда итоговый режим ask равен `always`. ### `askFallback` Решение, когда требуется запрос, но UI недоступен. Если это поле опущено, OpenClaw по умолчанию использует `deny`. * `deny` - блокировать. * `allowlist` - разрешать только если allowlist совпадает. * `full` - разрешать. ### `tools.exec.strictInlineEval` Когда `true`, OpenClaw рассматривает формы встроенного code-eval как требующие только подтверждения, даже если сам бинарный файл интерпретатора находится в allowlist. Defense-in-depth для загрузчиков интерпретаторов, которые не отображаются чисто на один стабильный файловый операнд. Примеры, которые перехватывает строгий режим: * `python -c` * `node -e`, `node --eval`, `node -p` * `ruby -e` * `perl -e`, `perl -E` * `php -r` * `lua -e` * `osascript -e` В строгом режиме этим командам все равно требуется явное подтверждение, а `allow-always` не сохраняет для них новые записи allowlist автоматически. ### `tools.exec.commandHighlighting` Управляет только представлением в запросах подтверждения exec. Когда включено, OpenClaw может прикреплять полученные парсером диапазоны команд, чтобы Web-запросы подтверждения могли подсвечивать токены команды. Установите `true`, чтобы включить подсветку текста команды. Эта настройка **не** меняет `security`, `ask`, сопоставление allowlist, строгое поведение inline-eval, пересылку подтверждений или выполнение команд. Ее можно задать глобально в `tools.exec.commandHighlighting` или для агента в `agents.list[].tools.exec.commandHighlighting`. ## Режим YOLO (без подтверждений) Если вы хотите, чтобы host exec запускался без запросов подтверждения, нужно открыть **оба** слоя policy: запрошенную exec policy в конфигурации OpenClaw (`tools.exec.*`) **и** локальную для хоста policy подтверждений в файле подтверждений хоста исполнения. OpenClaw по умолчанию задает пропущенный `askFallback` как `deny`. Явно задайте хостовый `askFallback` как `full`, когда запрос подтверждения без UI должен откатываться к разрешению. | Слой | Настройка YOLO | | ---------------------- | -------------------------- | | `tools.exec.security` | `full` на `gateway`/`node` | | `tools.exec.ask` | `off` | | Хостовый `askFallback` | `full` | **Важные различия:** * `tools.exec.host=auto` выбирает, **где** выполняется exec: в sandbox, когда доступно, иначе на gateway. * YOLO выбирает, **как** подтверждается host exec: `security=full` плюс `ask=off`. * В режиме YOLO OpenClaw **не** добавляет отдельный эвристический шлюз подтверждения для обфускации команд или слой предварительного отклонения скриптов поверх настроенной policy host exec. * `auto` не делает маршрутизацию на gateway свободным обходом из изолированного сеанса. Запрос отдельного вызова `host=node` разрешен из `auto`; `host=gateway` разрешен из `auto` только когда активная среда выполнения sandbox отсутствует. Для стабильного не-auto значения по умолчанию задайте `tools.exec.host` или явно используйте `/exec host=...`. Провайдеры на базе CLI, которые предоставляют собственный неинтерактивный режим разрешений, могут следовать этой policy. Claude CLI добавляет `--permission-mode bypassPermissions`, когда итоговая exec policy OpenClaw является YOLO. Для управляемых OpenClaw живых сеансов Claude итоговая exec policy OpenClaw имеет приоритет над нативным режимом разрешений Claude: YOLO нормализует live-запуски к `--permission-mode bypassPermissions`, а ограничительная итоговая exec policy нормализует live-запуски к `--permission-mode default`, даже если raw-аргументы backend Claude указывают другой режим. Если нужна более консервативная настройка, ужесточите exec policy OpenClaw обратно до `allowlist` / `on-miss` или `deny`. ### Постоянная настройка "никогда не запрашивать" для хоста gateway ```bash theme={"theme":{"light":"min-light","dark":"min-dark"}} 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 theme={"theme":{"light":"min-light","dark":"min-dark"}} openclaw approvals set --stdin <<'EOF' { version: 1, defaults: { security: "full", ask: "off", askFallback: "full" } } EOF ``` ### Локальный ярлык ```bash theme={"theme":{"light":"min-light","dark":"min-dark"}} openclaw exec-policy preset yolo ``` Этот локальный ярлык обновляет оба: * Локальные `tools.exec.host/security/ask`. * Локальные значения по умолчанию файла подтверждений, включая `askFallback: "full"`. Он намеренно только локальный. Чтобы изменить подтверждения хоста gateway или хоста node удаленно, используйте `openclaw approvals set --gateway` или `openclaw approvals set --node `. ### Хост Node Для хоста node примените тот же файл подтверждений на этом node: ```bash theme={"theme":{"light":"min-light","dark":"min-dark"}} 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` — это аварийный shortcut, который пропускает утверждения 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`. Цепочки shell вроде `echo ok && pwd` по-прежнему требуют, чтобы каждый сегмент верхнего уровня удовлетворял правилам списка разрешений. Примеры: * `rg` * `~/Projects/**/bin/peekaboo` * `~/.local/bin/*` * `/opt/homebrew/bin/rg` ### Ограничение аргументов с помощью argPattern Добавьте `argPattern`, когда запись списка разрешений должна совпадать с бинарным файлом и конкретной формой аргументов. OpenClaw вычисляет регулярное выражение по разобранным аргументам команды, исключая токен исполняемого файла (`argv[0]`). Для записей, созданных вручную, аргументы соединяются одним пробелом, поэтому закрепляйте шаблон, когда нужно точное совпадение. ```json theme={"theme":{"light":"min-light","dark":"min-dark"}} { "version": 1, "agents": { "main": { "allowlist": [ { "pattern": "python3", "argPattern": "^safe\\.py$" } ] } } } ``` Эта запись разрешает `python3 safe.py`; `python3 other.py` не попадает в список разрешений. Если для того же бинарного файла также присутствует запись только по пути, несовпавшие аргументы все еще могут откатиться к этой записи только по пути. Не добавляйте запись только по пути, если цель — ограничить бинарный файл объявленными аргументами. Записи, сохраненные потоками утверждения, могут использовать внутренний формат с разделителем для точного сопоставления argv. Предпочитайте UI или поток утверждения для повторного создания таких записей вместо ручного редактирования закодированного значения. Если OpenClaw не может разобрать argv для сегмента команды, записи с `argPattern` не совпадают. Каждая запись списка разрешений поддерживает: | Поле | Значение | | ------------------ | ------------------------------------------------------------------------- | | `pattern` | Glob разрешенного пути к бинарному файлу или glob простого имени команды | | `argPattern` | Необязательное regex для argv; пропущенные записи работают только по пути | | `id` | Стабильный UUID, используемый для идентичности в UI | | `source` | Источник записи, например `allow-always` | | `commandText` | Текст команды, захваченный при создании записи потоком утверждения | | `lastUsedAt` | Метка времени последнего использования | | `lastUsedCommand` | Последняя совпавшая команда | | `lastResolvedPath` | Последний разрешенный путь к бинарному файлу | ## Автоматическое разрешение CLI Skills Когда включено **Автоматическое разрешение CLI Skills**, исполняемые файлы, на которые ссылаются известные Skills, считаются разрешенными на узлах (узел macOS или headless хост узла). Для получения списка bin-файлов skills используется `skills.bins` через Gateway RPC. Отключите это, если нужны строгие ручные списки разрешений. * Это **неявный удобный список разрешений**, отдельный от ручных записей списка разрешений по пути. * Он предназначен для доверенных операторских окружений, где Gateway и узел находятся в одной границе доверия. * Если вам требуется строгое явное доверие, оставьте `autoAllowSkills: false` и используйте только ручные записи списка разрешений по пути. ## Безопасные bin-файлы и пересылка утверждений О безопасных bin-файлах (быстрый путь только через stdin), деталях привязки интерпретатора и о том, как пересылать запросы утверждения в Slack/Discord/Telegram (или запускать их как нативные клиенты утверждений), см. [Утверждения exec — расширенные настройки](/ru/tools/exec-approvals-advanced). ## Редактирование в Control UI Используйте карточку **Control UI → Узлы → Утверждения exec**, чтобы редактировать defaults, переопределения для отдельных агентов и списки разрешений. Выберите область (Defaults или агент), настройте политику, добавьте/удалите шаблоны списка разрешений, затем нажмите **Save**. UI показывает метаданные последнего использования для каждого шаблона, чтобы список было проще поддерживать в порядке. Селектор цели выбирает **Gateway** (локальные утверждения) или **узел**. Узлы должны объявлять `system.execApprovals.get/set` (приложение macOS или headless хост узла). Если узел еще не объявляет утверждения exec, редактируйте его локальный файл утверждений напрямую. CLI: `openclaw approvals` поддерживает редактирование Gateway или узла — см. [CLI утверждений](/ru/cli/approvals). ## Поток утверждения Когда требуется запрос, Gateway рассылает `exec.approval.requested` клиентам операторов. Control UI и приложение macOS разрешают его через `exec.approval.resolve`, затем Gateway пересылает утвержденный запрос хосту узла. Для `host=node` запросы утверждения включают каноническую полезную нагрузку `systemRunPlan`. Gateway использует этот план как авторитетный контекст command/cwd/session при пересылке утвержденных запросов `system.run`. Это важно при задержке асинхронного утверждения: * Путь exec узла заранее подготавливает один канонический план. * Запись утверждения сохраняет этот план и его метаданные привязки. * После утверждения финальный пересланный вызов `system.run` повторно использует сохраненный план вместо доверия более поздним правкам вызывающей стороны. * Если вызывающая сторона изменяет `command`, `rawCommand`, `cwd`, `agentId` или `sessionKey` после создания запроса утверждения, Gateway отклоняет пересланный запуск как несоответствие утверждению. ## Системные события Жизненный цикл exec отображается как системные сообщения: * `Exec running` (только если команда превышает порог уведомления о выполнении). * `Exec finished`. Они публикуются в сеанс агента после того, как узел сообщает о событии. Отклоненные утверждения exec являются терминальными для самой команды хоста: команда не запускается. Для асинхронных утверждений основного агента с исходным сеансом OpenClaw публикует отказ обратно в этот сеанс как внутреннее последующее сообщение, чтобы агент мог перестать ждать асинхронную команду и избежать восстановления отсутствующего результата. Если сеанса нет или сеанс нельзя возобновить, OpenClaw все еще может сообщить краткий отказ оператору или в прямой маршрут чата. Отказы для сеансов сабагентов не публикуются обратно в сабагент. Утверждения exec на хосте Gateway испускают те же события жизненного цикла, когда команда завершается (и, при необходимости, когда выполняется дольше порога). Exec, ограниченные утверждениями, повторно используют id утверждения как `runId` в этих сообщениях для простой корреляции. ## Поведение при отклоненном утверждении Когда асинхронное утверждение exec отклонено, OpenClaw считает команду хоста терминальной и закрытой с отказом. Для сеансов основного агента отказ доставляется как внутреннее последующее сообщение сеанса, которое сообщает агенту, что асинхронная команда не запускалась. Это сохраняет непрерывность transcript, не раскрывая устаревший вывод команды. Если доставка в сеанс недоступна, OpenClaw откатывается к краткому отказу для оператора или прямого чата, когда существует безопасный маршрут. ## Следствия * **`full`** дает большие полномочия; по возможности предпочитайте списки разрешений. * **`ask`** оставляет вас в цикле контроля, при этом сохраняя быстрые утверждения. * Списки разрешений для каждого агента предотвращают утечку утверждений одного агента к другим. * Утверждения применяются только к запросам exec хоста от **авторизованных отправителей**. Неавторизованные отправители не могут выполнять `/exec`. * `/exec security=full` — это удобство уровня сеанса для авторизованных операторов, которое намеренно пропускает утверждения. Чтобы жестко заблокировать exec хоста, установите security утверждений в `deny` или запретите инструмент `exec` через политику инструментов. ## Связанные материалы Безопасные bin-файлы, привязка интерпретатора и пересылка утверждений в чат. Инструмент выполнения shell-команд. Аварийный путь, который также пропускает утверждения. Режимы sandbox и доступ к workspace. Модель безопасности и усиление защиты. Когда использовать каждый механизм управления. Поведение автоматического разрешения на основе Skills.