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

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

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

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

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

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

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

• Автентифіковані через Gateway викликачі вважаються довіреними операторами цього Gateway.
• Спарені вузли поширюють можливості довіреного оператора на хост Node.
• Підтвердження зменшують ризик випадкового виконання, але не є межею автентифікації для окремих користувачів або політикою доступу до файлової системи лише для читання.
• Після підтвердження команда може змінювати файли відповідно до дозволів файлової системи вибраного хоста або пісочниці.
• Підтверджені запуски на хості Node прив’язуються до канонічного контексту виконання: cwd, точного argv, прив’язки env за її наявності та зафіксованого шляху до виконуваного файла, коли це застосовно.
• Для сценаріїв оболонки та прямих викликів файлів через інтерпретатор або середовище виконання OpenClaw також намагається прив’язати один конкретний локальний файловий операнд. Якщо цей файл зміниться після підтвердження, але до виконання, запуск буде відхилено замість виконання зміненого вмісту.
• Прив’язка файла виконується за можливості й не є повною моделлю всіх шляхів завантаження інтерпретаторів або середовищ виконання. Якщо не вдається визначити рівно один конкретний локальний файл, OpenClaw відмовляється створювати запуск на основі підтвердження, а не вдавати повне охоплення.

Розподіл відповідальності в macOS

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

Перевірка ефективної політики

Повний довідник CLI (прапорці, виведення JSON, додавання й видалення зі списку дозволених): CLI підтверджень.

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

Якщо інтерфейс супутнього застосунку недоступний, будь-який запит, який за звичайних умов показав би запит на підтвердження, обробляється через резервну дію для запиту (типово: 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, коли ефективною політикою виконання команд OpenClaw є YOLO. Для керованих OpenClaw активних сеансів Claude ефективна політика виконання команд OpenClaw має вищий пріоритет за власний режим дозволів Claude: YOLO нормалізує запуск активних сеансів до --permission-mode bypassPermissions, а обмежувальна ефективна політика виконання команд нормалізує запуск активних сеансів до --permission-mode default, навіть якщо необроблені аргументи бекенда Claude вказують інший режим.

Якщо потрібне консервативніше налаштування, посильте політику виконання команд 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 — це аварійне скорочення, яке пропускає схвалення виконання команд лише тоді, коли і запитана політика, і файл схвалень хоста визначають 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), виконувані файли, на які посилаються відомі Skills, вважаються дозволеними на Node (Node macOS або автономному хості Node). Для отримання списку виконуваних файлів Skills через RPC Gateway використовується skills.bins. Вимкніть це, якщо потрібні суворі ручні списки дозволених команд.

Безпечні виконувані файли та пересилання схвалень

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

Редагування в інтерфейсі керування

Використовуйте картку Інтерфейс керування -> Вузли -> Схвалення виконання команд, щоб редагувати стандартні значення, перевизначення для окремих агентів і списки дозволених команд. Виберіть область (Стандартні значення або агент), налаштуйте політику, додайте або видаліть шаблони списку дозволених команд, а потім натисніть Зберегти. Інтерфейс показує метадані останнього використання для кожного шаблону, щоб список залишався впорядкованим.

Перемикач цілі дає змогу вибрати Gateway (локальні схвалення) або Node. Node мають оголошувати підтримку system.execApprovals.get/set (застосунок macOS або автономний хост Node). Якщо Node ще не оголошує підтримку схвалень виконання команд, відредагуйте його локальний файл схвалень безпосередньо.

Деякі хости Node, зокрема допоміжний застосунок Windows, використовують інший формат політики схвалення. Інтерфейс керування показує такі власні політики хоста лише для читання. Щоб відредагувати їх, використовуйте допоміжний застосунок або openclaw approvals set --node <id|name|ip> із власною структурою політики; дивіться CLI схвалень.

CLI: openclaw approvals підтримує редагування Gateway або Node — дивіться CLI схвалень.

Процедура схвалення

Коли потрібне підтвердження, Gateway транслює exec.approval.requested клієнтам операторів. Інтерфейс керування та застосунок macOS обробляють його через exec.approval.resolve, після чого Gateway пересилає схвалений запит хосту Node.

Для host=node запити на схвалення містять канонічне корисне навантаження systemRunPlan. Gateway використовує цей план як авторитетний контекст команди, cwd і сеансу під час пересилання схвалених запитів system.run:

• Шлях виконання команд Node заздалегідь готує один канонічний план.
• Запис схвалення зберігає цей план і метадані його прив’язки.
• Після схвалення остаточний пересланий виклик system.run повторно використовує збережений план, а не довіряє подальшим змінам викликувачем.
• Якщо викликувач змінює command, rawCommand, cwd, agentId або sessionKey після створення запиту на схвалення, Gateway відхиляє пересланий запуск через невідповідність схваленню.

Системні події та відмови

Після того як Node повідомляє про завершення, життєвий цикл виконання команд публікує системне повідомлення Exec finished у сеансі агента. OpenClaw також може надіслати повідомлення про виконання після надання схвалення та спливу tools.exec.approvalRunningNoticeMs (стандартне значення 10000, значення 0 вимикає його). Відхилення схвалення виконання команди є остаточним для команди хоста: команда не запускається.

• Для асинхронних схвалень головного агента з початковим сеансом OpenClaw надсилає повідомлення про відмову назад у цей сеанс як внутрішнє продовження, щоб агент припинив очікувати асинхронну команду й уникнув виправлення відсутнього результату.
• Якщо сеансу немає або його неможливо відновити, OpenClaw усе одно може стисло повідомити про відмову оператору або безпосередньо в маршрут чату.
• Відмови для сеансів субагентів і Cron не надсилаються назад у такий сеанс.

Схвалення виконання команд на хості Gateway породжують ту саму подію завершення життєвого циклу. Команди, для яких потрібне схвалення, повторно використовують ідентифікатор схвалення, щоб пов’язати очікуваний запит із повідомленням про його завершення або відмову (Exec finished (gateway id=...) / Exec denied (gateway id=...)).

Наслідки

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

Пов’язані матеріали