Схвалення виконання

Схвалення exec — це запобіжник супровідного застосунку / хоста Node, який дозволяє ізольованому агенту виконувати команди на реальному хості (gateway або node). Це блокувальний механізм безпеки: команди дозволені лише тоді, коли політика + список дозволених + (необов’язкове) схвалення користувача всі узгоджуються. Схвалення exec накладаються поверх політики інструментів і шлюзу підвищених прав (якщо elevated не встановлено в full, що пропускає схвалення).

Огляд режимів deny, allowlist, ask, auto, full, зіставлення Codex Guardian і дозволів harness ACPX дивіться в Режими дозволів.

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

Коли локальна область запитує host=node, exec-policy show повідомляє цю область як керовану Node під час виконання, замість того щоб удавати, що локальний файл схвалень є джерелом істини.

Якщо UI супровідного застосунку недоступний, будь-який запит, який зазвичай показував би prompt, вирішується через резервний режим ask (стандартно: deny).

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

Схвалення 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

exec.ask

askFallback

tools.exec.strictInlineEval

Приклади, які ловить 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

Це налаштування не змінює 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 до дозволу.

Провайдери на основі 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-хоста “ніколи не питати”

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

Локальний 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

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 не збігаються.

Кожен запис списку дозволеного підтримує:

Автоматичний дозвіл CLI Skills

Коли ввімкнено Автоматичний дозвіл CLI Skills, виконувані файли, на які посилаються відомі Skills, вважаються доданими до списку дозволеного на вузлах (вузол macOS або headless хост вузла). Для отримання списку бінарних файлів skill це використовує skills.bins через Gateway RPC. Вимкніть це, якщо хочете суворі ручні списки дозволеного.

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

Про безпечні бінарні файли (швидкий шлях лише через 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 через політику інструментів.

Пов'язане