--- read_when: - Налаштування схвалень виконання або списків дозволеного - Реалізація UX підтвердження exec у застосунку macOS - Перегляд промптів для виходу з пісочниці та їхніх наслідків sidebarTitle: Exec approvals summary: 'Погодження виконання команд на хості: параметри політики, списки дозволених і робочий процес YOLO/суворий' title: Схвалення виконання x-i18n: generated_at: "2026-05-11T21:00:27Z" model: gpt-5.5 provider: openai source_hash: 2966a6f4633046941a9ef3267bad10f3a153956361b9f088fb3e29fcd3fcb99d source_path: tools/exec-approvals.md workflow: 16 --- Схвалення exec — це **запобіжний механізм застосунку-супутника / хоста Node**, який дає змогу пісочничному агенту запускати команди на реальному хості (`gateway` або `node`). Це захисне блокування: команди дозволені лише тоді, коли політика + allowlist + (необов’язково) схвалення користувача узгоджуються між собою. Схвалення exec накладаються **поверх** політики інструментів і gating підвищених прав (якщо elevated не встановлено в `full`, що пропускає схвалення). Ефективна політика є **суворішою** з `tools.exec.*` і типових значень схвалень; якщо поле схвалень пропущено, використовується значення `tools.exec`. Host exec також використовує локальний стан схвалень на цій машині - локальне для хоста `ask: "always"` у `~/.openclaw/exec-approvals.json` і далі показує запити, навіть якщо типові значення сеансу або конфігурації вимагають `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 fallback** (типово: `deny`). Нативні клієнти схвалень у чаті можуть додавати до повідомлення про очікуване схвалення можливості, специфічні для каналу. Наприклад, Matrix додає швидкі реакції (`✅` дозволити один раз, `❌` відхилити, `♾️` дозволяти завжди), водночас залишаючи команди `/approve ...` у повідомленні як запасний варіант. ## Де це застосовується Схвалення exec застосовуються локально на хості виконання: - **Хост Gateway** → процес `openclaw` на машині Gateway. - **Хост Node** → runner Node (застосунок-супутник macOS або headless-хост Node). ### Модель довіри - Виклики, автентифіковані Gateway, вважаються довіреними операторами для цього Gateway. - Спарені Node поширюють цю можливість довіреного оператора на хост Node. - Схвалення exec зменшують ризик випадкового виконання, але **не** є межею автентифікації для окремого користувача або політикою доступу до файлової системи лише для читання. - Після схвалення команда може змінювати файли відповідно до вибраних дозволів хоста або пісочниці файлової системи. - Схвалені запуски на хості Node прив’язують канонічний контекст виконання: канонічний cwd, точний argv, прив’язку env, якщо вона наявна, і закріплений шлях до виконуваного файла, коли це застосовно. - Для shell-скриптів і прямих викликів файлів інтерпретатора/runtime OpenClaw також намагається прив’язати один конкретний локальний файловий операнд. Якщо цей прив’язаний файл змінюється після схвалення, але до виконання, запуск відхиляється замість виконання зміненого вмісту. - Прив’язка файлів навмисно є best-effort, **а не** повною семантичною моделлю кожного шляху завантаження інтерпретатора/runtime. Якщо режим схвалення не може ідентифікувати рівно один конкретний локальний файл для прив’язки, він відмовляється створювати запуск на основі схвалення замість того, щоб удавати повне покриття. ### Поділ у macOS - **Сервіс хоста Node** пересилає `system.run` до **застосунку macOS** через local IPC. - **Застосунок macOS** застосовує схвалення та виконує команду в контексті UI. ## Налаштування та зберігання Схвалення зберігаються в локальному JSON-файлі на хості виконання: ```text ~/.openclaw/exec-approvals.json ``` Приклад схеми: ```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" } ] } } } ``` ## Регулятори політики ### `exec.security` - `deny` - блокує всі запити host exec. - `allowlist` - дозволяє лише команди з allowlist. - `full` - дозволяє все (еквівалент elevated). ### `exec.ask` - `off` - ніколи не показувати prompt. - `on-miss` - показувати prompt лише коли allowlist не збігається. - `always` - показувати prompt для кожної команди. Довготривала довіра `allow-always` **не** пригнічує prompts, коли ефективний режим ask дорівнює `always`. ### `askFallback` Рішення, коли prompt потрібен, але жоден UI недоступний. - `deny` - заблокувати. - `allowlist` - дозволити лише якщо allowlist збігається. - `full` - дозволити. ### `tools.exec.strictInlineEval` Коли `true`, OpenClaw розглядає форми inline code-eval як такі, що потребують лише схвалення, навіть якщо сам binary інтерпретатора є в allowlist. Defense-in-depth для завантажувачів інтерпретаторів, які не відображаються чисто на один стабільний файловий операнд. Приклади, які перехоплює strict-режим: - `python -c` - `node -e`, `node --eval`, `node -p` - `ruby -e` - `perl -e`, `perl -E` - `php -r` - `lua -e` - `osascript -e` У strict-режимі ці команди все одно потребують явного схвалення, а `allow-always` не зберігає для них нові записи allowlist автоматично. ### `tools.exec.commandHighlighting` Керує лише представленням у запитах підтвердження exec. Коли ввімкнено, OpenClaw може додавати отримані парсером діапазони команд, щоб Web-запити підтвердження могли підсвічувати токени команди. Установіть `true`, щоб увімкнути підсвічування тексту команди. Це налаштування **не** змінює `security`, `ask`, зіставлення зі списком дозволеного, строгу поведінку inline-eval, пересилання підтверджень або виконання команд. Його можна задати глобально в `tools.exec.commandHighlighting` або для окремого агента в `agents.list[].tools.exec.commandHighlighting`. ## Режим YOLO (без підтвердження) Якщо ви хочете, щоб host exec запускався без запитів підтвердження, потрібно відкрити **обидва** рівні політики: запитану політику exec у конфігурації OpenClaw (`tools.exec.*`) **і** локальну для хоста політику підтверджень у `~/.openclaw/exec-approvals.json`. YOLO є типовою поведінкою хоста, якщо ви явно її не посилите: | Рівень | Налаштування YOLO | | --------------------- | -------------------------- | | `tools.exec.security` | `full` на `gateway`/`node` | | `tools.exec.ask` | `off` | | Host `askFallback` | `full` | **Важливі відмінності:** - `tools.exec.host=auto` вибирає, **де** запускається exec: у пісочниці, коли вона доступна, інакше на gateway. - YOLO вибирає, **як** підтверджується host exec: `security=full` плюс `ask=off`. - У режимі YOLO OpenClaw **не** додає окремий евристичний шлюз підтвердження для обфускації команд або шар script-preflight-відхилення поверх налаштованої політики host exec. - `auto` не робить маршрутизацію gateway вільним перевизначенням із сесії в пісочниці. Запит `host=node` для окремого виклику дозволений з `auto`; `host=gateway` дозволений з `auto` лише тоді, коли немає активного середовища виконання пісочниці. Для стабільного неавтоматичного стандартного значення задайте `tools.exec.host` або явно використовуйте `/exec host=...`. Провайдери на основі CLI, які надають власний неінтерактивний режим дозволів, можуть дотримуватися цієї політики. Claude CLI додає `--permission-mode bypassPermissions`, коли запитана OpenClaw політика exec є YOLO. Перевизначте цю поведінку бекенда явними аргументами Claude в `agents.defaults.cliBackends.claude-cli.args` / `resumeArgs` - наприклад `--permission-mode default`, `acceptEdits` або `bypassPermissions`. Якщо потрібне консервативніше налаштування, посильте будь-який рівень назад до `allowlist` / `on-miss` або `deny`. ### Постійне налаштування gateway-host "never prompt" ```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 ``` ### Локальне скорочення ```bash openclaw exec-policy preset yolo ``` Це локальне скорочення оновлює обидва: - Локальні `tools.exec.host/security/ask`. - Локальні стандартні значення `~/.openclaw/exec-approvals.json`. Воно навмисно лише локальне. Щоб змінити підтвердження gateway-host або node-host віддалено, використовуйте `openclaw approvals set --gateway` або `openclaw approvals set --node `. ### Node host Для node host застосуйте такий самий файл підтверджень на цьому 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 ...`. ### Скорочення лише для сесії - `/exec security=full ask=off` змінює лише поточну сесію. - `/elevated full` — це аварійне скорочення, яке також пропускає підтвердження exec для цієї сесії. Якщо файл підтверджень хоста залишається суворішим за конфігурацію, суворіша політика хоста все одно має перевагу. ## Список дозволеного (для кожного агента) Списки дозволеного є **окремими для кожного агента**. Якщо існує кілька агентів, перемкніть у застосунку 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 оцінює регулярний вираз відносно розібраних аргументів команди, виключаючи токен виконуваного файлу (`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 хост вузла). Для отримання списку бінарних файлів Skills це використовує `skills.bins` через Gateway RPC. Вимкніть це, якщо вам потрібні суворі ручні списки дозволеного. - Це **неявний зручний список дозволеного**, окремий від ручних записів списку дозволених шляхів. - Він призначений для довірених операторських середовищ, де Gateway і вузол перебувають в одній межі довіри. - Якщо вам потрібна сувора явна довіра, залиште `autoAllowSkills: false` і використовуйте лише ручні записи списку дозволених шляхів. ## Безпечні бінарні файли та пересилання схвалень Про безпечні бінарні файли (швидкий шлях лише через stdin), деталі прив’язки інтерпретатора та те, як пересилати запити схвалення до Slack/Discord/Telegram (або запускати їх як нативні клієнти схвалення), див. [Схвалення exec - розширено](/uk/tools/exec-approvals-advanced). ## Редагування Control UI Використовуйте картку **Control UI → Вузли → Схвалення exec**, щоб редагувати типові значення, перевизначення для окремих агентів і списки дозволеного. Виберіть область дії (типові значення або агент), налаштуйте політику, додайте/видаліть шаблони списку дозволеного, потім натисніть **Зберегти**. UI показує метадані останнього використання для кожного шаблону, щоб ви могли підтримувати список охайним. Селектор цілі вибирає **Gateway** (локальні схвалення) або **вузол**. Вузли мають оголошувати `system.execApprovals.get/set` (застосунок macOS або headless хост вузла). Якщо вузол ще не оголошує схвалення exec, редагуйте його локальний `~/.openclaw/exec-approvals.json` напряму. 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 denied`. Вони публікуються в сеанс агента після того, як вузол повідомляє про подію. Схвалення exec на хості Gateway випускають ті самі події життєвого циклу, коли команда завершується (і, необов’язково, коли виконується довше за поріг). Exec, обмежені схваленням, повторно використовують ідентифікатор схвалення як `runId` у цих повідомленнях для зручної кореляції. ## Поведінка відхиленого схвалення Коли асинхронне схвалення exec відхилено, OpenClaw не дає агенту повторно використати вивід будь-якого попереднього запуску тієї самої команди в сеансі. Причина відхилення передається з явною вказівкою, що вивід команди недоступний, що не дає агенту стверджувати, ніби є новий вивід, або повторювати відхилену команду із застарілими результатами попереднього успішного запуску. ## Наслідки - **`full`** є потужним; за можливості надавайте перевагу спискам дозволеного. - **`ask`** залишає вас у циклі, водночас дозволяючи швидкі схвалення. - Списки дозволеного для окремих агентів запобігають потраплянню схвалень одного агента до інших. - Схвалення застосовуються лише до host-запитів exec від **авторизованих відправників**. Неавторизовані відправники не можуть виконувати `/exec`. - `/exec security=full` є зручністю рівня сеансу для авторизованих операторів і навмисно обходить схвалення. Щоб жорстко заблокувати host exec, установіть для безпеки схвалень `deny` або забороніть інструмент `exec` через політику інструментів. ## Пов’язане Безпечні бінарні файли, прив’язка інтерпретатора та пересилання схвалень до чату. Інструмент виконання shell-команд. Аварійний шлях, який також обходить схвалення. Режими sandbox і доступ до робочої області. Модель безпеки та посилення захисту. Коли використовувати кожен механізм керування. Поведінка автоматичного дозволення на основі Skills.