Перейти к основному содержанию
Подтверждения exec — это защитный механизм companion app / хоста node, позволяющий изолированному агенту запускать команды на реальном хосте (gateway или node). Это предохранитель: команды разрешены только тогда, когда policy + allowlist + (необязательное) подтверждение пользователя согласованы. Подтверждения exec накладываются поверх политики инструментов и elevated gating (если только elevated не установлен в full, что пропускает подтверждения). Обзор режимов deny, allowlist, ask, auto, full, сопоставления Codex Guardian и разрешений ACPX harness см. в разделе Режимы разрешений.
Итоговая policy — более строгая из tools.exec.* и значений по умолчанию для подтверждений; если поле подтверждений опущено, используется значение tools.exec. Host exec также использует локальное состояние подтверждений на этой машине: локальное для хоста ask: "always" в файле подтверждений хоста исполнения продолжает запрашивать подтверждение, даже если значения по умолчанию сеанса или конфигурации требуют ask: "on-miss".

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

КомандаЧто показывает
openclaw approvals get / --gateway / --node <id|name|ip>Запрошенную 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: 
$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

​
security
"deny" | "allowlist" | "full"
  • deny - блокировать все запросы host exec.
  • allowlist - разрешать только команды из allowlist.
  • full - разрешать все (эквивалентно elevated).

​
exec.ask

​
ask
"off" | "on-miss" | "always"
Настроенная policy запросов для host exec. Управляет базовым поведением запроса подтверждения из tools.exec.ask и значений по умолчанию подтверждений хоста. Параметр инструмента ask для отдельного вызова (см. Инструмент Exec) может только ужесточить эту базу, а вызовы модели из каналов игнорируют его, когда итоговое значение host ask равно off.
  • off - никогда не запрашивать.
  • on-miss - запрашивать только когда allowlist не совпадает.
  • always - запрашивать для каждой команды. Долговременное доверие allow-always не подавляет запросы, когда итоговый режим ask равен always.

​
askFallback

​
askFallback
"deny" | "allowlist" | "full"
Решение, когда требуется запрос, но UI недоступен. Если это поле опущено, OpenClaw по умолчанию использует deny.
  • deny - блокировать.
  • allowlist - разрешать только если allowlist совпадает.
  • full - разрешать.

​
tools.exec.strictInlineEval

​
strictInlineEval
boolean
Когда 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

​
commandHighlighting
boolean
по умолчанию:"false"
Управляет только представлением в запросах подтверждения 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.securityfull на gateway/node
tools.exec.askoff
Хостовый askFallbackfull
Важные различия:
  • 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

1

Задайте запрошенную config policy

openclaw config set tools.exec.host gateway
openclaw config set tools.exec.security full
openclaw config set tools.exec.ask off
openclaw gateway restart
2

Согласуйте файл подтверждений хоста

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
Ограничения только локального режима:
  • 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]). Для записей, созданных вручную, аргументы соединяются одним пробелом, поэтому закрепляйте шаблон, когда нужно точное совпадение. 
{
  "version": 1,
  "agents": {
    "main": {
      "allowlist": [
        {
          "pattern": "python3",
          "argPattern": "^safe\\.py$"
        }
      ]
    }
  }
}
Эта запись разрешает python3 safe.py; python3 other.py не попадает в список разрешений. Если для того же бинарного файла также присутствует запись только по пути, несовпавшие аргументы все еще могут откатиться к этой записи только по пути. Не добавляйте запись только по пути, если цель — ограничить бинарный файл объявленными аргументами. Записи, сохраненные потоками утверждения, могут использовать внутренний формат с разделителем для точного сопоставления argv. Предпочитайте UI или поток утверждения для повторного создания таких записей вместо ручного редактирования закодированного значения. Если OpenClaw не может разобрать argv для сегмента команды, записи с argPattern не совпадают. Каждая запись списка разрешений поддерживает:
ПолеЗначение
patternGlob разрешенного пути к бинарному файлу или 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 — расширенные настройки.

​
Редактирование в 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 через политику инструментов.

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

Exec approvals - advanced

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

Exec tool

Инструмент выполнения shell-команд.

Elevated mode

Аварийный путь, который также пропускает утверждения.

Sandboxing

Режимы sandbox и доступ к workspace.

Security

Модель безопасности и усиление защиты.

Sandbox vs tool policy vs elevated

Когда использовать каждый механизм управления.

Skills

Поведение автоматического разрешения на основе Skills.