Перейти до основного вмісту
Схвалення exec — це запобіжник супровідного застосунку / хоста Node, який дозволяє ізольованому агенту виконувати команди на реальному хості (gateway або node). Це блокувальний механізм безпеки: команди дозволені лише тоді, коли політика + список дозволених + (необов’язкове) схвалення користувача всі узгоджуються. Схвалення exec накладаються поверх політики інструментів і шлюзу підвищених прав (якщо elevated не встановлено в full, що пропускає схвалення). Огляд режимів deny, allowlist, ask, auto, full, зіставлення Codex Guardian і дозволів harness ACPX дивіться в Режими дозволів.
Ефективна політика є суворішою з tools.exec.* і стандартних значень схвалень; якщо поле схвалень пропущено, використовується значення tools.exec. Host exec також використовує локальний стан схвалень на цій машині - локальне для хоста ask: "always" у файлі схвалень хоста виконання продовжує запитувати підтвердження, навіть якщо стандартні значення сеансу або конфігурації запитують ask: "on-miss".

​
Перегляд ефективної політики

КомандаЩо вона показує
openclaw approvals get / --gateway / --node <id|name|ip>Запитану політику, джерела політики хоста та ефективний результат.
openclaw exec-policy showОб’єднаний вигляд локальної машини.
openclaw exec-policy set / presetСинхронізує локальну запитану політику з локальним файлом схвалень хоста за один крок.
Коли локальна область запитує host=node, exec-policy show повідомляє цю область як керовану Node під час виконання, замість того щоб удавати, що локальний файл схвалень є джерелом істини. Якщо UI супровідного застосунку недоступний, будь-який запит, який зазвичай показував би prompt, вирішується через резервний режим ask (стандартно: deny).
Нативні клієнти схвалення в чаті можуть додавати специфічні для каналу можливості до повідомлення з очікуваним схваленням. Наприклад, Matrix додає швидкі реакції (✅ дозволити один раз, ❌ відхилити, ♾️ завжди дозволяти), водночас залишаючи команди /approve ... у повідомленні як резервний варіант.

​
Де це застосовується

Схвалення exec застосовуються локально на хості виконання:
  • Хост Gateway → процес openclaw на машині Gateway.
  • Хост Node → ранер Node (супровідний застосунок macOS або headless-хост Node).

​
Модель довіри

  • Абоненти, автентифіковані через Gateway, є довіреними операторами для цього Gateway.
  • Спарені Node поширюють цю здатність довіреного оператора на хост Node.
  • Схвалення exec зменшують ризик випадкового виконання, але не є межею авторизації для окремого користувача або політикою read-only для файлової системи.
  • Після схвалення команда може змінювати файли відповідно до вибраних дозволів хоста або файлової системи 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
Стандартний socket схвалень використовує той самий корінь: $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"
        }
      ]
    }
  }
}

​
Ручки політики

​
tools.exec.mode

tools.exec.mode є рекомендованою нормалізованою поверхнею політики для host exec. Значення:
  • deny - блокувати host exec.
  • allowlist - виконувати без запиту лише команди зі списку дозволених.
  • ask - використовувати політику списку дозволених і запитувати при промахах.
  • auto - використовувати політику списку дозволених, запускати детерміновані збіги напряму та надсилати промахи схвалення через нативного auto reviewer OpenClaw перед fallback до маршруту схвалення людиною.
  • full - виконувати host exec без prompt схвалення.
Застарілі tools.exec.security / tools.exec.ask залишаються підтримуваними та все ще мають пріоритет, коли задані у вужчій області сеансу або агента.

​
exec.security

​
security
"deny" | "allowlist" | "full"
  • deny - блокувати всі запити host exec.
  • allowlist - дозволяти лише команди зі списку дозволених.
  • full - дозволяти все (еквівалентно elevated).

​
exec.ask

​
ask
"off" | "on-miss" | "always"
Налаштована політика ask для host exec. Керує базовою поведінкою prompt схвалення з tools.exec.ask і стандартних значень схвалень хоста. Параметр інструмента ask для окремого виклику (див. Інструмент Exec) може лише посилити цю базову лінію, а модельні виклики з каналів ігнорують його, коли ефективний ask хоста дорівнює off.
  • off - ніколи не показувати prompt.
  • on-miss - показувати prompt лише коли список дозволених не збігається.
  • always - показувати prompt для кожної команди. Довготривала довіра allow-always не пригнічує prompt, коли ефективний режим ask дорівнює always.

​
askFallback

​
askFallback
"deny" | "allowlist" | "full"
Рішення, коли prompt потрібен, але UI недоступний. Якщо це поле пропущено, OpenClaw стандартно використовує deny.
  • deny - блокувати.
  • allowlist - дозволяти лише якщо список дозволених збігається.
  • full - дозволяти.

​
tools.exec.strictInlineEval

​
strictInlineEval
boolean
Коли true, OpenClaw розглядає форми inline code-eval як такі, що потребують лише схвалення, навіть якщо сам binary інтерпретатора є в allowlist. Defense-in-depth для завантажувачів інтерпретаторів, які не відображаються чисто на один стабільний файловий операнд.
Приклади, які ловить strict mode:
  • python -c
  • node -e, node --eval, node -p
  • ruby -e
  • perl -e, perl -E
  • php -r
  • lua -e
  • osascript -e
У strict mode ці команди все ще потребують явного схвалення, а allow-always не зберігає для них нові записи allowlist автоматично.

​
tools.exec.commandHighlighting

