---
read_when:
    - Налаштування затверджень виконання або списків дозволеного
    - Реалізація UX затвердження виконання у застосунку macOS
    - Перевірка підказок щодо виходу з пісочниці та їхніх наслідків
summary: Підказки щодо затвердження виконання, списків дозволеного та виходу з пісочниці
title: Затвердження виконання
x-i18n:
    generated_at: "2026-04-23T23:27:47Z"
    model: gpt-5.4
    provider: openai
    source_hash: 0d7c5cd24e7c1831d5a865da6fa20f4c23280a0ec12b9e8f7f3245170a05a37d
    source_path: tools/exec-approvals.md
    workflow: 15
---

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

<Note>
Ефективна політика — **суворіша** з `tools.exec.*` та типових значень затверджень; якщо поле затверджень пропущено, використовується значення `tools.exec`. Виконання на хості також використовує локальний стан затверджень на цій машині — локальне для хоста `ask: "always"` у `~/.openclaw/exec-approvals.json` продовжує показувати запит навіть тоді, коли типові значення сеансу або конфігурації вимагають `ask: "on-miss"`.
</Note>

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

- `openclaw approvals get`, `... --gateway`, `... --node <id|name|ip>` — показує запитану політику, джерела політики хоста та ефективний результат.
- `openclaw exec-policy show` — об’єднане подання для локальної машини.
- `openclaw exec-policy set|preset` — синхронізує локально запитану політику з локальним файлом затверджень хоста за один крок.

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

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

<Tip>
Нативні клієнти затвердження в чаті можуть додавати специфічні для каналу елементи керування до повідомлення з очікуванням затвердження. Наприклад, Matrix додає швидкі реакції (`✅` дозволити один раз, `❌` заборонити, `♾️` дозволити завжди), водночас залишаючи команди `/approve ...` у повідомленні як резервний варіант.
</Tip>

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

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

- **gateway host** → процес `openclaw` на машині Gateway
- **node host** → виконавець Node (застосунок-компаньйон macOS або headless-хост Node)

Примітка щодо моделі довіри:

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

Розподіл у macOS:

- **служба хоста Node** пересилає `system.run` до **застосунку macOS** через локальний IPC.
- **застосунок macOS** застосовує затвердження + виконує команду в контексті UI.

## Налаштування та зберігання

Затвердження зберігаються в локальному JSON-файлі на хості виконання:

`~/.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",
          "lastUsedAt": 1737150000000,
          "lastUsedCommand": "rg -n TODO",
          "lastResolvedPath": "/Users/user/Projects/.../bin/rg"
        }
      ]
    }
  }
}
```

## Режим "YOLO" без затвердження

Якщо ви хочете, щоб виконання на хості працювало без запитів на затвердження, потрібно відкрити **обидва** рівні політики:

- запитувана політика виконання в конфігурації OpenClaw (`tools.exec.*`)
- локальна для хоста політика затверджень у `~/.openclaw/exec-approvals.json`

Тепер це типова поведінка хоста, якщо ви явно не зробите її суворішою:

- `tools.exec.security`: `full` на `gateway`/`node`
- `tools.exec.ask`: `off`
- host `askFallback`: `full`

Важлива відмінність:

- `tools.exec.host=auto` визначає, де виконується exec: у пісочниці, якщо вона доступна, інакше на gateway.
- YOLO визначає, як затверджується виконання на хості: `security=full` плюс `ask=off`.
- Провайдери на основі CLI, які мають власний неінтерактивний режим дозволів, можуть дотримуватися цієї політики.
  Claude CLI додає `--permission-mode bypassPermissions`, коли запитана OpenClaw політика виконання є
  YOLO. Перевизначте цю поведінку бекенда явними аргументами Claude в
  `agents.defaults.cliBackends.claude-cli.args` / `resumeArgs`, наприклад
  `--permission-mode default`, `acceptEdits` або `bypassPermissions`.
