​

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

​

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

• хост gateway → процес openclaw на машині gateway
• хост node → runner вузла (companion app для macOS або headless-хост вузла)

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

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

​

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

{
  "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
• хост askFallback: full

• tools.exec.host=auto вибирає, де виконується exec: у пісочниці, якщо вона доступна, інакше на gateway.
• YOLO вибирає, як підтверджується виконання на хості: security=full плюс ask=off.
• У режимі YOLO OpenClaw не додає окремий евристичний шлюз підтвердження для обфускації команд поверх налаштованої політики виконання на хості.
• auto не робить маршрутизацію через gateway безкоштовним способом обходу із сеансу в пісочниці. Запит host=node на рівні окремого виклику дозволений із auto, а host=gateway дозволений із auto лише тоді, коли активне середовище виконання в пісочниці відсутнє. Якщо вам потрібне стабільне нетипове значення замість auto, установіть tools.exec.host або явно використовуйте /exec host=....

openclaw config set tools.exec.host gateway
openclaw config set tools.exec.security full
openclaw config set tools.exec.ask off
openclaw 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
• локальні типові значення ~/.openclaw/exec-approvals.json

openclaw approvals set --node <id|name|ip> --stdin <<'EOF'
{
  version: 1,
  defaults: {
    security: "full",
    ask: "off",
    askFallback: "full"
  }
}
EOF

• openclaw exec-policy не синхронізує підтвердження вузла
• openclaw exec-policy set --host 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)

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

​

Посилення inline eval інтерпретаторів (tools.exec.strictInlineEval)

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

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

​

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

