Перейти до основного вмісту

Documentation Index

Fetch the complete documentation index at: https://docs.openclaw.ai/llms.txt

Use this file to discover all available pages before exploring further.

Схвалення 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 <id|name|ip>Запитану політику, джерела політики хоста та ефективний результат.
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-файлі на хості виконання:
~/.openclaw/exec-approvals.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

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

exec.ask

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

askFallback

askFallback
"deny" | "allowlist" | "full"
Рішення, коли prompt потрібен, але жоден UI недоступний.
  • deny - заблокувати.
  • allowlist - дозволити лише якщо allowlist збігається.
  • full - дозволити.

tools.exec.strictInlineEval

strictInlineEval
boolean
Коли 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

commandHighlighting
boolean
за замовчуванням:"false"
Керує лише представленням у запитах підтвердження 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.securityfull на gateway/node
tools.exec.askoff
Host askFallbackfull
Важливі відмінності:
  • 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”

1

Задайте запитану політику конфігурації

openclaw config set tools.exec.host gateway
openclaw config set tools.exec.security full
openclaw config set tools.exec.ask off
openclaw gateway restart
2

Узгодьте файл підтверджень хоста

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.
Воно навмисно лише локальне. Щоб змінити підтвердження gateway-host або node-host віддалено, використовуйте openclaw approvals set --gateway або openclaw approvals set --node <id|name|ip>.

Node host

Для node host застосуйте такий самий файл підтверджень на цьому node:
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 відхиляється.
  • Підтвердження 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]). Для записів, написаних вручну, аргументи об’єднуються одним пробілом, тож використовуйте якорі в шаблоні, коли потрібний точний збіг.
{
  "version": 1,
  "agents": {
    "main": {
      "allowlist": [
        {
          "pattern": "python3",
          "argPattern": "^safe\\.py$"
        }
      ]
    }
  }
}
Цей запис дозволяє python3 safe.py; python3 other.py є промахом списку дозволеного. Якщо запис лише зі шляхом для того самого бінарного файлу також присутній, аргументи без збігу все ще можуть повернутися до цього запису лише зі шляхом. Опустіть запис лише зі шляхом, коли мета — обмежити бінарний файл оголошеними аргументами. Записи, збережені потоками схвалення, можуть використовувати внутрішній формат розділювача для точного зіставлення argv. Надавайте перевагу UI або потоку схвалення, щоб повторно згенерувати ці записи, замість ручного редагування закодованого значення. Якщо OpenClaw не може розібрати argv для сегмента команди, записи з argPattern не збігаються. Кожен запис списку дозволеного підтримує:
ПолеЗначення
patternGlob розв’язаного шляху до бінарного файлу або 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 - розширено.

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

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

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

Коли потрібен запит, 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 через політику інструментів.

Пов’язане

Схвалення exec - розширено

Безпечні бінарні файли, прив’язка інтерпретатора та пересилання схвалень до чату.

Інструмент exec

Інструмент виконання shell-команд.

Підвищений режим

Аварійний шлях, який також обходить схвалення.

Ізоляція в sandbox

Режими sandbox і доступ до робочої області.

Безпека

Модель безпеки та посилення захисту.

Sandbox проти політики інструментів проти підвищеного режиму

Коли використовувати кожен механізм керування.

Skills

Поведінка автоматичного дозволення на основі Skills.