- У режимі YOLO OpenClaw не додає окремий евристичний шлюз затвердження для обфускації команд або шар відхилення script-preflight поверх налаштованої політики виконання на хості.
- `auto` не перетворює маршрутизацію через gateway на безкоштовне перевизначення із сеансу в пісочниці. Запит на рівні виклику `host=node` дозволений із `auto`, а `host=gateway` дозволений із `auto` лише тоді, коли середовище виконання пісочниці неактивне. Якщо вам потрібне стабільне типове значення без auto, установіть `tools.exec.host` або використовуйте `/exec host=...` явно.

Якщо вам потрібне більш консервативне налаштування, знову зробіть будь-який із шарів суворішим до `allowlist` / `on-miss`
або `deny`.

Постійне налаштування gateway-host "ніколи не запитувати":

```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
```

Локальне скорочення для тієї самої політики gateway-host на поточній машині:

```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 <id|name|ip>`.

Для хоста Node застосуйте той самий файл затверджень на цій Node:

```bash
openclaw approvals set --node <id|name|ip> --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 (`exec.security`)

- **deny**: блокувати всі запити на виконання на хості.
- **allowlist**: дозволяти лише команди зі списку дозволеного.
- **full**: дозволяти все (еквівалент elevated).

### Ask (`exec.ask`)

- **off**: ніколи не показувати запит.
- **on-miss**: показувати запит лише тоді, коли список дозволеного не збігається.
- **always**: показувати запит для кожної команди.
- довготривала довіра `allow-always` не пригнічує запити, коли ефективний режим ask дорівнює `always`

### Ask fallback (`askFallback`)

Якщо потрібен запит, але жоден UI недоступний, резервна поведінка визначає:

- **deny**: блокувати.
- **allowlist**: дозволяти лише за наявності збігу зі списком дозволеного.
- **full**: дозволяти.

### Посилення inline interpreter eval (`tools.exec.strictInlineEval`)

Коли `tools.exec.strictInlineEval=true`, OpenClaw розглядає форми inline code-eval як такі, що потребують лише затвердження, навіть якщо сам двійковий файл інтерпретатора є в списку дозволеного.

Приклади:

- `python -c`
- `node -e`, `node --eval`, `node -p`
- `ruby -e`
- `perl -e`, `perl -E`
- `php -r`
- `lua -e`
- `osascript -e`

Це захист у глибину для завантажувачів інтерпретаторів, які не зіставляються чисто з одним стабільним файловим операндом. У строгому режимі:

- ці команди все одно потребують явного затвердження;
- `allow-always` не зберігає для них нові записи списку дозволеного автоматично.

## Список дозволеного (для кожного агента)

Списки дозволеного є **окремими для кожного агента**. Якщо існує кілька агентів, перемкніть агента,
якого ви редагуєте, у застосунку macOS. Шаблони — це **нечутливі до регістру glob-збіги**.
Шаблони мають розв’язуватися до **шляхів двійкових файлів** (записи лише з basename ігноруються).
Застарілі записи `agents.default` під час завантаження мігруються до `agents.main`.
Shell-ланцюжки, як-от `echo ok && pwd`, усе одно вимагають, щоб кожен сегмент верхнього рівня відповідав правилам списку дозволеного.

Приклади:

- `~/Projects/**/bin/peekaboo`
- `~/.local/bin/*`
- `/opt/homebrew/bin/rg`

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

- **id** — стабільний UUID, який використовується для ідентичності в UI (необов’язково)
- **last used** — позначка часу останнього використання
- **last used command**
- **last resolved path**

## Автодозвіл для CLI Skills

Коли ввімкнено **Auto-allow skill CLIs**, виконувані файли, на які посилаються відомі Skills,
розглядаються як такі, що входять до списку дозволеного на Node (macOS node або headless-хост Node). Для цього використовується
`skills.bins` через Gateway RPC, щоб отримати список bin для skill. Вимкніть це, якщо вам потрібні суворі списки дозволеного, задані вручну.

Важливі примітки щодо довіри:

- Це **неявний зручний список дозволеного**, окремий від записів ручного списку дозволеного за шляхами.
- Він призначений для середовищ довірених операторів, де Gateway і Node перебувають в одній межі довіри.
- Якщо вам потрібна сувора явна довіра, залиште `autoAllowSkills: false` і використовуйте лише ручні записи списку дозволеного за шляхами.

## Safe bins і пересилання затвердження

Щодо safe bins (швидкий шлях лише через stdin), деталей прив’язки інтерпретатора та того,
як пересилати запити на затвердження до Slack/Discord/Telegram (або запускати їх як нативні
клієнти затвердження), див. [Затвердження виконання — додатково](/uk/tools/exec-approvals-advanced).

<!-- moved to /tools/exec-approvals-advanced -->

## Редагування в UI керування

Використовуйте картку **Control UI → Nodes → Exec approvals**, щоб редагувати типові значення, перевизначення
для окремих агентів і списки дозволеного. Виберіть область (Defaults або агент), налаштуйте політику,
додайте/видаліть шаблони списку дозволеного, а потім натисніть **Save**. UI показує метадані **last used**
для кожного шаблону, щоб вам було легше підтримувати список в охайному стані.

Перемикач цілі вибирає **Gateway** (локальні затвердження) або **Node**. Node
мають оголошувати `system.execApprovals.get/set` (застосунок macOS або headless-хост Node).
Якщо Node ще не оголошує затвердження виконання, редагуйте її локальний
`~/.openclaw/exec-approvals.json` безпосередньо.

CLI: `openclaw approvals` підтримує редагування gateway або node (див. [CLI затверджень](/uk/cli/approvals)).

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

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

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

Це важливо для затримки асинхронного затвердження:

- шлях виконання node готує один канонічний план наперед
- запис затвердження зберігає цей план та його метадані прив’язки
- після затвердження остаточний пересланий виклик `system.run` повторно використовує збережений план
  замість того, щоб довіряти пізнішим змінам виклику
- якщо виклик змінює `command`, `rawCommand`, `cwd`, `agentId` або
  `sessionKey` після створення запиту на затвердження, gateway відхиляє
  пересланий запуск як невідповідність затвердженню

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

Життєвий цикл exec відображається як системні повідомлення:

- `Exec running` (лише якщо команда перевищує поріг сповіщення про виконання)
- `Exec finished`
- `Exec denied`

Вони публікуються в сеанс агента після того, як Node повідомляє про подію.
Затвердження виконання на gateway-host видають ті самі події життєвого циклу, коли команда завершується (і, за потреби, коли вона виконується довше за поріг).
Виконання з перевіркою через затвердження повторно використовують ідентифікатор затвердження як `runId` у цих повідомленнях для зручної кореляції.

## Поведінка у разі відхилення затвердження

Коли асинхронне затвердження виконання відхиляється, OpenClaw не дозволяє агенту повторно використовувати
вивід будь-якого попереднього запуску тієї самої команди в цьому сеансі. Причина відхилення
передається разом із явною вказівкою, що вивід команди недоступний, що не дає
агенту стверджувати, що є новий вивід, або повторювати відхилену команду зі
застарілими результатами з попереднього успішного запуску.

## Наслідки

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

## Пов’язане

<CardGroup cols={2}>
  <Card title="Затвердження виконання — додатково" href="/uk/tools/exec-approvals-advanced" icon="gear">
    Safe bins, прив’язка інтерпретатора та пересилання затверджень до чату.
  </Card>
  <Card title="Інструмент exec" href="/uk/tools/exec" icon="terminal">
    Інструмент виконання команд shell.
  </Card>
  <Card title="Режим elevated" href="/uk/tools/elevated" icon="shield-exclamation">
    Аварійний шлях, який також пропускає затвердження.
  </Card>
  <Card title="Пісочниця" href="/uk/gateway/sandboxing" icon="box">
    Режими пісочниці та доступ до робочого простору.
  </Card>
  <Card title="Безпека" href="/uk/gateway/security" icon="lock">
    Модель безпеки та посилення захисту.
  </Card>
  <Card title="Пісочниця vs політика інструментів vs elevated" href="/uk/gateway/sandbox-vs-tool-policy-vs-elevated" icon="sliders">
    Коли варто використовувати кожен із цих засобів керування.
  </Card>
  <Card title="Skills" href="/uk/tools/skills" icon="sparkles">
    Поведінка автодозволу на основі Skills.
  </Card>
</CardGroup>
