​

Підтвердження exec

​

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

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

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

• служба node host пересилає 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” без підтверджень

• запитана політика exec у конфігурації 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: у sandbox, якщо доступно, інакше на gateway.
• YOLO визначає, як підтверджується host exec: security=full плюс ask=off.
• У режимі YOLO OpenClaw не додає окремий евристичний бар’єр підтвердження для обфускації команд поверх налаштованої політики host exec.
• auto не перетворює маршрутизацію на gateway на вільне перевизначення із сесії в sandbox. Запит host=node для окремого виклику дозволений із auto, а host=gateway дозволений із auto лише тоді, коли немає активного середовища виконання sandbox. Якщо вам потрібне стабільне типове значення без 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 approvals set --node <id|name|ip> --stdin <<'EOF'
{
  version: 1,
  defaults: {
    security: "full",
    ask: "off",
    askFallback: "full"
  }
}
EOF

• /exec security=full ask=off змінює лише поточну сесію.
• /elevated full — це break-glass скорочення, яке також пропускає підтвердження exec для цієї сесії.

​

Параметри політики

​

Security (exec.security)

• deny: блокувати всі запити host exec.
• allowlist: дозволяти лише команди з allowlist.
• full: дозволяти все (еквівалент elevated).

​

Ask (exec.ask)

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

​

Ask fallback (askFallback)

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

​

Посилення для inline interpreter 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 не зберігає для них нові записи allowlist автоматично.

​

Allowlist (для кожного агента)

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

• id — стабільний UUID для ідентичності в UI (необов’язково)
• last used timestamp
• last used command
• last resolved path

​

Автодозвіл CLI навичок

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

​

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 проти allowlist

• 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

​

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

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

​

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

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

​

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

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

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

• Allow once → виконати зараз
• Always allow → додати до allowlist + виконати
• Deny → заблокувати

​

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

​

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

​

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

​

Нативна доставка підтверджень

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

• канал підтримує нативну доставку підтверджень
• схвалювачів можна розв’язати з явних execApprovals.approvers або з документованих для цього каналу fallback-джерел
• 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) або виведеними з наявної конфігурації owner (allowFrom, плюс defaultTo для direct message, де це підтримується)
• схвалювачі Slack можуть бути явними (execApprovals.approvers) або виведеними з commands.ownerAllowFrom
• нативні кнопки Slack зберігають вид ID підтвердження, тож ID plugin: можуть розв’язувати підтвердження plugin без другого локального fallback-рівня Slack
• нативна маршрутизація Matrix до DM/каналу стосується лише exec; підтвердження plugin у Matrix залишаються на спільному шляху /approve у тому самому чаті та необов’язковому пересиланні через approvals.plugin
• відправник запиту не обов’язково має бути схвалювачем
• початковий чат може підтвердити напряму через /approve, коли цей чат уже підтримує команди й відповіді
• нативні кнопки підтвердження Discord маршрутизуються за видом ID підтвердження: ID plugin: переходять безпосередньо до підтверджень plugin, усе інше — до підтверджень exec
• нативні кнопки підтвердження Telegram дотримуються того самого обмеженого fallback exec-to-plugin, що й /approve
• коли нативний target вмикає доставку до початкового чату, запити на підтвердження містять текст команди
• очікувані підтвердження exec типово спливають через 30 хвилин
• якщо жоден UI оператора або налаштований клієнт підтвердження не може прийняти запит, запит переходить до askFallback

• Discord
• Telegram

​

Потік IPC на macOS

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

​

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

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

​

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

​

Наслідки

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

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

​

Пов’язане

• Exec — інструмент виконання shell-команд
• Sandboxing — режими sandbox і доступ до робочого простору
• Security — модель безпеки та посилення
• Sandbox vs Tool Policy vs Elevated — коли що використовувати