Подтверждения выполнения команд

Подтверждения выполнения — это защитный механизм приложения-компаньона / хоста Node, позволяющий изолированному агенту запускать команды на реальном хосте (gateway или node). Команды выполняются, только если политика, список разрешений и необязательное подтверждение пользователя согласованы. Подтверждения применяются поверх политики инструментов и проверки повышенных привилегий (повышенный режим full обходит их).

Обзор режимов deny, allowlist, ask, auto, full, сопоставления Codex Guardian и разрешений среды ACPX см. в разделе Режимы разрешений.

Область применения

Подтверждения выполнения применяются локально на хосте выполнения:

• Хост Gateway -> процесс openclaw на компьютере Gateway.
• Хост Node -> исполнитель Node (приложение-компаньон macOS или безголовый хост Node).

Модель доверия

• Вызывающие стороны, прошедшие аутентификацию Gateway, считаются доверенными операторами этого Gateway.
• Сопряжённые узлы распространяют возможности доверенного оператора на хост Node.
• Подтверждения снижают риск случайного выполнения, но не являются границей аутентификации отдельных пользователей или политикой доступа к файловой системе только для чтения.
• После подтверждения команда может изменять файлы в соответствии с выбранными разрешениями файловой системы хоста или песочницы.
• Подтверждённые запуски на хосте Node привязываются к каноническому контексту выполнения: рабочему каталогу, точному массиву аргументов, привязке окружения при её наличии и зафиксированному пути к исполняемому файлу, когда это применимо.
• Для сценариев оболочки и прямых вызовов файлов интерпретатором или средой выполнения OpenClaw также пытается привязать один конкретный локальный файловый операнд. Если этот файл изменится после подтверждения, но до выполнения, запуск будет отклонён вместо выполнения изменившегося содержимого.
• Привязка файла выполняется по мере возможности и не является полной моделью всех путей загрузки интерпретаторов и сред выполнения. Если невозможно определить ровно один конкретный локальный файл, OpenClaw отказывается создавать запуск на основе подтверждения, а не имитирует полное покрытие.

Разделение ответственности в macOS

• Служба хоста Node пересылает system.run в приложение macOS через локальный IPC.
• Приложение macOS применяет подтверждения и выполняет команду в контексте пользовательского интерфейса.

Просмотр эффективной политики

Полный справочник CLI (флаги, вывод JSON, добавление и удаление элементов списка разрешений): CLI подтверждений.

Когда локальная область запрашивает host=node, exec-policy show сообщает, что во время выполнения эта область управляется узлом, вместо того чтобы считать локальный файл подтверждений источником истины.

Если пользовательский интерфейс приложения-компаньона недоступен, любой запрос, который обычно требовал бы подтверждения, обрабатывается согласно резервному режиму запроса (по умолчанию: deny).

Настройки и хранение

Подтверждения хранятся в локальном файле JSON на хосте выполнения. Когда задана переменная OPENCLAW_STATE_DIR, файл размещается в указанном ею каталоге состояния; в противном случае используется стандартный каталог состояния OpenClaw:

$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.

Пример схемы:

{  "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 — предпочтительный нормализованный интерфейс политики для выполнения на хосте:

Устаревшие tools.exec.security / tools.exec.ask по-прежнему поддерживаются и применяются везде, где mode не задан для соответствующей области.

exec.security

exec.ask

askFallback

tools.exec.strictInlineEval

Примеры, которые выявляет строгий режим: 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

Задайте параметр глобально в tools.exec.commandHighlighting или для отдельного агента в agents.list[].tools.exec.commandHighlighting.

Режим YOLO (без подтверждений)

Чтобы выполнять команды на хосте без запросов подтверждения, откройте оба уровня политики: запрошенную политику выполнения в конфигурации OpenClaw (tools.exec.*) и локальную политику подтверждений в файле подтверждений хоста выполнения.

Если askFallback не указано, по умолчанию используется deny. Явно задайте для хоста askFallback значение full, если при отсутствии пользовательского интерфейса запрос подтверждения должен резервно разрешать выполнение.

Провайдеры на базе 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

openclaw config set tools.exec.host gatewayopenclaw config set tools.exec.security fullopenclaw config set tools.exec.ask offopenclaw gateway restart

openclaw approvals set --stdin <<'EOF'{  version: 1,  defaults: {    security: "full",    ask: "off",    askFallback: "full"  }}EOF

Локальная сокращённая команда

openclaw exec-policy preset yolo

Обновляет как локальный tools.exec.host/security/ask, так и значения по умолчанию в локальном файле одобрений (включая askFallback: "full"). Она намеренно действует только локально. Чтобы удалённо изменить одобрения хоста Gateway или хоста Node, используйте openclaw approvals set --gateway или openclaw approvals set --node <id|name|ip>.

Другие встроенные предустановки: 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 <auto|sandbox|gateway|node> --security <deny|allowlist|full> --ask <off|on-miss|always> --ask-fallback <deny|allowlist|full> с любым подмножеством этих флагов.

Хост Node

Вместо этого примените тот же файл одобрений на Node:

openclaw approvals set --node <id|name|ip> --stdin <<'EOF'{  version: 1,  defaults: {    security: "full",    ask: "off",    askFallback: "full"  }}EOF

Сокращённая команда только для сеанса

• /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]). Для записей, созданных вручную, аргументы объединяются одним пробелом, поэтому, если требуется точное соответствие, используйте якоря в шаблоне.

{  "version": 1,  "agents": {    "main": {      "allowlist": [        {          "pattern": "python3",          "argPattern": "^safe\\.py$"        }      ]    }  }}

Эта запись разрешает python3 safe.py; python3 other.py не соответствует списку разрешений. Если также присутствует запись только с путём для того же исполняемого файла, несоответствующие аргументы всё ещё могут обрабатываться этой записью только с путём. Не добавляйте запись только с путём, если цель — ограничить исполняемый файл указанными аргументами.

Записи, сохранённые процессами одобрения, используют внутренний формат разделителей для точного сопоставления argv. Для повторного создания таких записей предпочтительно использовать интерфейс или процесс одобрения, а не редактировать закодированное значение вручную. Если OpenClaw не удаётся разобрать argv для сегмента команды, записи с argPattern не соответствуют ему.

Каждая запись списка разрешений поддерживает:

Автоматическое разрешение CLI из Skills

Когда параметр Автоматически разрешать CLI из Skills (autoAllowSkills) включён, исполняемые файлы, на которые ссылаются известные навыки, считаются включёнными в список разрешений на узлах (Node macOS или хосте Node без графического интерфейса). Для получения списка двоичных файлов навыков через RPC Gateway используется skills.bins. Отключите этот параметр, если вам нужны строго ручные списки разрешений.

Безопасные исполняемые файлы и перенаправление одобрений

Сведения о безопасных исполняемых файлах (быстрый путь только через stdin), привязке интерпретатора и перенаправлении запросов одобрения в Slack/Discord/Telegram (или их запуске в качестве собственных клиентов одобрения) см. в разделе Расширенные настройки одобрений exec.

Редактирование в 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 <id|name|ip> с собственным форматом политики; см. CLI одобрений.

CLI: openclaw approvals поддерживает редактирование Gateway или Node — см. CLI одобрений.

Процесс одобрения

Когда требуется запрос, 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 с помощью политики инструментов.

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