Утверждения выполнения

Подтверждения exec — это защитный механизм companion app / хоста node, позволяющий изолированному агенту запускать команды на реальном хосте (gateway или node). Это предохранитель: команды разрешены только тогда, когда policy + allowlist + (необязательное) подтверждение пользователя согласованы. Подтверждения exec накладываются поверх политики инструментов и elevated gating (если только elevated не установлен в full, что пропускает подтверждения).

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

Проверка итоговой policy

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

Если UI companion app недоступен, любой запрос, который обычно требовал бы подтверждения, разрешается через ask fallback (по умолчанию: deny).

Где это применяется

Подтверждения 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:

$OPENCLAW_STATE_DIR/exec-approvals.json# otherwise~/.openclaw/exec-approvals.json

Стандартный сокет подтверждений использует тот же корень: $OPENCLAW_STATE_DIR/exec-approvals.sock или ~/.openclaw/exec-approvals.sock, когда переменная не задана.

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

{  "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

exec.ask

askFallback

tools.exec.strictInlineEval

Примеры, которые перехватывает строгий режим:

• 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

Эта настройка не меняет 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 должен откатываться к разрешению.

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

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

Хост Node

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

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

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

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

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

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

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

Безопасные bin-файлы и пересылка утверждений

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

Редактирование в Control UI

Используйте карточку Control UI → Узлы → Утверждения exec, чтобы редактировать defaults, переопределения для отдельных агентов и списки разрешений. Выберите область (Defaults или агент), настройте политику, добавьте/удалите шаблоны списка разрешений, затем нажмите Save. UI показывает метаданные последнего использования для каждого шаблона, чтобы список было проще поддерживать в порядке.

Селектор цели выбирает Gateway (локальные утверждения) или узел. Узлы должны объявлять system.execApprovals.get/set (приложение macOS или headless хост узла). Если узел еще не объявляет утверждения exec, редактируйте его локальный файл утверждений напрямую.

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

Поток утверждения

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

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