​
commandHighlighting
boolean
за замовчуванням:"false"
Керує лише представленням у prompt схвалення exec. Коли ввімкнено, OpenClaw може додавати отримані з парсера фрагменти команд, щоб Web prompt схвалення могли підсвічувати токени команд. Установіть true, щоб увімкнути підсвічування тексту команд.
Це налаштування не змінює security, ask, зіставлення allowlist, поведінку strict inline-eval, пересилання схвалень або виконання команд. Його можна задати глобально в tools.exec.commandHighlighting або для окремого агента в agents.list[].tools.exec.commandHighlighting.

​
Режим YOLO (без схвалень)

Якщо ви хочете, щоб host exec запускався без prompt схвалення, потрібно відкрити обидва шари політики - запитану політику exec у конфігурації OpenClaw (tools.exec.*) і локальну для хоста політику схвалень у файлі схвалень хоста виконання. OpenClaw стандартно встановлює пропущений askFallback у deny. Установіть для хоста askFallback у full явно, коли prompt схвалення без UI має fallback до дозволу.
ШарНалаштування YOLO
tools.exec.securityfull на gateway/node
tools.exec.askoff
Host askFallbackfull
Важливі відмінності:
  • tools.exec.host=auto вибирає, де виконується exec: у sandbox, коли доступно, інакше на gateway.
  • YOLO вибирає, як схвалюється host exec: security=full плюс ask=off.
  • У режимі YOLO OpenClaw не додає окремий евристичний gate схвалення для обфускації команд або шар script-preflight rejection поверх налаштованої політики host exec.
  • auto не робить маршрутизацію на gateway вільним override із sandbox-сеансу. Запит host=node для окремого виклику дозволений з auto; host=gateway дозволений з auto лише коли немає активного sandbox runtime. Для стабільного не-auto стандартного значення задайте tools.exec.host або використовуйте /exec host=... явно.
Провайдери на основі CLI, які надають власний noninteractive режим дозволів, можуть дотримуватися цієї політики. Claude CLI додає --permission-mode bypassPermissions, коли ефективна політика exec OpenClaw є YOLO. Для керованих OpenClaw live-сеансів Claude ефективна політика exec OpenClaw є авторитетною щодо нативного режиму дозволів Claude: YOLO нормалізує live-запуски до --permission-mode bypassPermissions, а обмежувальна ефективна політика exec нормалізує live-запуски до --permission-mode default, навіть якщо сирі аргументи backend Claude задають інший режим. Якщо потрібне консервативніше налаштування, посильте політику exec OpenClaw назад до allowlist / on-miss або deny.

​
Постійне налаштування gateway-хоста “ніколи не питати”

1

Установіть запитану політику конфігурації

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

​
Локальний shortcut

openclaw exec-policy preset yolo
Цей локальний shortcut оновлює обидва:
  • Локальні 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 ....

​
Shortcut лише для сеансу

  • /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 хост вузла). Для отримання списку бінарних файлів skill це використовує skills.bins через Gateway RPC. Вимкніть це, якщо хочете суворі ручні списки дозволеного.
  • Це неявний зручний список дозволеного, окремий від ручних записів списку дозволених шляхів.
  • Він призначений для довірених операторських середовищ, де Gateway і вузол перебувають в одній межі довіри.
  • Якщо вам потрібна сувора явна довіра, залиште autoAllowSkills: false і використовуйте лише ручні записи списку дозволених шляхів.

​
Безпечні бінарні файли та пересилання підтверджень

Про безпечні бінарні файли (швидкий шлях лише через stdin), деталі прив’язки інтерпретатора та те, як пересилати запити підтвердження до Slack/Discord/Telegram (або запускати їх як нативні клієнти підтвердження), див. Підтвердження exec — додатково.

​
Редагування в Control UI

Використовуйте картку Control UI → Nodes → Exec approvals, щоб редагувати типові значення, перевизначення для окремих агентів і списки дозволеного. Виберіть область (типові значення або агент), налаштуйте політику, додайте/видаліть шаблони списку дозволеного, потім натисніть Save. UI показує метадані останнього використання для кожного шаблону, щоб ви могли підтримувати список упорядкованим. Селектор цілі вибирає Gateway (локальні підтвердження) або Node. Вузли мають оголошувати 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, обмежені підтвердженням, повторно використовують ідентифікатор підтвердження як runId у цих повідомленнях для зручної кореляції.

​
Поведінка відхиленого підтвердження

Коли асинхронне підтвердження exec відхилено, OpenClaw розглядає команду хоста як термінальну й fail-closed. Для сеансів головного агента відмова доставляється як внутрішнє продовження сеансу, яке повідомляє агенту, що асинхронна команда не запускалася. Це зберігає безперервність транскрипта без показу застарілого виводу команди. Якщо доставка в сеанс недоступна, OpenClaw повертається до стислої відмови для оператора або прямого чату, коли існує безпечний маршрут.

​
Наслідки

  • full є потужним; за можливості віддавайте перевагу спискам дозволеного.
  • ask залишає вас у циклі підтвердження, водночас дозволяючи швидкі підтвердження.
  • Списки дозволеного для кожного агента запобігають перетіканню підтверджень одного агента до інших.
  • Підтвердження застосовуються лише до host exec-запитів від авторизованих відправників. Неавторизовані відправники не можуть виконувати /exec.
  • /exec security=full — це зручність рівня сеансу для авторизованих операторів, яка за задумом пропускає підтвердження. Щоб жорстко заблокувати host exec, встановіть security підтверджень у deny або забороніть інструмент exec через політику інструментів.

​
Пов’язане

Exec approvals - advanced

Безпечні бінарні файли, прив’язка інтерпретатора та пересилання підтверджень у чат.

Exec tool

Інструмент виконання команд shell.

Elevated mode

Аварійний шлях, який також пропускає підтвердження.

Sandboxing

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

Security

Модель безпеки та посилення захисту.

Sandbox vs tool policy vs elevated

Коли використовувати кожен елемент керування.

Skills

Поведінка автоматичного дозволу на основі Skills.