• ~/Projects/**/bin/peekaboo
• ~/.local/bin/*
• /opt/homebrew/bin/rg

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

​

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

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

​

Safe bins (лише stdin)

• grep: --dereference-recursive, --directories, --exclude-from, --file, --recursive, -R, -d, -f, -r
• jq: --argfile, --from-file, --library-path, --rawfile, --slurpfile, -L, -f
• sort: --compress-program, --files0-from, --output, --random-source, --temporary-directory, -T, -o
• wc: --files0-from

​

Safe bins у порівнянні зі списком дозволених дій

• safeBins надходить із конфігурації (tools.exec.safeBins або agents.list[].tools.exec.safeBins для окремого агента).
• safeBinTrustedDirs надходить із конфігурації (tools.exec.safeBinTrustedDirs або agents.list[].tools.exec.safeBinTrustedDirs для окремого агента).
• safeBinProfiles надходить із конфігурації (tools.exec.safeBinProfiles або agents.list[].tools.exec.safeBinProfiles для окремого агента). Ключі профілю для окремого агента мають пріоритет над глобальними ключами.
• записи allowlist зберігаються в локальному для хоста ~/.openclaw/exec-approvals.json у agents.<id>.allowlist (або через Control UI / openclaw approvals allowlist ...).
• openclaw security audit показує попередження tools.exec.safe_bins_interpreter_unprofiled, коли двійкові файли інтерпретаторів/середовищ виконання з’являються в safeBins без явних профілів.
• openclaw doctor --fix може створити заготовки відсутніх записів safeBinProfiles.<bin> як {} (після цього перегляньте й посильте їх). Для двійкових файлів інтерпретаторів/середовищ виконання заготовки автоматично не створюються.

​

Редагування в Control UI

​

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

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

​

Команди інтерпретатора/середовища виконання

• Точний контекст argv/cwd/env завжди прив’язується.
• Форми прямого shell-скрипта і прямого файла середовища виконання прив’язуються в режимі best-effort до одного конкретного локального знімка файла.
• Поширені форми обгорток package manager, які все ще визначаються в один прямий локальний файл (наприклад, pnpm exec, pnpm node, npm exec, npx), розгортаються перед прив’язкою.
• Якщо OpenClaw не може визначити рівно один конкретний локальний файл для команди інтерпретатора/середовища виконання (наприклад, package scripts, форми eval, специфічні для середовища виконання ланцюжки завантажувачів або неоднозначні форми з кількома файлами), виконання на основі підтвердження забороняється замість того, щоб стверджувати семантичне покриття, якого насправді немає.
• Для таких робочих процесів надавайте перевагу пісочниці, окремій межі хоста або явному довіреному процесу allowlist/full, де оператор приймає ширшу семантику середовища виконання.

​

Поведінка доставлення followup

• Якщо існує дійсна зовнішня ціль доставлення (канал доставлення плюс ціль to), доставлення followup використовує цей канал.
• У потоках лише з webchat або внутрішнім сеансом без зовнішньої цілі доставлення followup залишається лише в межах сеансу (deliver: false).
• Якщо викликач явно запитує суворе зовнішнє доставлення без жодного зовнішнього каналу, що може бути визначений, запит завершується помилкою INVALID_REQUEST.
• Якщо ввімкнено bestEffortDeliver і не вдається визначити жоден зовнішній канал, доставлення знижується до режиму лише для сеансу замість помилки.

• команду + аргументи
• cwd
• id агента
• визначений шлях до виконуваного файла
• метадані хоста + політики

• Allow once → виконати зараз
• Always allow → додати до списку дозволених дій + виконати
• Deny → заблокувати

​

Пересилання підтверджень до чат-каналів

​

Пересилання підтверджень плагінів

​

Підтвердження в тому самому чаті на будь-якому каналі

​

Власне доставлення підтверджень

• політика виконання на хості й далі визначає, чи потрібне підтвердження exec
• approvals.exec керує пересиланням запитів на підтвердження в інші чат-призначення
• channels.<channel>.execApprovals керує тим, чи цей канал виступає власним клієнтом підтвердження

• канал підтримує власне доставлення підтверджень
• тих, хто може підтверджувати, можна визначити з явних execApprovals.approvers або з задокументованих резервних джерел цього каналу
• channels.<channel>.execApprovals.enabled не задано або має значення "auto"

• Discord: channels.discord.execApprovals.*
• Slack: channels.slack.execApprovals.*
• Telegram: channels.telegram.execApprovals.*

• Slack, Matrix, Microsoft Teams та подібні чати, що підтримують доставлення, використовують звичайну модель автентифікації каналу для /approve у тому самому чаті
• коли власний клієнт підтвердження автоматично вмикається, типовою ціллю власного доставлення стають DM тим, хто може підтверджувати
• для Discord і Telegram лише визначені особи, які можуть підтверджувати, можуть підтверджувати або відхиляти
• осіб, які можуть підтверджувати в Discord, можна задати явно (execApprovals.approvers) або вивести з commands.ownerAllowFrom
• осіб, які можуть підтверджувати в Telegram, можна задати явно (execApprovals.approvers) або вивести з наявної конфігурації власника (allowFrom, а також defaultTo для direct-message, де це підтримується)
• осіб, які можуть підтверджувати в Slack, можна задати явно (execApprovals.approvers) або вивести з commands.ownerAllowFrom
• власні кнопки Slack зберігають тип id підтвердження, тож id plugin: можуть визначати підтвердження плагінів без другого локального резервного шару Slack
• власна маршрутизація DM/каналу та швидкі реакції Matrix обробляють як підтвердження exec, так і підтвердження плагінів; авторизація плагінів і далі походить із channels.matrix.dm.allowFrom
• запитувач не обов’язково має бути особою, що може підтверджувати
• вихідний чат може підтверджувати безпосередньо через /approve, коли цей чат уже підтримує команди та відповіді
• власні кнопки підтвердження Discord маршрутизують за типом id підтвердження: id plugin: одразу переходять до підтверджень плагінів, усе інше — до підтверджень exec
• власні кнопки підтвердження Telegram дотримуються того самого обмеженого резервного переходу від exec до плагіна, що й /approve
• коли власний target вмикає доставлення у вихідний чат, запити на підтвердження містять текст команди
• очікувані підтвердження exec типово протерміновуються через 30 хвилин
• якщо жоден UI оператора або налаштований клієнт підтвердження не може прийняти запит, запит переходить до askFallback

• Discord
• Telegram

​

Потік IPC у macOS

• Режим Unix socket 0600, токен зберігається в exec-approvals.json.
• Перевірка однотипного UID однорангового процесу.
• Challenge/response (nonce + HMAC token + хеш запиту) + короткий TTL.

​

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

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

​

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

​

Наслідки

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

• Інструмент Exec
• Режим Elevated
• Skills

​

Пов’язане

• Exec — інструмент виконання shell-команд
• Пісочниця — режими пісочниці та доступ до робочого простору
• Безпека — модель безпеки та посилення захисту
• Пісочниця vs Політика інструментів vs Elevated — коли що використовувати