--- read_when: - Налаштування схвалень виконання або списків дозволеного - Реалізація інтерфейсу підтвердження виконання команд у застосунку для macOS - Аналіз запитів на вихід із пісочниці та їхніх наслідків sidebarTitle: Exec approvals summary: 'Схвалення виконання команд на хості: параметри політики, списки дозволів і робочий процес YOLO/strict' title: Підтвердження виконання x-i18n: generated_at: "2026-07-12T13:46:04Z" model: gpt-5.6 postprocess_version: locale-links-v1 provider: openai source_hash: b44efdfe5a6c9f3cc978baef91d80d1f75d39627d3a16f5971800809a642a72c source_path: tools/exec-approvals.md workflow: 16 --- Підтвердження виконання — це **запобіжний механізм супутнього застосунку / хоста Node**, який дає змогу ізольованому агенту виконувати команди на реальному хості (`gateway` або `node`). Команди виконуються лише тоді, коли політика, список дозволених команд і (необов’язкове) підтвердження користувача узгоджуються. Підтвердження діють **поверх** політики інструментів і обмежень підвищених привілеїв (режим підвищених привілеїв `full` обходить їх). Огляд режимів `deny`, `allowlist`, `ask`, `auto`, `full`, зіставлення Codex Guardian і дозволів середовища ACPX наведено в розділі [Режими дозволів](/uk/tools/permission-modes). Ефективною політикою є **суворіша** з `tools.exec.*` і типових значень підтверджень: підтвердження можуть лише посилювати параметри безпеки й запитів, отримані з конфігурації, але ніколи не послаблювати їх. Якщо поле підтверджень не вказано, використовується значення `tools.exec`. Виконання на хості також використовує локальний стан підтверджень на цьому комп’ютері: локальне для хоста `ask: "always"` у файлі підтверджень хоста виконання продовжує показувати запити, навіть якщо типові значення сеансу або конфігурації задають `ask: "on-miss"`. ## Де це застосовується Підтвердження виконання примусово застосовуються локально на хості виконання: - **Хост Gateway** -> процес `openclaw` на комп’ютері Gateway. - **Хост Node** -> виконавець Node (супутній застосунок macOS або безголовий хост Node). ### Модель довіри - Автентифіковані через Gateway викликачі вважаються довіреними операторами цього Gateway. - Спарені вузли поширюють можливості довіреного оператора на хост Node. - Підтвердження зменшують ризик випадкового виконання, але **не є** межею автентифікації для окремих користувачів або політикою доступу до файлової системи лише для читання. - Після підтвердження команда може змінювати файли відповідно до дозволів файлової системи вибраного хоста або пісочниці. - Підтверджені запуски на хості Node прив’язуються до канонічного контексту виконання: cwd, точного argv, прив’язки env за її наявності та зафіксованого шляху до виконуваного файла, коли це застосовно. - Для сценаріїв оболонки та прямих викликів файлів через інтерпретатор або середовище виконання OpenClaw також намагається прив’язати один конкретний локальний файловий операнд. Якщо цей файл зміниться після підтвердження, але до виконання, запуск буде відхилено замість виконання зміненого вмісту. - Прив’язка файла виконується за можливості й не є повною моделлю всіх шляхів завантаження інтерпретаторів або середовищ виконання. Якщо не вдається визначити рівно один конкретний локальний файл, OpenClaw відмовляється створювати запуск на основі підтвердження, а не вдавати повне охоплення. ### Розподіл відповідальності в macOS - **Служба хоста Node** пересилає `system.run` до **застосунку macOS** через локальний IPC. - **Застосунок macOS** застосовує підтвердження та виконує команду в контексті інтерфейсу користувача. ## Перевірка ефективної політики | Команда | Що вона показує | | ----------------------------------------------------------------- | --------------------------------------------------------------------------------------- | | `openclaw approvals get` / `--gateway` / `--node ` | Запитану політику, джерела політики хоста й ефективний результат. | | `openclaw exec-policy show` | Об’єднане представлення для локального комп’ютера. | | `openclaw exec-policy set` / `preset` | Синхронізацію локальної запитаної політики з локальним файлом підтверджень хоста за один крок. | Перевизначення `/exec` для окремого сеансу не враховуються. Виконайте `/exec` у відповідному сеансі, щоб переглянути його поточні типові значення. Див. [перевизначення сеансу](/uk/tools/exec#session-overrides-exec). Повний довідник CLI (прапорці, виведення JSON, додавання й видалення зі списку дозволених): [CLI підтверджень](/uk/cli/approvals). Коли локальна область запитує `host=node`, `exec-policy show` повідомляє, що під час виконання цією областю керує Node, замість того щоб вважати локальний файл підтверджень джерелом істини. Якщо інтерфейс супутнього застосунку **недоступний**, будь-який запит, який за звичайних умов показав би запит на підтвердження, обробляється через **резервну дію для запиту** (типово: `deny`). Нативні клієнти підтверджень у чатах можуть додавати специфічні для каналу засоби взаємодії до повідомлення про очікуване підтвердження. Matrix додає швидкі реакції (`✅` дозволити один раз, `♾️` дозволяти завжди, `❌` заборонити), водночас залишаючи `/approve ...` у повідомленні як резервний варіант. ## Налаштування та зберігання Підтвердження зберігаються в локальному файлі JSON на хості виконання. Коли встановлено `OPENCLAW_STATE_DIR`, файл розміщується у відповідному каталозі стану; інакше використовується типовий каталог стану OpenClaw: ```text $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. Приклад схеми: ```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", "lastUsedAt": 1737150000000, "lastUsedCommand": "rg -n TODO", "lastResolvedPath": "/Users/user/Projects/.../bin/rg" } ] } } } ``` ## Параметри політики ### `tools.exec.mode` `tools.exec.mode` — рекомендована нормалізована поверхня політики виконання на хості: | Значення | Поведінка | | ----------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `deny` | Блокувати виконання на хості. | | `allowlist` | Без запиту виконувати лише команди зі списку дозволених. | | `ask` | Використовувати політику списку дозволених і запитувати підтвердження за відсутності збігу. | | `auto` | Використовувати політику списку дозволених, безпосередньо виконувати детерміновані збіги, а за відсутності збігу надсилати запит до нативного автоматичного рецензента OpenClaw, перш ніж звертатися до маршруту підтвердження людиною. | | `full` | Виконувати команди на хості без запитів на підтвердження. | Застарілі `tools.exec.security` / `tools.exec.ask` залишаються підтримуваними й досі застосовуються всюди, де для відповідної області не встановлено `mode`. ### `exec.security` - `deny` — блокувати всі запити виконання на хості. - `allowlist` — дозволяти лише команди зі списку дозволених. - `full` — дозволяти все (еквівалент підвищених привілеїв). Типовим значенням для хостів Gateway/Node є `full`; натомість для хоста `sandbox` типовим є `deny`. ### `exec.ask` Налаштована політика запитів для виконання на хості. Керує базовою поведінкою запитів на підтвердження, що походить із `tools.exec.ask` і типових значень підтверджень хоста. Типове значення — `off`. Параметр інструмента `ask` для окремого виклику (див. [Інструмент виконання](/uk/tools/exec#parameters)) може лише посилити цю базову політику, а виклики моделі, що походять із каналу, ігнорують його, коли ефективне значення запиту хоста — `off`. - `off` — ніколи не показувати запит. - `on-miss` — показувати запит лише тоді, коли список дозволених не має збігу. - `always` — показувати запит для кожної команди. Тривала довіра `allow-always` **не** вимикає запити, коли ефективний режим запитів — `always`. ### `askFallback` Рішення, коли запит потрібен, але жоден інтерфейс користувача недоступний (або час очікування запиту минув). Якщо значення не вказано, типовим є `deny`. - `deny` — блокувати. - `allowlist` — дозволяти лише за наявності збігу зі списком дозволених. - `full` — дозволяти. ### `tools.exec.strictInlineEval` Якщо `true`, форми вбудованого обчислення коду вимагають підтвердження, навіть якщо сам виконуваний файл інтерпретатора є в списку дозволених. Це поглиблений захист для завантажувачів інтерпретаторів, які неможливо однозначно зіставити з одним стабільним файловим операндом. Приклади, які виявляє суворий режим: `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` Лише для представлення: якщо параметр увімкнено, OpenClaw може додавати визначені синтаксичним аналізатором ділянки команд, щоб вебзапити на підтвердження могли підсвічувати токени команд. Це **не** змінює `security`, `ask`, зіставлення зі списком дозволених, поведінку суворого вбудованого обчислення, пересилання підтверджень або виконання команд. Установіть глобально через `tools.exec.commandHighlighting` або для окремого агента через `agents.list[].tools.exec.commandHighlighting`. ## Режим YOLO (без підтверджень) Щоб виконувати команди на хості без запитів на підтвердження, відкрийте **обидва** рівні політики: запитану політику виконання в конфігурації OpenClaw (`tools.exec.*`) **і** локальну політику підтверджень хоста у файлі підтверджень хоста виконання. Якщо `askFallback` не вказано, типовим значенням є `deny`. Явно встановіть для хоста `askFallback` значення `full`, коли запит на підтвердження за відсутності інтерфейсу має резервно завершуватися дозволом. | Рівень | Налаштування YOLO | | --------------------- | -------------------------- | | `tools.exec.security` | `full` для `gateway`/`node` | | `tools.exec.ask` | `off` | | `askFallback` хоста | `full` | **Важливі відмінності:** - `tools.exec.host=auto` визначає, **де** виконується команда: у пісочниці, якщо вона доступна, інакше — на Gateway. - YOLO визначає, **як** підтверджується виконання на хості: `security=full` разом із `ask=off`. - YOLO **не** додає окремого евристичного механізму підтвердження обфускованих команд або рівня попередньої перевірки сценаріїв поверх налаштованої політики виконання на хості. - `auto` не перетворює маршрутизацію на Gateway на вільне перевизначення з ізольованого сеансу. Запит `host=node` для окремого виклику дозволено з `auto`; `host=gateway` дозволено з `auto` лише тоді, коли середовище виконання пісочниці неактивне. Для стабільного типового значення без `auto` встановіть `tools.exec.host` або явно використайте `/exec host=...`. Провайдери на основі 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 ```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`, так і стандартні значення локального файлу схвалень (включно з `askFallback: "full"`). Воно навмисно діє лише локально. Щоб віддалено змінити схвалення хоста Gateway або хоста Node, використовуйте `openclaw approvals set --gateway` або `openclaw approvals set --node `. Інші вбудовані набори налаштувань: `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 --security --ask --ask-fallback ` із будь-якою підмножиною цих прапорців. ### Хост 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` відхиляється. - Схвалення виконання команд Node отримуються з Node під час виконання, тому для оновлень, спрямованих на Node, потрібно використовувати `openclaw approvals --node ...`. ### Скорочення лише для поточного сеансу - `/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]`). Для записів, створених вручну, аргументи об’єднуються одним пробілом, тому закріплюйте шаблон якорями, якщо потрібна точна відповідність. ```json { "version": 1, "agents": { "main": { "allowlist": [ { "pattern": "python3", "argPattern": "^safe\\.py$" } ] } } } ``` Цей запис дозволяє `python3 safe.py`; `python3 other.py` не відповідає списку дозволених команд. Якщо також наявний запис лише зі шляхом для того самого виконуваного файла, аргументи, які не відповідають шаблону, усе одно можуть використовувати цей запис лише зі шляхом як резервний. Не додавайте запис лише зі шляхом, якщо мета полягає в обмеженні виконуваного файла оголошеними аргументами. Записи, збережені через процедури схвалення, використовують внутрішній формат роздільників для точного зіставлення argv. Для повторного створення таких записів віддавайте перевагу інтерфейсу або процедурі схвалення, а не редагуванню закодованого значення вручну. Якщо OpenClaw не може розібрати argv для сегмента команди, записи з `argPattern` не відповідають йому. Кожен запис списку дозволених команд підтримує: | Поле | Значення | | ------------------ | --------------------------------------------------------------- | | `pattern` | Glob-шаблон визначеного шляху до виконуваного файла або лише назви команди | | `argPattern` | Необов’язковий регулярний вираз ECMAScript для argv; якщо відсутній, запис відповідає лише шляху | | `id` | Стабільний непрозорий ідентифікатор; за відсутності генерується як UUID | | `source` | Джерело запису, наприклад `allow-always` | | `commandText` | Застаріле введення звичайним текстом; відкидається під час завантаження | | `lastUsedAt` | Часова позначка останнього використання | | `lastUsedCommand` | Остання команда, що збіглася | | `lastResolvedPath` | Останній визначений шлях до виконуваного файла | ## Автоматичний дозвіл CLI із Skills Коли ввімкнено **Автоматичний дозвіл CLI із Skills** (`autoAllowSkills`), виконувані файли, на які посилаються відомі Skills, вважаються дозволеними на Node (Node macOS або автономному хості Node). Для отримання списку виконуваних файлів Skills через RPC Gateway використовується `skills.bins`. Вимкніть це, якщо потрібні суворі ручні списки дозволених команд. - Це **неявний зручний список дозволених команд**, окремий від ручних записів списку дозволених шляхів. - Він призначений для довірених середовищ операторів, де Gateway і Node належать до однієї межі довіри. - Якщо потрібна сувора явна довіра, залиште `autoAllowSkills: false` і використовуйте лише ручні записи списку дозволених шляхів. ## Безпечні виконувані файли та пересилання схвалень Відомості про безпечні виконувані файли (швидкий шлях лише через stdin), прив’язування інтерпретатора та пересилання запитів на схвалення до Slack/Discord/Telegram (або їх запуск як власних клієнтів схвалення) дивіться в розділі [Схвалення виконання команд — розширені можливості](/uk/tools/exec-approvals-advanced). ## Редагування в інтерфейсі керування Використовуйте картку **Інтерфейс керування -> Вузли -> Схвалення виконання команд**, щоб редагувати стандартні значення, перевизначення для окремих агентів і списки дозволених команд. Виберіть область (Стандартні значення або агент), налаштуйте політику, додайте або видаліть шаблони списку дозволених команд, а потім натисніть **Зберегти**. Інтерфейс показує метадані останнього використання для кожного шаблону, щоб список залишався впорядкованим. Перемикач цілі дає змогу вибрати **Gateway** (локальні схвалення) або **Node**. Node мають оголошувати підтримку `system.execApprovals.get/set` (застосунок macOS або автономний хост Node). Якщо Node ще не оголошує підтримку схвалень виконання команд, відредагуйте його локальний файл схвалень безпосередньо. Деякі хости Node, зокрема допоміжний застосунок Windows, використовують інший формат політики схвалення. Інтерфейс керування показує такі власні політики хоста лише для читання. Щоб відредагувати їх, використовуйте допоміжний застосунок або `openclaw approvals set --node ` із власною структурою політики; дивіться [CLI схвалень](/uk/cli/approvals). CLI: `openclaw approvals` підтримує редагування Gateway або Node — дивіться [CLI схвалень](/uk/cli/approvals). ## Процедура схвалення Коли потрібне підтвердження, 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` через політику інструментів. ## Пов’язані матеріали Безпечні виконувані файли, прив’язування інтерпретатора та пересилання схвалень у чат. Інструмент виконання команд оболонки. Аварійний шлях, який також пропускає схвалення. Режими ізоляції та доступ до робочого простору. Модель безпеки та посилення захисту. Коли використовувати кожен засіб керування. Автоматичний дозвіл на основі Skills.