--- read_when: - Налаштування схвалень виконання або списків дозволів - Реалізація UX підтвердження виконання в застосунку macOS - Перегляд промптів для виходу з пісочниці та їхніх наслідків sidebarTitle: Exec approvals summary: 'Підтвердження виконання на хості: параметри політики, списки дозволів і робочий процес YOLO/суворий' title: Схвалення виконання x-i18n: generated_at: "2026-06-27T18:24:42Z" model: gpt-5.5 postprocess_version: locale-links-v1 provider: openai source_hash: 44a4a5c9c56da458fdb25d5fe698df305af17188695d8befc1d4cfd8e8333e96 source_path: tools/exec-approvals.md workflow: 16 --- Схвалення exec — це **запобіжник супровідного застосунку / хоста Node**, який дозволяє ізольованому агенту виконувати команди на реальному хості (`gateway` або `node`). Це блокувальний механізм безпеки: команди дозволені лише тоді, коли політика + список дозволених + (необов’язкове) схвалення користувача всі узгоджуються. Схвалення exec накладаються **поверх** політики інструментів і шлюзу підвищених прав (якщо elevated не встановлено в `full`, що пропускає схвалення). Огляд режимів `deny`, `allowlist`, `ask`, `auto`, `full`, зіставлення Codex Guardian і дозволів harness ACPX дивіться в [Режими дозволів](/uk/tools/permission-modes). Ефективна політика є **суворішою** з `tools.exec.*` і стандартних значень схвалень; якщо поле схвалень пропущено, використовується значення `tools.exec`. Host exec також використовує локальний стан схвалень на цій машині - локальне для хоста `ask: "always"` у файлі схвалень хоста виконання продовжує запитувати підтвердження, навіть якщо стандартні значення сеансу або конфігурації запитують `ask: "on-miss"`. ## Перегляд ефективної політики | Команда | Що вона показує | | ---------------------------------------------------------------- | -------------------------------------------------------------------------------------- | | `openclaw approvals get` / `--gateway` / `--node ` | Запитану політику, джерела політики хоста та ефективний результат. | | `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: ```text $OPENCLAW_STATE_DIR/exec-approvals.json # otherwise ~/.openclaw/exec-approvals.json ``` Стандартний socket схвалень використовує той самий корінь: `$OPENCLAW_STATE_DIR/exec-approvals.sock`, або `~/.openclaw/exec-approvals.sock`, коли змінну не задано. Приклад схеми: ```json { "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` - `deny` - блокувати всі запити host exec. - `allowlist` - дозволяти лише команди зі списку дозволених. - `full` - дозволяти все (еквівалентно elevated). ### `exec.ask` Налаштована політика ask для host exec. Керує базовою поведінкою prompt схвалення з `tools.exec.ask` і стандартних значень схвалень хоста. Параметр інструмента `ask` для окремого виклику (див. [Інструмент Exec](/uk/tools/exec#parameters)) може лише посилити цю базову лінію, а модельні виклики з каналів ігнорують його, коли ефективний ask хоста дорівнює `off`. - `off` - ніколи не показувати prompt. - `on-miss` - показувати prompt лише коли список дозволених не збігається. - `always` - показувати prompt для кожної команди. Довготривала довіра `allow-always` **не** пригнічує prompt, коли ефективний режим ask дорівнює `always`. ### `askFallback` Рішення, коли prompt потрібен, але UI недоступний. Якщо це поле пропущено, OpenClaw стандартно використовує `deny`. - `deny` - блокувати. - `allowlist` - дозволяти лише якщо список дозволених збігається. - `full` - дозволяти. ### `tools.exec.strictInlineEval` Коли `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` Керує лише представленням у 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.security` | `full` на `gateway`/`node` | | `tools.exec.ask` | `off` | | Host `askFallback` | `full` | **Важливі відмінності:** - `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-хоста “ніколи не питати” ```bash openclaw config set tools.exec.host gateway openclaw config set tools.exec.security full openclaw config set tools.exec.ask off openclaw gateway restart ``` ```bash openclaw approvals set --stdin <<'EOF' { version: 1, defaults: { security: "full", ask: "off", askFallback: "full" } } EOF ``` ### Локальний shortcut ```bash openclaw exec-policy preset yolo ``` Цей локальний shortcut оновлює обидва: - Локальні `tools.exec.host/security/ask`. - Стандартні значення локального файлу схвалень, зокрема `askFallback: "full"`. Він навмисно лише локальний. Щоб змінити схвалення gateway-хоста або node-хоста віддалено, використовуйте `openclaw approvals set --gateway` або `openclaw approvals set --node `. ### Хост Node Для хоста Node застосуйте той самий файл схвалень на цьому Node: ```bash openclaw approvals set --node --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]`). Для записів, створених вручну, аргументи об'єднуються одним пробілом, тому закріплюйте шаблон, коли потрібен точний збіг. ```json { "version": 1, "agents": { "main": { "allowlist": [ { "pattern": "python3", "argPattern": "^safe\\.py$" } ] } } } ``` Цей запис дозволяє `python3 safe.py`; `python3 other.py` не збігається зі списком дозволеного. Якщо для того самого бінарного файла також є запис лише за шляхом, аргументи без збігу все ще можуть повернутися до цього запису лише за шляхом. Не додавайте запис лише за шляхом, коли мета — обмежити бінарний файл оголошеними аргументами. Записи, збережені потоками підтвердження, можуть використовувати внутрішній формат розділювача для точного зіставлення argv. Віддавайте перевагу UI або потоку підтвердження, щоб повторно згенерувати ці записи, замість ручного редагування закодованого значення. Якщо OpenClaw не може розібрати argv для сегмента команди, записи з `argPattern` не збігаються. Кожен запис списку дозволеного підтримує: | Поле | Значення | | ------------------ | ------------------------------------------------------------- | | `pattern` | Glob-шаблон розв'язаного шляху до бінарного файла або 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 — додатково](/uk/tools/exec-approvals-advanced). ## Редагування в Control UI Використовуйте картку **Control UI → Nodes → Exec approvals**, щоб редагувати типові значення, перевизначення для окремих агентів і списки дозволеного. Виберіть область (типові значення або агент), налаштуйте політику, додайте/видаліть шаблони списку дозволеного, потім натисніть **Save**. UI показує метадані останнього використання для кожного шаблону, щоб ви могли підтримувати список упорядкованим. Селектор цілі вибирає **Gateway** (локальні підтвердження) або **Node**. Вузли мають оголошувати `system.execApprovals.get/set` (застосунок macOS або headless хост вузла). Якщо вузол ще не оголошує підтвердження exec, редагуйте його локальний файл підтверджень напряму. CLI: `openclaw approvals` підтримує редагування gateway або вузла — див. [CLI підтверджень](/uk/cli/approvals). ## Потік підтвердження Коли потрібен запит, 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` через політику інструментів. ## Пов'язане Безпечні бінарні файли, прив'язка інтерпретатора та пересилання підтверджень у чат. Інструмент виконання команд shell. Аварійний шлях, який також пропускає підтвердження. Режими sandbox і доступ до workspace. Модель безпеки та посилення захисту. Коли використовувати кожен елемент керування. Поведінка автоматичного дозволу на основі Skills.