openclaw/docs
openclaw/docs
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

chore(i18n): refresh uk translations

Browse Source
This commit is contained in:
openclaw-docs-i18n[bot] 2026-04-29 00:33:32 +00:00
parent 027cdf6a1c
commit 76c11b6ba0
2 changed files with 368 additions and 359 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

528
docs/uk/channels/discord.md
View File

File diff suppressed because it is too large Load Diff

199
docs/uk/tools/exec-approvals-advanced.md
View File

@ -1,30 +1,30 @@
---
read_when:
- Налаштування безпечних бінів або користувацьких профілів безпечних бінів
- Пересилання затверджень у Slack/Discord/Telegram або інші канали чату
- Реалізація нативного клієнта схвалення для каналу
summary: 'Розширені схвалення exec: безпечні бінарні файли, прив’язування інтерпретатора, пересилання схвалень, нативна доставка'
- Налаштування безпечних виконуваних файлів або користувацьких профілів безпечних виконуваних файлів
- Пересилання схвалень до Slack/Discord/Telegram або інших чат-каналів
- Реалізація нативного клієнта схвалень для каналу
summary: 'Розширені схвалення exec: безпечні виконувані файли, прив’язування інтерпретатора, передавання схвалень, нативна доставка'
title: Схвалення виконання — розширені
x-i18n:
generated_at: "2026-04-28T23:41:37Z"
generated_at: "2026-04-29T00:30:53Z"
model: gpt-5.5
provider: openai
source_hash: c134fbb417dab5b3642dc5a98d4076eef3825a2114b87f396e73271474882deb
source_hash: ad31e606eb8d0a5d99c59a53feee82212ee7d4fad7346c183315d6257a41cf43
source_path: tools/exec-approvals-advanced.md
workflow: 16
---
Розширені теми exec-схвалень: швидкий шлях `safeBins`, прив’язування інтерпретатора/середовища виконання та переспрямування схвалень у чат-канали (включно з нативною доставкою). Основну політику та потік схвалень див. у [Exec-схваленнях](/uk/tools/exec-approvals).
Розширені теми схвалення exec: швидкий шлях `safeBins`, прив’язування інтерпретатора/середовища виконання та пересилання схвалень у канали чату (включно з нативною доставкою). Основну політику та потік схвалення див. у [Схвалення exec](/uk/tools/exec-approvals).
## Безпечні бінарні файли (лише stdin)
`tools.exec.safeBins` визначає невеликий список **лише stdin** бінарних файлів (наприклад `cut`), які можуть запускатися в режимі списку дозволених **без** явних записів у списку дозволених. Безпечні бінарні файли відхиляють позиційні аргументи файлів і токени, схожі на шляхи, тому вони можуть працювати лише з вхідним потоком. Розглядайте це як вузький швидкий шлях для потокових фільтрів, а не як загальний список довіри.
<Warning>
**Не** додавайте бінарні файли інтерпретаторів або середовищ виконання (наприклад `python3`, `node`, `ruby`, `bash`, `sh`, `zsh`) до `safeBins`. Якщо команда може оцінювати код, виконувати підкоманди або читати файли за своєю природою, віддавайте перевагу явним записам списку дозволених і залишайте запити схвалення ввімкненими. Користувацькі безпечні бінарні файли мають визначати явний профіль у `tools.exec.safeBinProfiles.<bin>`.
**Не** додавайте інтерпретатори або бінарні файли середовищ виконання (наприклад `python3`, `node`, `ruby`, `bash`, `sh`, `zsh`) до `safeBins`. Якщо команда може виконувати код, запускати підкоманди або читати файли за задумом, віддавайте перевагу явним записам у списку дозволених і залишайте запити на схвалення ввімкненими. Користувацькі безпечні бінарні файли мають визначати явний профіль у `tools.exec.safeBinProfiles.<bin>`.
</Warning>
Стандартні безпечні бінарні файли:
Безпечні бінарні файли за замовчуванням:
[//]: # "SAFE_BIN_DEFAULTS:START"
@ -32,11 +32,11 @@ x-i18n:
[//]: # "SAFE_BIN_DEFAULTS:END"
`grep` і `sort` не входять до стандартного списку. Якщо ви вмикаєте їх, збережіть явні записи списку дозволених для їхніх сценаріїв не зі stdin. Для `grep` у режимі безпечного бінарного файлу передавайте шаблон через `-e`/`--regexp`; позиційна форма шаблону відхиляється, щоб файлові операнди не можна було приховати як неоднозначні позиційні аргументи.
`grep` і `sort` не входять до списку за замовчуванням. Якщо ви їх увімкнете, залиште явні записи у списку дозволених для їхніх сценаріїв не через stdin. Для `grep` у режимі безпечного бінарного файлу передавайте шаблон через `-e`/`--regexp`; позиційна форма шаблону відхиляється, щоб файлові операнди не можна було приховано передати як неоднозначні позиційні аргументи.
### Валідація argv і заборонені прапорці
### Перевірка argv і заборонені прапорці
Валідація є детермінованою лише за формою argv (без перевірок існування у файловій системі хоста), що запобігає поведінці оракула існування файлів через різницю між дозволом і забороною. Опції, орієнтовані на файли, заборонені для стандартних безпечних бінарних файлів; довгі опції валідуються за принципом fail-closed (невідомі прапорці та неоднозначні скорочення відхиляються).
Перевірка є детермінованою лише за формою argv (без перевірок існування у файловій системі хоста), що запобігає поведінці оракула існування файлів через відмінності allow/deny. Файлово-орієнтовані параметри заборонені для безпечних бінарних файлів за замовчуванням; довгі параметри перевіряються за принципом fail-closed (невідомі прапорці та неоднозначні скорочення відхиляються).
Заборонені прапорці за профілем безпечного бінарного файлу:
@ -49,176 +49,183 @@ x-i18n:
[//]: # "SAFE_BIN_DENIED_FLAGS:END"
Безпечні бінарні файли також примусово трактують токени argv як **буквальний текст** під час виконання (без globbing і без розгортання `$VARS`) для сегментів лише stdin, тому шаблони на кшталт `*` або `$HOME/...` не можна використати для прихованого читання файлів.
Безпечні бінарні файли також примусово обробляють токени argv як **літеральний текст** під час виконання (без globbing і без розгортання `$VARS`) для сегментів лише stdin, тому шаблони на кшталт `*` або `$HOME/...` не можна використати для прихованого читання файлів.
### Довірені каталоги бінарних файлів
Безпечні бінарні файли мають визначатися з довірених каталогів бінарних файлів (системні стандартні каталоги плюс опціональні `tools.exec.safeBinTrustedDirs`). Записи `PATH` ніколи не стають довіреними автоматично. Стандартні довірені каталоги навмисно мінімальні: `/bin`, `/usr/bin`. Якщо ваш виконуваний файл безпечного бінарного файлу розташований у шляхах пакетного менеджера/користувача (наприклад `/opt/homebrew/bin`, `/usr/local/bin`, `/opt/local/bin`, `/snap/bin`), додайте їх явно до `tools.exec.safeBinTrustedDirs`.
Безпечні бінарні файли мають розв’язуватися з довірених каталогів бінарних файлів (системні значення за замовчуванням плюс необов’язкові `tools.exec.safeBinTrustedDirs`). Записи `PATH` ніколи не стають довіреними автоматично. Довірені каталоги за замовчуванням навмисно мінімальні: `/bin`, `/usr/bin`. Якщо виконуваний файл безпечного бінарного файлу розташований у шляхах менеджера пакетів/користувача (наприклад `/opt/homebrew/bin`, `/usr/local/bin`, `/opt/local/bin`, `/snap/bin`), додайте їх явно до `tools.exec.safeBinTrustedDirs`.
### Ланцюжки shell, обгортки та мультиплексори
Ланцюжки shell (`&&`, `||`, `;`) дозволені, коли кожен сегмент верхнього рівня відповідає списку дозволених (включно з безпечними бінарними файлами або автоматичним дозволом Skills). Перенаправлення залишаються непідтримуваними в режимі списку дозволених. Підстановка команд (`$()` / зворотні лапки) відхиляється під час розбору списку дозволених, зокрема всередині подвійних лапок; використовуйте одинарні лапки, якщо вам потрібен буквальний текст `$()`.
Ланцюжки shell (`&&`, `||`, `;`) дозволені, коли кожен сегмент верхнього рівня відповідає списку дозволених (включно з безпечними бінарними файлами або автоматичним дозволом Skills). Перенаправлення залишаються непідтримуваними в режимі списку дозволених. Підстановка команд (`$()` / зворотні лапки) відхиляється під час розбору списку дозволених, зокрема всередині подвійних лапок; використовуйте одинарні лапки, якщо вам потрібен літеральний текст `$()`.
У схваленнях супровідного застосунку macOS сирий текст shell, що містить керівний синтаксис shell або синтаксис розгортання (`&&`, `||`, `;`, `|`, `` ` ``, `$`, `<`, `>`, `(`, `)`), вважається промахом списку дозволених, якщо сам бінарний файл shell не внесено до списку дозволених.
У схваленнях супровідного застосунку macOS сирий текст shell, що містить керувальний синтаксис shell або синтаксис розгортання (`&&`, `||`, `;`, `|`, `` ` ``, `$`, `<`, `>`, `(`, `)`), розглядається як промах списку дозволених, якщо сам бінарний файл shell не внесено до списку дозволених.
Для обгорток shell (`bash|sh|zsh ... -c/-lc`) request-scoped перевизначення env зводяться до невеликого явного списку дозволених (`TERM`, `LANG`, `LC_*`, `COLORTERM`, `NO_COLOR`, `FORCE_COLOR`).
Для обгорток shell (`bash|sh|zsh ... -c/-lc`) request-scoped перевизначення env скорочуються до невеликого явного списку дозволених (`TERM`, `LANG`, `LC_*`, `COLORTERM`, `NO_COLOR`, `FORCE_COLOR`).
Для рішень `allow-always` у режимі списку дозволених відомі диспетчерські обгортки (`env`, `nice`, `nohup`, `stdbuf`, `timeout`) зберігають шлях внутрішнього виконуваного файлу замість шляху обгортки. Мультиплексори shell (`busybox`, `toybox`) розгортаються для shell-аплетів (`sh`, `ash` тощо) так само. Якщо обгортку або мультиплексор не можна безпечно розгорнути, жоден запис списку дозволених автоматично не зберігається.
Для рішень `allow-always` у режимі списку дозволених відомі dispatch-обгортки (`env`, `nice`, `nohup`, `stdbuf`, `timeout`) зберігають шлях до внутрішнього виконуваного файлу замість шляху до обгортки. Мультиплексори shell (`busybox`, `toybox`) розгортаються для аплетів shell (`sh`, `ash` тощо) так само. Якщо обгортку або мультиплексор неможливо безпечно розгорнути, запис у списку дозволених автоматично не зберігається.
Якщо ви додаєте інтерпретатори на кшталт `python3` або `node` до списку дозволених, віддавайте перевагу `tools.exec.strictInlineEval=true`, щоб inline eval усе одно потребував явного схвалення. У strict-режимі `allow-always` усе ще може зберігати безпечні виклики інтерпретатора/скрипта, але носії inline-eval автоматично не зберігаються.
Якщо ви додаєте інтерпретатори на кшталт `python3` або `node` до списку дозволених, віддавайте перевагу `tools.exec.strictInlineEval=true`, щоб inline eval усе одно вимагав явного схвалення. У строгому режимі `allow-always` усе ще може зберігати безпечні виклики інтерпретатора/скрипта, але носії inline-eval не зберігаються автоматично.
### Безпечні бінарні файли порівняно зі списком дозволених
### Безпечні бінарні файли проти списку дозволених
| Тема | `tools.exec.safeBins` | Список дозволених (`exec-approvals.json`) |
| Тема | `tools.exec.safeBins` | Список дозволених (`exec-approvals.json`) |
| ---------------- | ------------------------------------------------------ | ---------------------------------------------------------------------------------- |
| Мета | Автоматично дозволяти вузькі фільтри stdin | Явно довіряти конкретним виконуваним файлам |
| Тип збігу | Ім’я виконуваного файлу + політика argv безпечного бінарного файлу | Glob визначеного шляху виконуваного файлу або glob голого імені команди для команд, викликаних через PATH |
| Область аргументів | Обмежена профілем безпечного бінарного файлу та правилами буквальних токенів | Лише збіг шляху; аргументи в іншому є вашою відповідальністю |
| Типові приклади | `head`, `tail`, `tr`, `wc` | `jq`, `python3`, `node`, `ffmpeg`, користувацькі CLI |
| Найкраще використання | Низькоризикові перетворення тексту в конвеєрах | Будь-який інструмент із ширшою поведінкою або побічними ефектами |
| Мета | Автоматично дозволяти вузькі stdin-фільтри | Явно довіряти конкретним виконуваним файлам |
| Тип збігу | Ім’я виконуваного файлу + політика argv безпечного бінарного файлу | Glob розв’язаного шляху виконуваного файлу або glob простої назви команди для команд, викликаних через PATH |
| Область аргументів | Обмежена профілем безпечного бінарного файлу та правилами літеральних токенів | Лише збіг шляху; аргументи в іншому є вашою відповідальністю |
| Типові приклади | `head`, `tail`, `tr`, `wc` | `jq`, `python3`, `node`, `ffmpeg`, користувацькі CLI |
| Найкраще застосування | Низькоризикові перетворення тексту в конвеєрах | Будь-який інструмент із ширшою поведінкою або побічними ефектами |
Розташування конфігурації:
- `safeBins` надходить із конфігурації (`tools.exec.safeBins` або per-agent `agents.list[].tools.exec.safeBins`).
- `safeBinTrustedDirs` надходить із конфігурації (`tools.exec.safeBinTrustedDirs` або per-agent `agents.list[].tools.exec.safeBinTrustedDirs`).
- `safeBinProfiles` надходить із конфігурації (`tools.exec.safeBinProfiles` або per-agent `agents.list[].tools.exec.safeBinProfiles`). Ключі профілю per-agent перевизначають глобальні ключі.
- Записи списку дозволених зберігаються у host-local `~/.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>` як `{}` (перегляньте й посильте після цього). Бінарні файли інтерпретатора/середовища виконання не генеруються автоматично.
- `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` для окремого агента). Ключі профілів окремого агента перевизначають глобальні ключі.
- Записи списку дозволених зберігаються в локальному для хоста `~/.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>` як `{}` (після цього перегляньте й посильте їх). Інтерпретатор/бінарні файли середовища виконання не створюються автоматично.
Приклад користувацького профілю:
__OC_I18N_900000__
Якщо ви явно додаєте `jq` до `safeBins`, OpenClaw усе одно відхиляє builtin `env` у режимі безпечного бінарного файлу, тому `jq -n env` не може вивантажити середовище процесу хоста без явного шляху в списку дозволених або запиту схвалення.
Якщо ви явно додаєте `jq` до `safeBins`, OpenClaw усе одно відхиляє builtin `env` у режимі безпечного бінарного файлу, щоб `jq -n env` не міг вивантажити середовище процесу хоста без явного шляху у списку дозволених або запиту на схвалення.
## Команди інтерпретатора/середовища виконання
Запуски інтерпретатора/середовища виконання, підкріплені схваленням, навмисно консервативні:
Запуски інтерпретатора/середовища виконання з опорою на схвалення навмисно консервативні:
- Точний контекст argv/cwd/env завжди прив’язується.
- Прямі форми shell-скрипта та прямі форми runtime-файлу best-effort прив’язуються до одного конкретного локального знімка файлу.
- Поширені форми обгорток пакетних менеджерів, які все ще визначаються до одного прямого локального файлу (наприклад `pnpm exec`, `pnpm node`, `npm exec`, `npx`), розгортаються перед прив’язуванням.
- Якщо OpenClaw не може ідентифікувати рівно один конкретний локальний файл для команди інтерпретатора/середовища виконання (наприклад пакетні скрипти, форми eval, runtime-specific ланцюги завантажувачів або неоднозначні multi-file форми), виконання, підкріплене схваленням, забороняється замість того, щоб заявляти про семантичне покриття, якого воно не має.
- Для таких сценаріїв віддавайте перевагу sandboxing, окремій межі хоста або явному довіреному списку дозволених/повному workflow, де оператор приймає ширшу семантику runtime.
- Прямі форми shell-скрипта та прямі форми файла середовища виконання найкращим можливим способом прив’язуються до одного конкретного знімка локального файла.
- Поширені форми обгорток менеджерів пакетів, які все ще розв’язуються в один прямий локальний файл (наприклад `pnpm exec`, `pnpm node`, `npm exec`, `npx`), розгортаються перед прив’язуванням.
- Якщо OpenClaw не може ідентифікувати рівно один конкретний локальний файл для команди інтерпретатора/середовища виконання (наприклад package scripts, eval-форми, ланцюжки завантажувачів, специфічні для середовища виконання, або неоднозначні багатофайлові форми), виконання з опорою на схвалення відхиляється замість того, щоб заявляти семантичне покриття, якого воно не має.
- Для таких сценаріїв віддавайте перевагу sandboxing, окремій межі хоста або явному довіреному списку дозволених/повному робочому процесу, де оператор приймає ширшу семантику середовища виконання.
Коли потрібні схвалення, інструмент exec негайно повертає id схвалення. Використовуйте цей id, щоб співвідносити пізніші системні події (`Exec finished` / `Exec denied`). Якщо рішення не надійде до timeout, запит трактується як timeout схвалення і показується як причина відмови.
Коли потрібні схвалення, інструмент exec негайно повертає approval id. Використовуйте цей id для зіставлення з пізнішими системними подіями (`Exec finished` / `Exec denied`). Якщо рішення не надходить до завершення timeout, запит розглядається як timeout схвалення й відображається як причина відмови.
### Поведінка доставки followup
Після завершення схваленого async exec OpenClaw надсилає followup turn `agent` у той самий сеанс.
Після завершення схваленого async exec OpenClaw надсилає followup `agent` turn до тієї самої сесії.
- Якщо існує валідна зовнішня ціль доставки (канал, придатний для доставки, плюс target `to`), followup-доставка використовує цей канал.
- У webchat-only або internal-session потоках без зовнішньої цілі followup-доставка залишається лише в межах сеансу (`deliver: false`).
- Якщо caller явно запитує strict зовнішню доставку без визначеного зовнішнього каналу, запит завершується помилкою `INVALID_REQUEST`.
- Якщо `bestEffortDeliver` увімкнено і зовнішній канал не можна визначити, доставка знижується до session-only замість помилки.
- Якщо існує дійсна зовнішня ціль доставки (deliverable channel плюс ціль `to`), followup-доставка використовує цей канал.
- У webchat-only або internal-session потоках без зовнішньої цілі followup-доставка залишається лише в межах сесії (`deliver: false`).
- Якщо викликач явно запитує сувору зовнішню доставку без розв’язуваного зовнішнього каналу, запит завершується помилкою `INVALID_REQUEST`.
- Якщо `bestEffortDeliver` увімкнено і зовнішній канал не може бути розв’язаний, доставка понижується до лише сесійної замість помилки.
## Переспрямування схвалень у чат-канали
## Пересилання схвалень у канали чату
Ви можете переспрямовувати запити exec-схвалень у будь-який чат-канал (включно з каналами Plugin) і схвалювати їх через `/approve`. Це використовує звичайний конвеєр вихідної доставки.
Ви можете пересилати запити на схвалення exec до будь-якого каналу чату (включно з plugin channels) і схвалювати їх через `/approve`. Це використовує звичайний конвеєр вихідної доставки.
Конфігурація:
__OC_I18N_900001__
Відповідь у чаті:
__OC_I18N_900002__
Команда `/approve` обробляє і exec-схвалення, і Plugin-схвалення. Якщо ID не відповідає pending exec-схваленню, вона автоматично перевіряє натомість Plugin-схвалення.
Команда `/approve` обробляє як схвалення exec, так і схвалення plugin. Якщо ID не відповідає жодному очікуваному схваленню exec, вона автоматично перевіряє натомість схвалення plugin.
### Переспрямування Plugin-схвалень
### Пересилання схвалень Plugin
Переспрямування Plugin-схвалень використовує той самий конвеєр доставки, що й exec-схвалення, але має власну незалежну конфігурацію під `approvals.plugin`. Увімкнення або вимкнення одного не впливає на інше.
Пересилання схвалень Plugin використовує той самий конвеєр доставки, що й схвалення exec, але має власну незалежну конфігурацію в `approvals.plugin`. Увімкнення або вимкнення одного не впливає на інше.
__OC_I18N_900003__
Форма конфігурації ідентична `approvals.exec`: `enabled`, `mode`, `agentFilter`, `sessionFilter` і `targets` працюють так само.
Форма конфігурації ідентична до `approvals.exec`: `enabled`, `mode`, `agentFilter`, `sessionFilter` і `targets` працюють так само.
Канали, що підтримують спільні інтерактивні відповіді, рендерять ті самі кнопки схвалення і для exec-, і для Plugin-схвалень. Канали без спільного інтерактивного UI повертаються до звичайного тексту з інструкціями `/approve`.
Канали, що підтримують спільні інтерактивні відповіді, показують ті самі кнопки схвалення як для exec, так і для схвалень plugin. Канали без спільного інтерактивного UI повертаються до простого тексту з інструкціями `/approve`.
### Схвалення в тому самому чаті на будь-якому каналі
Коли запит exec- або Plugin-схвалення походить із чат-поверхні, придатної для доставки, той самий чат тепер може схвалити його через `/approve` за замовчуванням. Це застосовується до каналів, таких як Slack, Matrix і Microsoft Teams, на додачу до наявних потоків Web UI і terminal UI.
Коли запит на схвалення exec або plugin походить із deliverable chat surface, той самий чат тепер може схвалити його через `/approve` за замовчуванням. Це застосовується до таких каналів, як Slack, Matrix і Microsoft Teams, на додачу до наявних потоків Web UI і terminal UI.
Цей спільний шлях текстової команди використовує звичайну модель автентифікації каналу для цієї розмови. Якщо початковий чат уже може надсилати команди й отримувати відповіді, запитам схвалення більше не потрібен окремий нативний адаптер доставки лише для того, щоб залишатися pending.
Цей спільний шлях текстових команд використовує звичайну модель авторизації каналу для цієї розмови. Якщо початковий чат уже може надсилати команди й отримувати відповіді, запитам на схвалення більше не потрібен окремий native delivery adapter лише для того, щоб залишатися очікуваними.
Discord і Telegram також підтримують same-chat `/approve`, але ці канали все ще використовують свій визначений список approver для авторизації, навіть коли нативну доставку схвалень вимкнено.
Discord і Telegram також підтримують same-chat `/approve`, але ці канали все ще використовують свій розв’язаний список approver для авторизації, навіть коли нативну доставку схвалень вимкнено.
Для Telegram та інших нативних клієнтів схвалень, які викликають Gateway напряму, цей fallback навмисно обмежений помилками "approval not found". Справжня відмова/помилка exec-схвалення не повторюється непомітно як Plugin-схвалення.
Для Telegram та інших native approval clients, які викликають Gateway напряму, цей fallback навмисно обмежений помилками "approval not found". Реальна відмова/помилка схвалення exec не повторюється непомітно як схвалення plugin.
### Нативна доставка схвалень
Деякі канали також можуть діяти як нативні клієнти схвалень. Нативні клієнти додають approver DM, розсилання в початковий чат і channel-specific інтерактивний UX схвалення поверх спільного same-chat потоку `/approve`.
Деякі канали також можуть діяти як native approval clients. Native clients додають DM для approver, fanout до origin-chat і специфічний для каналу інтерактивний UX схвалення поверх спільного same-chat потоку `/approve`.
Коли доступні нативні картки/кнопки схвалення, цей нативний UI є основним
шляхом для агента. Агент не повинен також дублювати звичайну чат-команду
`/approve`, якщо результат інструмента не каже, що чат-схвалення недоступні або
шляхом, призначеним для агента. Агент не повинен також дублювати звичайну команду чату
`/approve`, якщо результат інструмента не каже, що схвалення в чаті недоступні або
ручне схвалення є єдиним шляхом, що залишився.
Загальна модель:
- політика виконання хоста й надалі вирішує, чи потрібне схвалення виконання
- `approvals.exec` керує пересиланням запитів на схвалення до інших чат-напрямків
- `channels.<channel>.execApprovals` керує тим, чи цей канал діє як нативний клієнт схвалення
- політика host exec надалі вирішує, чи потрібне схвалення exec
- `approvals.exec` керує пересиланням запитів на схвалення до інших чат-призначень
- `channels.<channel>.execApprovals` керує тим, чи цей канал діє як нативний клієнт схвалень
Нативні клієнти схвалення автоматично вмикають доставку спершу в DM, коли істинні всі ці умови:
Нативні клієнти схвалень автоматично вмикають доставку спочатку в DM, коли виконуються всі ці умови:
- канал підтримує нативну доставку схвалень
- схвалювачів можна визначити з явних `execApprovals.approvers` або ідентичності
власника, як-от `commands.ownerAllowFrom`
- `channels.<channel>.execApprovals.enabled` не встановлено або має значення `"auto"`
- `channels.<channel>.execApprovals.enabled` не задано або має значення `"auto"`
Установіть `enabled: false`, щоб явно вимкнути нативний клієнт схвалення. Установіть `enabled: true`, щоб примусово
ввімкнути його, коли схвалювачів визначено. Доставка в публічний початковий чат залишається явною через
Задайте `enabled: false`, щоб явно вимкнути нативний клієнт схвалень. Задайте `enabled: true`, щоб примусово
ввімкнути його, коли схвалювачів визначено. Публічна доставка до початкового чату лишається явною через
`channels.<channel>.execApprovals.target`.
FAQ: [Чому є дві конфігурації схвалення виконання для чат-схвалень?](/help/faq-first-run#why-are-there-two-exec-approval-configs-for-chat-approvals)
Поширені запитання: [Чому є дві конфігурації схвалення exec для схвалень у чаті?](/help/faq-first-run#why-are-there-two-exec-approval-configs-for-chat-approvals)
- Discord: `channels.discord.execApprovals.*`
- Slack: `channels.slack.execApprovals.*`
- Telegram: `channels.telegram.execApprovals.*`
Ці нативні клієнти схвалення додають маршрутизацію в DM та необов’язкове розсилання в канали поверх спільного
потоку `/approve` в тому самому чаті та спільних кнопок схвалення.
Ці нативні клієнти схвалень додають маршрутизацію DM і необов’язкове розсилання в канали поверх спільного
потоку `/approve` у тому самому чаті та спільних кнопок схвалення.
Спільна поведінка:
- Slack, Matrix, Microsoft Teams і подібні чати з доставкою використовують звичайну модель автентифікації каналу
для `/approve` в тому самому чаті
- коли нативний клієнт схвалення автоматично вмикається, типовою нативною ціллю доставки є DM схвалювачів
- Slack, Matrix, Microsoft Teams та подібні доставні чати використовують звичайну модель автентифікації каналу
для `/approve` у тому самому чаті
- коли нативний клієнт схвалень автоматично вмикається, ціль нативної доставки за замовчуванням — DM схвалювачів
- для Discord і Telegram схвалити або відхилити можуть лише визначені схвалювачі
- схвалювачі Discord можуть бути явними (`execApprovals.approvers`) або виведеними з `commands.ownerAllowFrom`
- схвалювачі Telegram можуть бути явними (`execApprovals.approvers`) або виведеними з `commands.ownerAllowFrom`
- схвалювачі Slack можуть бути явними (`execApprovals.approvers`) або виведеними з `commands.ownerAllowFrom`
- нативні кнопки Slack зберігають вид id схвалення, тому id `plugin:` можуть визначати схвалення Plugin
без другого локального резервного шару Slack
- нативна маршрутизація Matrix у DM/канал і реакції-скорочення обробляють і схвалення виконання, і схвалення Plugin;
авторизація Plugin усе ще походить із `channels.matrix.dm.allowFrom`
- нативні запити Matrix містять вміст користувацької події `com.openclaw.approval` у першій події запиту,
щоб Matrix-клієнти, обізнані про OpenClaw, могли читати структурований стан схвалення, тоді як стандартні клієнти
зберігають звичайний текстовий резервний варіант `/approve`
- запитувачеві не потрібно бути схвалювачем
- початковий чат може схвалювати напряму через `/approve`, коли цей чат уже підтримує команди та відповіді
- нативні кнопки схвалення Discord маршрутизують за видом id схвалення: id `plugin:` переходять
безпосередньо до схвалень Plugin, усе інше переходить до схвалень виконання
- нативні кнопки схвалення Telegram дотримуються того самого обмеженого резервного переходу від виконання до Plugin, що й `/approve`
- коли нативний `target` вмикає доставку в початковий чат, запити на схвалення містять текст команди
- очікувані схвалення виконання за замовчуванням спливають через 30 хвилин
- якщо жоден операторський UI або налаштований клієнт схвалення не може прийняти запит, запит повертається до `askFallback`
- нативні кнопки Slack зберігають різновид id схвалення, тому id `plugin:` можуть визначати схвалення Plugin
без другого резервного шару, локального для Slack
- нативна маршрутизація DM/каналу Matrix і реакційні скорочення обробляють як схвалення exec, так і схвалення Plugin;
авторизація Plugin усе ще надходить із `channels.matrix.dm.allowFrom`
- нативні запити Matrix містять вміст користувацької події `com.openclaw.approval` у першій події
запиту, щоб клієнти Matrix, обізнані з OpenClaw, могли читати структурований стан схвалення, тоді як стандартні клієнти
зберігають резервний plain-text `/approve`
- запитувач не мусить бути схвалювачем
- початковий чат може схвалити напряму через `/approve`, коли цей чат уже підтримує команди й відповіді
- нативні кнопки схвалення Discord маршрутизують за різновидом id схвалення: id `plugin:` йдуть
прямо до схвалень Plugin, усе інше йде до схвалень exec
- нативні кнопки схвалення Telegram дотримуються того самого обмеженого резервного переходу від exec до Plugin, що й `/approve`
- коли нативний `target` вмикає доставку до початкового чату, запити на схвалення містять текст команди
- очікувані схвалення exec за замовчуванням спливають через 30 хвилин
- якщо жоден операторський UI або налаштований клієнт схвалень не може прийняти запит, запит переходить до `askFallback`
Telegram за замовчуванням надсилає в DM схвалювачів (`target: "dm"`). Ви можете перемкнути на `channel` або `both`, коли
Чутливі групові команди лише для власника, як-от `/diagnostics` і `/export-trajectory`, використовують приватну
маршрутизацію власника для запитів на схвалення та фінальних результатів. OpenClaw спочатку пробує приватний маршрут на тій самій
поверхні, де власник запустив команду. Якщо ця поверхня не має приватного маршруту власника, виконується
резервний перехід до першого доступного маршруту власника з `commands.ownerAllowFrom`, тому групова команда Discord
усе ще може надіслати схвалення й результат до DM власника в Telegram, коли Telegram є налаштованим
основним приватним інтерфейсом. Груповий чат отримує лише коротке підтвердження.
Telegram за замовчуванням використовує DM схвалювачів (`target: "dm"`). Ви можете перемкнути на `channel` або `both`, коли
хочете, щоб запити на схвалення також з’являлися в початковому чаті/темі Telegram. Для форумних
тем Telegram OpenClaw зберігає тему для запиту на схвалення та подальшого повідомлення після схвалення.
Див.:
Дивіться:
- [Discord](/channels/discord)
- [Telegram](/channels/telegram)
### Потік macOS IPC
### Потік IPC у macOS
__OC_I18N_900004__
Нотатки щодо безпеки:
Примітки щодо безпеки:
- Режим Unix-сокета `0600`, токен зберігається в `exec-approvals.json`.
- Перевірка peer з тим самим UID.
- Виклик/відповідь (nonce + HMAC-токен + хеш запиту) + короткий TTL.
- режим Unix-сокета `0600`, токен зберігається в `exec-approvals.json`.
- перевірка одно-UID peer.
- Challenge/response (nonce + HMAC token + request hash) + короткий TTL.
## Пов’язане
- [Схвалення виконання](/uk/tools/exec-approvals) — основна політика та потік схвалення
- [Інструмент виконання](/uk/tools/exec)
- [Розширений режим](/uk/tools/elevated)
- [Схвалення exec](/uk/tools/exec-approvals) — основна політика та потік схвалення
- [Інструмент exec](/uk/tools/exec)
- [Підвищений режим](/uk/tools/elevated)
- [Skills](/uk/tools/skills) — поведінка автоматичного дозволу на основі Skills