From 76c11b6ba048d763c6440c5ae28232d553ecb386 Mon Sep 17 00:00:00 2001 From: "openclaw-docs-i18n[bot]" Date: Wed, 29 Apr 2026 00:33:32 +0000 Subject: [PATCH] chore(i18n): refresh uk translations --- docs/uk/channels/discord.md | 528 ++++++++++++----------- docs/uk/tools/exec-approvals-advanced.md | 199 ++++----- 2 files changed, 368 insertions(+), 359 deletions(-) diff --git a/docs/uk/channels/discord.md b/docs/uk/channels/discord.md index 8f7729754..cccbbf0fd 100644 --- a/docs/uk/channels/discord.md +++ b/docs/uk/channels/discord.md @@ -1,24 +1,24 @@ --- read_when: - Робота над функціями каналу Discord -summary: Стан підтримки бота Discord, можливості та конфігурація +summary: Статус підтримки бота Discord, можливості та конфігурація title: Discord x-i18n: - generated_at: "2026-04-28T19:12:28Z" + generated_at: "2026-04-29T00:30:31Z" model: gpt-5.5 provider: openai - source_hash: b552ae25d1f1edac7499af1ebb0a04b213f546b95aa93cd2bb4e292ce793bc40 + source_hash: 2fc2d3b26704ffa0f8e388cde48952ad2e205b9cd09c4873666d25db3a9bd94b source_path: channels/discord.md workflow: 16 --- -Готово для приватних повідомлень і каналів гільдії через офіційний Discord Gateway. +Готово для особистих повідомлень і каналів серверів через офіційний Gateway Discord. - Приватні повідомлення Discord за замовчуванням переходять у режим сполучення. + Особисті повідомлення Discord за замовчуванням використовують режим сполучення. - + Нативна поведінка команд і каталог команд. @@ -28,37 +28,37 @@ x-i18n: ## Швидке налаштування -Вам потрібно створити нову програму з ботом, додати бота на свій сервер і сполучити його з OpenClaw. Рекомендуємо додати бота на власний приватний сервер. Якщо у вас його ще немає, [спочатку створіть сервер](https://support.discord.com/hc/en-us/articles/204849977-How-do-I-create-a-server) (виберіть **Create My Own > For me and my friends**). +Вам потрібно створити нову програму з ботом, додати бота на свій сервер і сполучити його з OpenClaw. Ми рекомендуємо додавати бота на власний приватний сервер. Якщо у вас його ще немає, [спочатку створіть його](https://support.discord.com/hc/en-us/articles/204849977-How-do-I-create-a-server) (виберіть **Create My Own > For me and my friends**). - - Перейдіть до [Discord Developer Portal](https://discord.com/developers/applications) і натисніть **New Application**. Назвіть її, наприклад, "OpenClaw". + + Перейдіть до [Discord Developer Portal](https://discord.com/developers/applications) і натисніть **New Application**. Назвіть її приблизно "OpenClaw". Натисніть **Bot** на бічній панелі. Установіть **Username** на ім’я, яким ви називаєте свого агента OpenClaw. - - На сторінці **Bot** прокрутіть униз до **Privileged Gateway Intents** і ввімкніть: + + Залишаючись на сторінці **Bot**, прокрутіть униз до **Privileged Gateway Intents** і ввімкніть: - **Message Content Intent** (обов’язково) - - **Server Members Intent** (рекомендовано; обов’язково для списків дозволених ролей і зіставлення імен з ID) + - **Server Members Intent** (рекомендовано; потрібно для списків дозволених ролей і зіставлення імен з ID) - **Presence Intent** (необов’язково; потрібно лише для оновлень присутності) - Прокрутіть назад угору на сторінці **Bot** і натисніть **Reset Token**. + Прокрутіть угору на сторінці **Bot** і натисніть **Reset Token**. - Попри назву, це генерує ваш перший токен — нічого не "скидається". + Попри назву, це створює ваш перший токен — нічого не "скидається." - Скопіюйте токен і збережіть його десь. Це ваш **Bot Token**, і він скоро знадобиться. + Скопіюйте токен і збережіть його. Це ваш **Bot Token**, і він знадобиться вам невдовзі. - + Натисніть **OAuth2** на бічній панелі. Ви згенеруєте URL запрошення з потрібними дозволами, щоб додати бота на свій сервер. Прокрутіть униз до **OAuth2 URL Generator** і ввімкніть: @@ -66,42 +66,42 @@ x-i18n: - `bot` - `applications.commands` - Нижче з’явиться розділ **Bot Permissions**. Увімкніть принаймні: + Нижче з’явиться розділ **Bot Permissions**. Увімкніть щонайменше: - **Загальні дозволи** - - Переглядати канали - **Текстові дозволи** - - Надсилати повідомлення - - Читати історію повідомлень - - Вбудовувати посилання - - Прикріплювати файли - - Додавати реакції (необов’язково) + **General Permissions** + - View Channels + **Text Permissions** + - Send Messages + - Read Message History + - Embed Links + - Attach Files + - Add Reactions (необов’язково) - Це базовий набір для звичайних текстових каналів. Якщо ви плануєте публікувати в тредах Discord, зокрема в робочих процесах форумних або медіаканалів, які створюють чи продовжують тред, також увімкніть **Send Messages in Threads**. - Скопіюйте згенерований URL унизу, вставте його в браузер, виберіть свій сервер і натисніть **Continue**, щоб підключити. Тепер ви маєте побачити свого бота на сервері Discord. + Це базовий набір для звичайних текстових каналів. Якщо ви плануєте публікувати в гілках Discord, зокрема у сценаріях форумних або медіаканалів, які створюють чи продовжують гілку, також увімкніть **Send Messages in Threads**. + Скопіюйте згенерований URL унизу, вставте його в браузер, виберіть свій сервер і натисніть **Continue**, щоб підключити. Тепер ви маєте бачити свого бота на сервері Discord. - - Повернувшись у програму Discord, потрібно ввімкнути Developer Mode, щоб копіювати внутрішні ID. + + У програмі Discord потрібно ввімкнути режим розробника, щоб копіювати внутрішні ID. - 1. Натисніть **User Settings** (іконка шестерні поруч із вашим аватаром) → **Advanced** → увімкніть **Developer Mode** - 2. Клацніть правою кнопкою миші **іконку сервера** на бічній панелі → **Copy Server ID** + 1. Натисніть **User Settings** (значок шестерні поруч із вашим аватаром) → **Advanced** → увімкніть **Developer Mode** + 2. Клацніть правою кнопкою миші **значок сервера** на бічній панелі → **Copy Server ID** 3. Клацніть правою кнопкою миші **власний аватар** → **Copy User ID** - Збережіть свої **Server ID** і **User ID** поруч із Bot Token — на наступному кроці ви надішлете всі три до OpenClaw. + Збережіть **Server ID** і **User ID** разом із Bot Token — на наступному кроці ви надішлете всі три до OpenClaw. - - Щоб сполучення працювало, Discord має дозволяти вашому боту надсилати вам приватні повідомлення. Клацніть правою кнопкою миші **іконку сервера** → **Privacy Settings** → увімкніть **Direct Messages**. + + Щоб сполучення працювало, Discord має дозволити вашому боту надсилати вам особисті повідомлення. Клацніть правою кнопкою миші **значок сервера** → **Privacy Settings** → увімкніть **Direct Messages**. - Це дозволяє учасникам сервера (зокрема ботам) надсилати вам приватні повідомлення. Залиште це ввімкненим, якщо хочете використовувати приватні повідомлення Discord з OpenClaw. Якщо ви плануєте використовувати лише канали гільдії, можете вимкнути приватні повідомлення після сполучення. + Це дає змогу учасникам сервера (включно з ботами) надсилати вам особисті повідомлення. Залиште це ввімкненим, якщо хочете використовувати особисті повідомлення Discord з OpenClaw. Якщо ви плануєте використовувати лише канали серверів, після сполучення особисті повідомлення можна вимкнути. - - Токен вашого бота Discord є секретом (як пароль). Установіть його на машині, де запущено OpenClaw, перш ніж писати своєму агенту. + + Токен бота Discord є секретом (як пароль). Задайте його на машині, де запущено OpenClaw, перш ніж писати агенту. ```bash export DISCORD_BOT_TOKEN="YOUR_BOT_TOKEN" @@ -111,21 +111,21 @@ openclaw config set channels.discord.enabled true --strict-json openclaw gateway ``` - Якщо OpenClaw уже працює як фоновий сервіс, перезапустіть його через програму OpenClaw для Mac або зупинивши й повторно запустивши процес `openclaw gateway run`. - Для керованих інсталяцій сервісу виконайте `openclaw gateway install` з оболонки, де присутній `DISCORD_BOT_TOKEN`, або збережіть змінну в `~/.openclaw/.env`, щоб сервіс міг розв’язати env SecretRef після перезапуску. + Якщо OpenClaw уже запущено як фонову службу, перезапустіть його через програму OpenClaw для Mac або зупинивши й знову запустивши процес `openclaw gateway run`. + Для інсталяцій керованої служби виконайте `openclaw gateway install` з оболонки, де наявний `DISCORD_BOT_TOKEN`, або збережіть змінну в `~/.openclaw/.env`, щоб служба могла розв’язати env SecretRef після перезапуску. - - Поспілкуйтеся зі своїм агентом OpenClaw у будь-якому наявному каналі (наприклад, Telegram) і повідомте йому. Якщо Discord — ваш перший канал, скористайтеся вкладкою CLI / конфігурація. + + Поспілкуйтеся зі своїм агентом OpenClaw у будь-якому наявному каналі (наприклад, Telegram) і повідомте йому. Якщо Discord — ваш перший канал, натомість використайте вкладку CLI / конфігурації. - > "Я вже встановив токен свого бота Discord у конфігурації. Заверши налаштування Discord з User ID `` і Server ID ``." + > "Я вже задав токен бота Discord у конфігурації. Завершіть налаштування Discord з User ID `` і Server ID ``." - Якщо ви віддаєте перевагу файловій конфігурації, установіть: + Якщо ви віддаєте перевагу файловій конфігурації, задайте: ```json5 { @@ -142,27 +142,27 @@ openclaw gateway } ``` - Резервний env-варіант для облікового запису за замовчуванням: + Резервне значення env для типового облікового запису: ```bash DISCORD_BOT_TOKEN=... ``` - Значення `token` у відкритому тексті підтримуються. Значення SecretRef також підтримуються для `channels.discord.token` через env/file/exec-провайдери. Див. [Керування секретами](/uk/gateway/secrets). + Підтримуються відкриті значення `token`. Значення SecretRef також підтримуються для `channels.discord.token` у провайдерах env/file/exec. Див. [Керування секретами](/uk/gateway/secrets). - - Дочекайтеся, доки Gateway запуститься, а потім надішліть приватне повідомлення своєму боту в Discord. Він відповість кодом сполучення. + + Зачекайте, доки Gateway запуститься, а потім надішліть своєму боту особисте повідомлення в Discord. Він відповість кодом сполучення. - + Надішліть код сполучення своєму агенту в наявному каналі: - > "Схвали цей код сполучення Discord: ``" + > "Підтвердьте цей код сполучення Discord: ``" @@ -176,28 +176,28 @@ openclaw pairing approve discord Коди сполучення спливають через 1 годину. - Тепер ви маєте змогу спілкуватися зі своїм агентом у Discord через приватні повідомлення. + Тепер ви маєте змогу спілкуватися зі своїм агентом у Discord через особисті повідомлення. -Розв’язання токена враховує обліковий запис. Значення токена з конфігурації мають пріоритет над резервним env-значенням. `DISCORD_BOT_TOKEN` використовується лише для облікового запису за замовчуванням. -Якщо два ввімкнені облікові записи Discord розв’язуються до одного й того самого токена бота, OpenClaw запускає лише один монітор Gateway для цього токена. Токен із конфігурації має пріоритет над резервним env-значенням за замовчуванням; інакше перемагає перший увімкнений обліковий запис, а дубльований обліковий запис повідомляється як вимкнений. -Для розширених вихідних викликів (дії інструмента message/каналу) явний `token` для кожного виклику використовується саме для цього виклику. Це стосується дій send і read/probe-стилю (наприклад read/search/fetch/thread/pins/permissions). Налаштування політики облікового запису та повторних спроб усе одно беруться з вибраного облікового запису в активному знімку runtime. +Розв’язання токена враховує обліковий запис. Значення токена в конфігурації мають пріоритет над резервним значенням env. `DISCORD_BOT_TOKEN` використовується лише для типового облікового запису. +Якщо два ввімкнені облікові записи Discord розв’язуються в той самий токен бота, OpenClaw запускає лише один монітор Gateway для цього токена. Токен із конфігурації має пріоритет над типовим резервним значенням env; в іншому разі перемагає перший увімкнений обліковий запис, а дубльований обліковий запис повідомляється як вимкнений. +Для розширених вихідних викликів (інструмент повідомлень/дії каналу) явний `token` для кожного виклику використовується саме для цього виклику. Це стосується дій надсилання та дій читання/перевірки (наприклад, read/search/fetch/thread/pins/permissions). Політика облікового запису та налаштування повторів усе ще беруться з вибраного облікового запису в активному знімку середовища виконання. -## Рекомендовано: налаштуйте робочий простір гільдії +## Рекомендовано: налаштуйте робочий простір сервера -Коли приватні повідомлення запрацюють, ви можете налаштувати свій сервер Discord як повноцінний робочий простір, де кожен канал отримує власну сесію агента з власним контекстом. Це рекомендовано для приватних серверів, де є лише ви й ваш бот. +Коли особисті повідомлення запрацюють, ви можете налаштувати свій сервер Discord як повноцінний робочий простір, де кожен канал отримує власну сесію агента зі своїм контекстом. Це рекомендовано для приватних серверів, де є лише ви та ваш бот. - - Це дає вашому агенту змогу відповідати в будь-якому каналі на вашому сервері, а не лише в приватних повідомленнях. + + Це дає змогу вашому агенту відповідати в будь-якому каналі на вашому сервері, а не лише в особистих повідомленнях. - - > "Додай мій Discord Server ID `` до списку дозволених гільдій" + + > "Додайте мій Discord Server ID `` до списку дозволених серверів" @@ -223,16 +223,16 @@ openclaw pairing approve discord - За замовчуванням ваш агент відповідає в каналах гільдії лише коли його згадують через @mention. Для приватного сервера ви, ймовірно, хочете, щоб він відповідав на кожне повідомлення. + За замовчуванням ваш агент відповідає в каналах сервера лише коли його згадано через @mention. Для приватного сервера ви, ймовірно, хочете, щоб він відповідав на кожне повідомлення. - У каналах гільдії звичайні фінальні відповіді асистента за замовчуванням залишаються приватними. Видимий вивід Discord потрібно надсилати явно за допомогою інструмента `message`, тож агент може за замовчуванням спостерігати й публікувати лише тоді, коли вирішить, що відповідь у каналі корисна. + У каналах сервера звичайні фінальні відповіді асистента за замовчуванням залишаються приватними. Видимий вивід Discord потрібно надсилати явно за допомогою інструмента `message`, тож агент може за замовчуванням залишатися непомітним і публікувати лише тоді, коли вирішить, що відповідь у каналі корисна. - - > "Дозволь моєму агенту відповідати на цьому сервері без потреби бути @mentioned" + + > "Дозвольте моєму агенту відповідати на цьому сервері без потреби бути згаданим через @mention" - Установіть `requireMention: false` у конфігурації гільдії: + Установіть `requireMention: false` у конфігурації свого сервера: ```json5 { @@ -255,65 +255,65 @@ openclaw pairing approve discord - - За замовчуванням довгострокова пам’ять (MEMORY.md) завантажується лише в сесіях приватних повідомлень. Канали гільдії не завантажують MEMORY.md автоматично. + + За замовчуванням довготривала пам’ять (MEMORY.md) завантажується лише в сесіях особистих повідомлень. Канали сервера не завантажують MEMORY.md автоматично. - - > "Коли я ставлю запитання в каналах Discord, використовуй memory_search або memory_get, якщо тобі потрібен довгостроковий контекст із MEMORY.md." + + > "Коли я ставлю запитання в каналах Discord, використовуйте memory_search або memory_get, якщо вам потрібен довготривалий контекст із MEMORY.md." - Якщо вам потрібен спільний контекст у кожному каналі, помістіть стабільні інструкції в `AGENTS.md` або `USER.md` (вони ін’єктуються для кожної сесії). Зберігайте довгострокові нотатки в `MEMORY.md` і звертайтеся до них на вимогу за допомогою інструментів пам’яті. + Якщо вам потрібен спільний контекст у кожному каналі, помістіть стабільні інструкції в `AGENTS.md` або `USER.md` (вони вставляються в кожну сесію). Зберігайте довготривалі нотатки в `MEMORY.md` і звертайтеся до них за потреби за допомогою інструментів пам’яті. -Тепер створіть кілька каналів на своєму сервері Discord і почніть спілкуватися. Ваш агент бачить назву каналу, і кожен канал отримує власну ізольовану сесію — тож ви можете налаштувати `#coding`, `#home`, `#research` або будь-що, що відповідає вашому робочому процесу. +Тепер створіть кілька каналів на своєму сервері Discord і починайте спілкуватися. Ваш агент бачить назву каналу, і кожен канал отримує власну ізольовану сесію — тож ви можете налаштувати `#coding`, `#home`, `#research` або будь-що, що пасує вашому робочому процесу. -## Модель runtime +## Модель середовища виконання - Gateway володіє підключенням Discord. -- Маршрутизація відповідей детермінована: вхідні відповіді Discord повертаються до Discord. -- Метадані гільдії/каналу Discord додаються до запиту моделі як недовірений - контекст, а не як видимий користувачу префікс відповіді. Якщо модель копіює цей конверт - назад, OpenClaw прибирає скопійовані метадані з вихідних відповідей і з - майбутнього контексту відтворення. +- Маршрутизація відповідей детермінована: вхідні відповіді Discord повертаються в Discord. +- Метадані сервера/каналу Discord додаються до промпта моделі як ненадійний + контекст, а не як видимий користувачу префікс відповіді. Якщо модель скопіює цей конверт + назад, OpenClaw вилучить скопійовані метадані з вихідних відповідей і з + майбутнього контексту повторного відтворення. - За замовчуванням (`session.dmScope=main`) прямі чати спільно використовують головну сесію агента (`agent:main:main`). -- Канали гільдії мають ізольовані ключі сесій (`agent::discord:channel:`). -- Групові приватні повідомлення за замовчуванням ігноруються (`channels.discord.dm.groupEnabled=false`). -- Нативні slash-команди виконуються в ізольованих командних сесіях (`agent::discord:slash:`), водночас усе ще передаючи `CommandTargetSessionKey` до маршрутизованої сесії розмови. -- Текстова доставка оголошень cron/Heartbeat до Discord використовує фінальну - видиму для асистента відповідь один раз. Медіа та payload-и структурованих компонентів залишаються - багатоповідомними, коли агент видає кілька payload-ів, придатних для доставки. +- Канали серверів ізольовані ключами сесій (`agent::discord:channel:`). +- Групові особисті повідомлення за замовчуванням ігноруються (`channels.discord.dm.groupEnabled=false`). +- Нативні слеш-команди виконуються в ізольованих командних сесіях (`agent::discord:slash:`), водночас усе ще передаючи `CommandTargetSessionKey` до маршрутизованої сесії розмови. +- Текстова доставка оголошень cron/heartbeat до Discord використовує фінальну + видиму асистенту відповідь один раз. Медіа та структуровані компонентні корисні навантаження залишаються + багатоповідомленнєвими, коли агент видає кілька придатних для доставки корисних навантажень. ## Форумні канали -Форумні та медіаканали Discord приймають лише публікації в тредах. OpenClaw підтримує два способи їх створення: +Форумні та медіаканали Discord приймають лише дописи в гілках. OpenClaw підтримує два способи їх створення: -- Надішліть повідомлення до батьківського форуму (`channel:`), щоб автоматично створити тред. Заголовок треду використовує перший непорожній рядок вашого повідомлення. -- Використайте `openclaw message thread create`, щоб створити тред напряму. Не передавайте `--message-id` для форумних каналів. +- Надішліть повідомлення до батьківського форуму (`channel:`), щоб автоматично створити гілку. Назва гілки використовує перший непорожній рядок вашого повідомлення. +- Використайте `openclaw message thread create`, щоб створити гілку напряму. Не передавайте `--message-id` для форумних каналів. -Приклад: надіслати до батьківського форуму, щоб створити тред +Приклад: надіслати до батьківського форуму, щоб створити гілку ```bash openclaw message send --channel discord --target channel: \ --message "Topic title\nBody of the post" ``` -Приклад: явно створити форумний тред +Приклад: явно створити форумну гілку ```bash openclaw message thread create --channel discord --target channel: \ --thread-name "Topic title" --message "Body of the post" ``` -Батьківські форуми не приймають компоненти Discord. Якщо вам потрібні компоненти, надсилайте до самого треду (`channel:`). +Батьківські форуми не приймають компоненти Discord. Якщо вам потрібні компоненти, надсилайте до самої гілки (`channel:`). ## Інтерактивні компоненти -OpenClaw підтримує контейнери компонентів Discord v2 для повідомлень агента. Використовуйте інструмент повідомлень із payload `components`. Результати взаємодії маршрутизуються назад до агента як звичайні вхідні повідомлення та дотримуються наявних налаштувань Discord `replyToMode`. +OpenClaw підтримує контейнери Discord components v2 для повідомлень агентів. Використовуйте інструмент повідомлень із корисним навантаженням `components`. Результати взаємодій маршрутизуються назад до агента як звичайні вхідні повідомлення та дотримуються наявних налаштувань Discord `replyToMode`. Підтримувані блоки: @@ -321,21 +321,21 @@ OpenClaw підтримує контейнери компонентів Discord - Рядки дій дозволяють до 5 кнопок або одне меню вибору - Типи вибору: `string`, `user`, `role`, `mentionable`, `channel` -За замовчуванням компоненти одноразові. Установіть `components.reusable=true`, щоб дозволити використовувати кнопки, вибори та форми багато разів, доки не завершиться строк їх дії. +За замовчуванням компоненти призначені для одноразового використання. Установіть `components.reusable=true`, щоб дозволити багаторазове використання кнопок, елементів вибору та форм до завершення строку їх дії. -Щоб обмежити, хто може натиснути кнопку, задайте `allowedUsers` для цієї кнопки (ID користувачів Discord, теги або `*`). Коли це налаштовано, користувачі, які не збігаються, отримують ефемерну відмову. +Щоб обмежити, хто може натиснути кнопку, задайте `allowedUsers` для цієї кнопки (ID користувачів Discord, теги або `*`). Якщо налаштовано, користувачі без збігу отримують ефемерну відмову. -Слеш-команди `/model` і `/models` відкривають інтерактивний вибірник моделі з випадаючими списками провайдера, моделі та сумісного середовища виконання, а також кроком Submit. `/models add` застаріла й тепер повертає повідомлення про застарілість замість реєстрації моделей із чату. Відповідь вибірника ефемерна, і користуватися нею може лише користувач, який її викликав. +Слеш-команди `/model` і `/models` відкривають інтерактивний вибір моделі з випадаючими списками провайдера, моделі та сумісного середовища виконання, а також кроком надсилання. `/models add` застаріла й тепер повертає повідомлення про застарілість замість реєстрації моделей із чату. Відповідь вибору є ефемерною, і користуватися нею може лише користувач, який її викликав. -Вкладені файли: +Вкладення файлів: -- блоки `file` мають вказувати на посилання на вкладення (`attachment://`) -- Передайте вкладення через `media`/`path`/`filePath` (один файл); використовуйте `media-gallery` для кількох файлів -- Використовуйте `filename`, щоб перевизначити назву завантаження, коли вона має збігатися з посиланням на вкладення +- Блоки `file` мають указувати на посилання вкладення (`attachment://`) +- Надайте вкладення через `media`/`path`/`filePath` (один файл); використовуйте `media-gallery` для кількох файлів +- Використовуйте `filename`, щоб перевизначити назву завантаження, коли вона має збігатися з посиланням вкладення Модальні форми: -- Додайте `components.modal` із максимум 5 полями +- Додайте `components.modal` із кількістю полів до 5 - Типи полів: `text`, `checkbox`, `radio`, `select`, `role-select`, `user-select` - OpenClaw автоматично додає кнопку запуску @@ -396,7 +396,7 @@ OpenClaw підтримує контейнери компонентів Discord ## Контроль доступу та маршрутизація - + `channels.discord.dmPolicy` керує доступом до DM (застаріле: `channels.discord.dm.policy`): - `pairing` (за замовчуванням) @@ -404,40 +404,40 @@ OpenClaw підтримує контейнери компонентів Discord - `open` (потребує, щоб `channels.discord.allowFrom` містив `"*"`; застаріле: `channels.discord.dm.allowFrom`) - `disabled` - Якщо політика DM не відкрита, невідомі користувачі блокуються (або отримують запит на спарювання в режимі `pairing`). + Якщо політика DM не відкрита, невідомі користувачі блокуються (або отримують запит на сполучення в режимі `pairing`). - Пріоритет для кількох акаунтів: + Пріоритет для кількох облікових записів: - - `channels.discord.accounts.default.allowFrom` застосовується лише до акаунта `default`. - - Іменовані акаунти успадковують `channels.discord.allowFrom`, коли їхній власний `allowFrom` не задано. - - Іменовані акаунти не успадковують `channels.discord.accounts.default.allowFrom`. + - `channels.discord.accounts.default.allowFrom` застосовується лише до облікового запису `default`. + - Іменовані облікові записи успадковують `channels.discord.allowFrom`, коли власний `allowFrom` не задано. + - Іменовані облікові записи не успадковують `channels.discord.accounts.default.allowFrom`. Формат цілі DM для доставки: - `user:` - згадка `<@id>` - Голі числові ID неоднозначні й відхиляються, якщо не надано явний тип цілі користувача/каналу. + Голі числові ID неоднозначні та відхиляються, якщо не надано явний тип цілі користувача/каналу. - - Обробкою guild керує `channels.discord.groupPolicy`: + + Обробкою гільдій керує `channels.discord.groupPolicy`: - `open` - `allowlist` - `disabled` - Безпечний базовий рівень, коли існує `channels.discord`, — `allowlist`. + Безпечна базова лінія, коли існує `channels.discord`, — це `allowlist`. Поведінка `allowlist`: - - guild має збігатися з `channels.discord.guilds` (переважно `id`, slug приймається) - - необов’язкові списки дозволених відправників: `users` (рекомендовано стабільні ID) і `roles` (лише ID ролей); якщо налаштовано будь-який із них, відправники дозволяються, коли збігаються з `users` АБО `roles` - - прямий збіг за іменем/тегом вимкнений за замовчуванням; увімкніть `channels.discord.dangerouslyAllowNameMatching: true` лише як режим аварійної сумісності + - гільдія має збігатися з `channels.discord.guilds` (бажано `id`, slug приймається) + - необов’язкові списки дозволених відправників: `users` (рекомендовано стабільні ID) і `roles` (лише ID ролей); якщо налаштовано будь-який із них, відправники дозволяються, коли вони збігаються з `users` АБО `roles` + - пряме зіставлення за іменем/тегом вимкнено за замовчуванням; увімкніть `channels.discord.dangerouslyAllowNameMatching: true` лише як аварійний режим сумісності - імена/теги підтримуються для `users`, але ID безпечніші; `openclaw security audit` попереджає, коли використовуються записи імен/тегів - - якщо для guild налаштовано `channels`, канали поза списком забороняються - - якщо guild не має блока `channels`, усі канали в цьому дозволеному guild дозволені + - якщо для гільдії налаштовано `channels`, канали, яких немає в списку, забороняються + - якщо в гільдії немає блока `channels`, дозволяються всі канали в цій гільдії зі списку дозволених Приклад: @@ -463,12 +463,12 @@ OpenClaw підтримує контейнери компонентів Discord } ``` - Якщо ви задаєте лише `DISCORD_BOT_TOKEN` і не створюєте блок `channels.discord`, резервне значення під час виконання — `groupPolicy="allowlist"` (із попередженням у журналах), навіть якщо `channels.defaults.groupPolicy` дорівнює `open`. + Якщо ви задаєте лише `DISCORD_BOT_TOKEN` і не створюєте блок `channels.discord`, резервне значення під час виконання — `groupPolicy="allowlist"` (із попередженням у журналах), навіть якщо `channels.defaults.groupPolicy` має значення `open`. - - Повідомлення guild за замовчуванням обмежуються згадками. + + Повідомлення гільдії за замовчуванням пропускаються лише за згадкою. Виявлення згадок охоплює: @@ -476,20 +476,20 @@ OpenClaw підтримує контейнери компонентів Discord - налаштовані шаблони згадок (`agents.list[].groupChat.mentionPatterns`, резервно `messages.groupChat.mentionPatterns`) - неявну поведінку відповіді боту в підтримуваних випадках - `requireMention` налаштовується для кожного guild/каналу (`channels.discord.guilds...`). - `ignoreOtherMentions` необов’язково відкидає повідомлення, які згадують іншого користувача/роль, але не бота (крім @everyone/@here). + `requireMention` налаштовується для кожної гільдії/каналу (`channels.discord.guilds...`). + `ignoreOtherMentions` необов’язково відкидає повідомлення, що згадують іншого користувача/роль, але не бота (за винятком @everyone/@here). Групові DM: - за замовчуванням: ігноруються (`dm.groupEnabled=false`) - - необов’язковий `allowlist` через `dm.groupChannels` (ID каналів або slug) + - необов’язковий список дозволених через `dm.groupChannels` (ID каналів або slugs) ### Маршрутизація агентів на основі ролей -Використовуйте `bindings[].match.roles`, щоб маршрутизувати учасників Discord guild до різних агентів за ID ролі. Прив’язки на основі ролей приймають лише ID ролей і оцінюються після прив’язок peer або parent-peer та перед прив’язками лише для guild. Якщо прив’язка також задає інші поля збігу (наприклад `peer` + `guildId` + `roles`), мають збігатися всі налаштовані поля. +Використовуйте `bindings[].match.roles`, щоб маршрутизувати учасників гільдії Discord до різних агентів за ID ролі. Прив’язки на основі ролей приймають лише ID ролей і оцінюються після прив’язок peer або parent-peer та перед прив’язками лише для гільдії. Якщо прив’язка також задає інші поля збігу (наприклад, `peer` + `guildId` + `roles`), усі налаштовані поля мають збігатися. ```json5 { @@ -515,22 +515,22 @@ OpenClaw підтримує контейнери компонентів Discord ## Нативні команди та авторизація команд -- `commands.native` за замовчуванням дорівнює `"auto"` і ввімкнено для Discord. +- `commands.native` за замовчуванням має значення `"auto"` і ввімкнено для Discord. - Перевизначення для окремого каналу: `channels.discord.commands.native`. - `commands.native=false` явно очищає раніше зареєстровані нативні команди Discord. - Авторизація нативних команд використовує ті самі списки дозволених і політики Discord, що й звичайна обробка повідомлень. -- Команди все ще можуть бути видимі в інтерфейсі Discord для користувачів, які не авторизовані; виконання все одно застосовує авторизацію OpenClaw і повертає "не авторизовано". +- Команди все ще можуть бути видимими в інтерфейсі Discord для користувачів без авторизації; виконання все одно застосовує авторизацію OpenClaw і повертає "not authorized". Див. [Слеш-команди](/uk/tools/slash-commands) для каталогу команд і поведінки. -Стандартні налаштування слеш-команд: +Налаштування слеш-команд за замовчуванням: - `ephemeral: true` -## Деталі функцій +## Подробиці функцій - + Discord підтримує теги відповіді у виводі агента: - `[[reply_to_current]]` @@ -543,21 +543,21 @@ OpenClaw підтримує контейнери компонентів Discord - `all` - `batched` - Примітка: `off` вимикає неявну потоковість відповідей. Явні теги `[[reply_to_*]]` усе ще враховуються. - `first` завжди додає неявне посилання нативної відповіді до першого вихідного повідомлення Discord за хід. - `batched` додає неявне посилання нативної відповіді Discord лише тоді, коли - вхідний хід був дебаунсованим пакетом із кількох повідомлень. Це корисно, - коли ви хочете нативні відповіді переважно для неоднозначних активних чатів, а не для кожного + Примітка: `off` вимикає неявне зв’язування відповідей у ланцюжки. Явні теги `[[reply_to_*]]` усе ще враховуються. + `first` завжди прикріплює неявне посилання нативної відповіді до першого вихідного повідомлення Discord за хід. + `batched` прикріплює неявне посилання нативної відповіді Discord лише тоді, коли + вхідний хід був дебаунс-пакетом із кількох повідомлень. Це корисно, + коли вам потрібні нативні відповіді переважно для неоднозначних швидких чатів, а не для кожного ходу з одним повідомленням. ID повідомлень передаються в контексті/історії, щоб агенти могли націлюватися на конкретні повідомлення. - - OpenClaw може транслювати чернетки відповідей, надсилаючи тимчасове повідомлення та редагуючи його в міру надходження тексту. `channels.discord.streaming` приймає `off` (за замовчуванням) | `partial` | `block` | `progress`. `progress` на Discord зіставляється з `partial`; `streamMode` — застарілий псевдонім, який мігрується автоматично. + + OpenClaw може транслювати чернетки відповідей, надсилаючи тимчасове повідомлення та редагуючи його в міру надходження тексту. `channels.discord.streaming` приймає `off` (за замовчуванням) | `partial` | `block` | `progress`. `progress` зіставляється з `partial` у Discord; `streamMode` є застарілим псевдонімом і автоматично мігрується. - За замовчуванням лишається `off`, бо редагування попереднього перегляду в Discord швидко впираються в ліміти частоти, коли кілька ботів або Gateway спільно використовують один акаунт. + За замовчуванням лишається `off`, оскільки редагування попереднього перегляду Discord швидко впираються в обмеження частоти, коли кілька ботів або gateways спільно використовують обліковий запис. ```json5 { @@ -575,47 +575,47 @@ OpenClaw підтримує контейнери компонентів Discord ``` - `partial` редагує одне повідомлення попереднього перегляду в міру надходження токенів. - - `block` видає фрагменти розміру чернетки (використовуйте `draftChunk`, щоб налаштувати розмір і точки розриву, обмежені `textChunkLimit`). + - `block` випускає фрагменти розміру чернетки (використовуйте `draftChunk`, щоб налаштувати розмір і точки розриву, обмежені `textChunkLimit`). - Медіа, помилки та фінальні повідомлення з явною відповіддю скасовують очікувані редагування попереднього перегляду. - `streaming.preview.toolProgress` (за замовчуванням `true`) керує тим, чи оновлення інструментів/прогресу повторно використовують повідомлення попереднього перегляду. - Трансляція попереднього перегляду підтримує лише текст; відповіді з медіа повертаються до звичайної доставки. Коли потокове передавання `block` явно ввімкнено, OpenClaw пропускає потік попереднього перегляду, щоб уникнути подвійного стримінгу. + Потоковий попередній перегляд підтримує лише текст; відповіді з медіа повертаються до звичайної доставки. Коли потокове передавання `block` явно ввімкнено, OpenClaw пропускає потік попереднього перегляду, щоб уникнути подвійної трансляції. - - Контекст історії guild: + + Контекст історії гільдії: - `channels.discord.historyLimit` за замовчуванням `20` - резервно: `messages.groupChat.historyLimit` - `0` вимикає - Елементи керування історією DM: + Керування історією DM: - `channels.discord.dmHistoryLimit` - `channels.discord.dms[""].historyLimit` - Поведінка thread: + Поведінка ланцюжків: - - Discord threads маршрутизуються як сеанси каналу й успадковують конфігурацію батьківського каналу, якщо її не перевизначено. - - Сеанси thread успадковують вибір `/model` на рівні сеансу батьківського каналу як резерв лише для моделі; локальні вибори `/model` у thread усе ще мають пріоритет, а історія транскрипту батьківського каналу не копіюється, якщо не ввімкнено успадкування транскрипту. - - `channels.discord.thread.inheritParent` (за замовчуванням `false`) вмикає для нових auto-threads початкове наповнення з батьківського транскрипту. Перевизначення для окремого акаунта містяться в `channels.discord.accounts..thread.inheritParent`. - - Реакції інструмента повідомлень можуть розпізнавати цілі DM `user:`. + - Ланцюжки Discord маршрутизуються як сеанси каналів і успадковують конфігурацію батьківського каналу, якщо її не перевизначено. + - Сеанси ланцюжків успадковують вибір `/model` рівня сеансу батьківського каналу як резерв лише для моделі; локальні для ланцюжка вибори `/model` усе ще мають пріоритет, а історія транскрипту батьківського каналу не копіюється, якщо успадкування транскрипту не ввімкнено. + - `channels.discord.thread.inheritParent` (за замовчуванням `false`) вмикає для нових автоматичних ланцюжків початкове заповнення з батьківського транскрипту. Перевизначення для окремого облікового запису розташовані в `channels.discord.accounts..thread.inheritParent`. + - Реакції інструмента повідомлень можуть визначати DM-цілі `user:`. - `guilds..channels..requireMention: false` зберігається під час резервної активації на етапі відповіді. - Теми каналів вставляються як **ненадійний** контекст. Списки дозволених визначають, хто може запускати агента, а не є повною межею редагування додаткового контексту. + Теми каналів впроваджуються як **ненадійний** контекст. Списки дозволених обмежують, хто може запускати агента, але не є повною межею редагування додаткового контексту. - - Discord може прив’язати thread до цілі сеансу, щоб наступні повідомлення в цьому thread і далі маршрутизувалися до того самого сеансу (зокрема сеансів subagent). + + Discord може прив’язати ланцюжок до цілі сеансу, щоб наступні повідомлення в цьому ланцюжку продовжували маршрутизуватися до того самого сеансу (включно із сеансами субагентів). Команди: - - `/focus ` прив’язати поточний/новий thread до цілі subagent/сеансу - - `/unfocus` видалити прив’язку поточного thread + - `/focus ` прив’язати поточний/новий ланцюжок до цілі субагента/сеансу + - `/unfocus` видалити прив’язку поточного ланцюжка - `/agents` показати активні запуски та стан прив’язки - - `/session idle ` переглянути/оновити авто-unfocus за неактивністю для сфокусованих прив’язок + - `/session idle ` переглянути/оновити автоматичне зняття фокуса через неактивність для сфокусованих прив’язок - `/session max-age ` переглянути/оновити жорсткий максимальний вік для сфокусованих прив’язок Конфігурація: @@ -646,16 +646,16 @@ OpenClaw підтримує контейнери компонентів Discord - `session.threadBindings.*` задає глобальні типові значення. - `channels.discord.threadBindings.*` перевизначає поведінку Discord. - - `spawnSubagentSessions` має бути `true`, щоб автоматично створювати/прив’язувати гілки для `sessions_spawn({ thread: true })`. - - `spawnAcpSessions` має бути `true`, щоб автоматично створювати/прив’язувати гілки для ACP (`/acp spawn ... --thread ...` або `sessions_spawn({ runtime: "acp", thread: true })`). + - `spawnSubagentSessions` має бути true, щоб автоматично створювати/прив’язувати гілки для `sessions_spawn({ thread: true })`. + - `spawnAcpSessions` має бути true, щоб автоматично створювати/прив’язувати гілки для ACP (`/acp spawn ... --thread ...` або `sessions_spawn({ runtime: "acp", thread: true })`). - Якщо прив’язки гілок вимкнені для облікового запису, `/focus` і пов’язані операції прив’язки гілок недоступні. Див. [Субагенти](/uk/tools/subagents), [Агенти ACP](/uk/tools/acp-agents) і [Довідник конфігурації](/uk/gateway/configuration-reference). - - Для стабільних «завжди ввімкнених» робочих просторів ACP налаштуйте типізовані прив’язки ACP верхнього рівня, націлені на розмови Discord. + + Для стабільних "always-on" робочих просторів ACP налаштуйте типізовані прив’язки ACP верхнього рівня, націлені на розмови Discord. Шлях конфігурації: @@ -711,15 +711,15 @@ OpenClaw підтримує контейнери компонентів Discord Примітки: - - `/acp spawn codex --bind here` прив’язує поточний канал або гілку на місці й зберігає майбутні повідомлення в тій самій сесії ACP. Повідомлення гілки успадковують прив’язку батьківського каналу. - - У прив’язаному каналі або гілці `/new` і `/reset` скидають ту саму сесію ACP на місці. Тимчасові прив’язки гілок можуть перевизначати визначення цілі, поки активні. + - `/acp spawn codex --bind here` прив’язує поточний канал або гілку на місці й зберігає майбутні повідомлення в тому самому сеансі ACP. Повідомлення гілки успадковують прив’язку батьківського каналу. + - У прив’язаному каналі або гілці `/new` і `/reset` скидають той самий сеанс ACP на місці. Тимчасові прив’язки гілок можуть перевизначати визначення цілі, поки активні. - `spawnAcpSessions` потрібен лише тоді, коли OpenClaw має створити/прив’язати дочірню гілку через `--thread auto|here`. - Див. [Агенти ACP](/uk/tools/acp-agents), щоб дізнатися подробиці поведінки прив’язок. + Див. [Агенти ACP](/uk/tools/acp-agents) для деталей поведінки прив’язок. - + Режим сповіщень про реакції для кожної гільдії: - `off` @@ -727,11 +727,11 @@ OpenClaw підтримує контейнери компонентів Discord - `all` - `allowlist` (використовує `guilds..users`) - Події реакцій перетворюються на системні події та додаються до маршрутизованої сесії Discord. + Події реакцій перетворюються на системні події та додаються до маршрутизованого сеансу Discord. - + `ackReaction` надсилає емодзі підтвердження, поки OpenClaw обробляє вхідне повідомлення. Порядок визначення: @@ -743,13 +743,13 @@ OpenClaw підтримує контейнери компонентів Discord Примітки: - - Discord приймає емодзі Unicode або назви власних емодзі. + - Discord приймає емодзі Unicode або назви користувацьких емодзі. - Використовуйте `""`, щоб вимкнути реакцію для каналу або облікового запису. - - Записи конфігурації, ініційовані каналом, увімкнені типово. + + Записи конфігурації, ініційовані каналом, увімкнені за замовчуванням. Це впливає на потоки `/config set|unset` (коли функції команд увімкнені). @@ -767,8 +767,8 @@ OpenClaw підтримує контейнери компонентів Discord - - Маршрутизуйте трафік Discord Gateway WebSocket і стартові REST-пошуки (ID застосунку + визначення списку дозволених) через HTTP(S)-проксі за допомогою `channels.discord.proxy`. + + Спрямовуйте WebSocket-трафік Gateway Discord і стартові REST-запити (ID застосунку + визначення allowlist) через HTTP(S)-проксі за допомогою `channels.discord.proxy`. ```json5 { @@ -798,8 +798,8 @@ OpenClaw підтримує контейнери компонентів Discord - - Увімкніть визначення PluralKit, щоб зіставляти проксійовані повідомлення з ідентичністю учасника системи: + + Увімкніть визначення PluralKit, щоб зіставляти проксовані повідомлення з ідентичністю учасника системи: ```json5 { @@ -816,14 +816,14 @@ OpenClaw підтримує контейнери компонентів Discord Примітки: - - списки дозволених можуть використовувати `pk:` - - відображувані імена учасників зіставляються за іменем/slug лише коли `channels.discord.dangerouslyAllowNameMatching: true` - - пошуки використовують початковий ID повідомлення й обмежені часовим вікном - - якщо пошук не вдається, проксійовані повідомлення вважаються повідомленнями бота й відкидаються, якщо не встановлено `allowBots=true` + - allowlist можуть використовувати `pk:` + - відображувані імена учасників зіставляються за ім’ям/slug лише коли `channels.discord.dangerouslyAllowNameMatching: true` + - пошуки використовують початковий ID повідомлення та обмежені часовим вікном + - якщо пошук не вдається, проксовані повідомлення вважаються повідомленнями бота й відкидаються, якщо `allowBots=true` не встановлено - + Оновлення присутності застосовуються, коли ви задаєте поле статусу або активності, або коли вмикаєте автоматичну присутність. Приклад лише зі статусом: @@ -865,7 +865,7 @@ OpenClaw підтримує контейнери компонентів Discord } ``` - Мапа типів активності: + Карта типів активності: - 0: Грає - 1: Транслює (потребує `activityUrl`) @@ -874,7 +874,7 @@ OpenClaw підтримує контейнери компонентів Discord - 4: Користувацька (використовує текст активності як стан статусу; емодзі необов’язковий) - 5: Змагається - Приклад автоматичної присутності (сигнал справності runtime): + Приклад автоматичної присутності (сигнал стану runtime): ```json5 { @@ -891,7 +891,7 @@ OpenClaw підтримує контейнери компонентів Discord } ``` - Автоматична присутність зіставляє доступність runtime зі статусом Discord: справний => онлайн, деградований або невідомий => неактивний, вичерпаний або недоступний => dnd. Необов’язкові перевизначення тексту: + Автоматична присутність зіставляє доступність runtime зі статусом Discord: healthy => online, degraded або unknown => idle, exhausted або unavailable => dnd. Необов’язкові перевизначення тексту: - `autoPresence.healthyText` - `autoPresence.degradedText` @@ -899,8 +899,8 @@ OpenClaw підтримує контейнери компонентів Discord - - Discord підтримує обробку схвалень на основі кнопок у DM і може додатково публікувати запити на схвалення у вихідному каналі. + + Discord підтримує обробку схвалень через кнопки в приватних повідомленнях і може додатково публікувати запити на схвалення у вихідному каналі. Шлях конфігурації: @@ -909,40 +909,42 @@ OpenClaw підтримує контейнери компонентів Discord - `channels.discord.execApprovals.target` (`dm` | `channel` | `both`, типово: `dm`) - `agentFilter`, `sessionFilter`, `cleanupAfterResolve` - Discord автоматично вмикає нативні exec-схвалення, коли `enabled` не задано або дорівнює `"auto"` і можна визначити принаймні одного схвалювача, або з `execApprovals.approvers`, або з `commands.ownerAllowFrom`. Discord не виводить exec-схвалювачів із канального `allowFrom`, застарілого `dm.allowFrom` або direct-message `defaultTo`. Установіть `enabled: false`, щоб явно вимкнути Discord як нативний клієнт схвалень. + Discord автоматично вмикає нативні схвалення виконання, коли `enabled` не задано або має значення `"auto"` і можна визначити принаймні одного схвалювача, або з `execApprovals.approvers`, або з `commands.ownerAllowFrom`. Discord не виводить схвалювачів виконання з `allowFrom` каналу, застарілого `dm.allowFrom` або `defaultTo` для прямих повідомлень. Установіть `enabled: false`, щоб явно вимкнути Discord як нативний клієнт схвалення. - Коли `target` дорівнює `channel` або `both`, запит на схвалення видимий у каналі. Лише визначені схвалювачі можуть користуватися кнопками; інші користувачі отримують ефемерну відмову. Запити на схвалення містять текст команди, тому вмикайте доставку в канал лише в довірених каналах. Якщо ID каналу не можна вивести з ключа сесії, OpenClaw повертається до доставки через DM. + Для чутливих групових команд лише для власника, як-от `/diagnostics` і `/export-trajectory`, OpenClaw надсилає запити на схвалення та фінальні результати приватно. Спершу він пробує Discord DM, коли власник, що викликає команду, має маршрут власника Discord; якщо він недоступний, використовується перший доступний маршрут власника з `commands.ownerAllowFrom`, наприклад Telegram. - Discord також відображає спільні кнопки схвалень, які використовують інші чат-канали. Нативний адаптер Discord переважно додає маршрутизацію DM для схвалювачів і розсилання в канали. + Коли `target` має значення `channel` або `both`, запит на схвалення видимий у каналі. Кнопками можуть користуватися лише визначені схвалювачі; інші користувачі отримують ефемерну відмову. Запити на схвалення містять текст команди, тому вмикайте доставку в канал лише в довірених каналах. Якщо ID каналу неможливо отримати з ключа сеансу, OpenClaw повертається до доставки через DM. + + Discord також відображає спільні кнопки схвалення, які використовують інші чат-канали. Нативний адаптер Discord переважно додає маршрутизацію DM для схвалювачів і розсилання в канали. Коли ці кнопки присутні, вони є основним UX схвалення; OpenClaw - має включати ручну команду `/approve` лише тоді, коли результат інструмента каже, - що чат-схвалення недоступні або ручне схвалення є єдиним шляхом. + має включати ручну команду `/approve` лише тоді, коли результат інструмента повідомляє, + що схвалення в чаті недоступні або ручне схвалення є єдиним шляхом. - Автентифікація Gateway і визначення схвалень дотримуються спільного контракту клієнта Gateway (ID `plugin:` визначаються через `plugin.approval.resolve`; інші ID — через `exec.approval.resolve`). Схвалення типово спливають через 30 хвилин. + Автентифікація Gateway і визначення схвалень дотримуються спільного контракту клієнта Gateway (`plugin:` IDs визначаються через `plugin.approval.resolve`; інші ID через `exec.approval.resolve`). За замовчуванням термін дії схвалень спливає через 30 хвилин. - Див. [Exec-схвалення](/uk/tools/exec-approvals). + Див. [Схвалення виконання](/uk/tools/exec-approvals). -## Інструменти й шлюзи дій +## Інструменти та шлюзи дій -Дії повідомлень Discord охоплюють надсилання повідомлень, адміністрування каналів, модерацію, присутність і дії з метаданими. +Дії повідомлень Discord охоплюють обмін повідомленнями, адміністрування каналів, модерацію, присутність і дії з метаданими. Основні приклади: -- повідомлення: `sendMessage`, `readMessages`, `editMessage`, `deleteMessage`, `threadReply` +- обмін повідомленнями: `sendMessage`, `readMessages`, `editMessage`, `deleteMessage`, `threadReply` - реакції: `react`, `reactions`, `emojiList` - модерація: `timeout`, `kick`, `ban` - присутність: `setPresence` -Дія `event-create` приймає необов’язковий параметр `image` (URL або шлях до локального файлу), щоб задати обкладинку запланованої події. +Дія `event-create` приймає необов’язковий параметр `image` (URL або локальний шлях до файлу), щоб задати обкладинку запланованої події. -Шлюзи дій розміщені в `channels.discord.actions.*`. +Шлюзи дій розташовані в `channels.discord.actions.*`. Типова поведінка шлюзів: -| Група дій | Типово | +| Група дій | Типово | | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | -------- | | reactions, messages, threads, pins, polls, search, memberInfo, roleInfo, channelInfo, channels, voiceStatus, events, stickers, emojiUploads, stickerUploads, permissions | увімкнено | | roles | вимкнено | @@ -951,11 +953,11 @@ OpenClaw підтримує контейнери компонентів Discord ## UI Components v2 -OpenClaw використовує Discord components v2 для exec-схвалень і міжконтекстних маркерів. Дії повідомлень Discord також можуть приймати `components` для користувацького UI (розширено; потребує побудови payload компонента через інструмент discord), тоді як застарілі `embeds` залишаються доступними, але не рекомендовані. +OpenClaw використовує компоненти Discord v2 для схвалень виконання та міжконтекстних маркерів. Дії повідомлень Discord також можуть приймати `components` для користувацького UI (розширений сценарій; потребує створення payload компонента через інструмент discord), тоді як застарілі `embeds` залишаються доступними, але не рекомендовані. - `channels.discord.ui.components.accentColor` задає акцентний колір, який використовують контейнери компонентів Discord (hex). -- Задавайте для кожного облікового запису через `channels.discord.accounts..ui.components.accentColor`. -- `embeds` ігноруються, коли присутні components v2. +- Задайте для облікового запису через `channels.discord.accounts..ui.components.accentColor`. +- `embeds` ігноруються, коли присутні компоненти v2. Приклад: @@ -982,13 +984,13 @@ Discord має дві окремі голосові поверхні: realtime * Контрольний список налаштування: 1. Увімкніть Message Content Intent у Discord Developer Portal. -2. Увімкніть Server Members Intent, коли використовуються списки дозволених ролей/користувачів. +2. Увімкніть Server Members Intent, коли використовуються allowlist ролей/користувачів. 3. Запросіть бота зі scopes `bot` і `applications.commands`. 4. Надайте Connect, Speak, Send Messages і Read Message History у цільовому голосовому каналі. 5. Увімкніть нативні команди (`commands.native` або `channels.discord.commands.native`). 6. Налаштуйте `channels.discord.voice`. -Використовуйте `/vc join|leave|status`, щоб керувати сесіями. Команда використовує типового агента облікового запису й дотримується тих самих правил списку дозволених і групової політики, що й інші команди Discord. +Використовуйте `/vc join|leave|status` для керування сеансами. Команда використовує типового агента облікового запису й дотримується тих самих правил allowlist і групової політики, що й інші команди Discord. ```bash /vc join channel: @@ -1026,33 +1028,33 @@ Discord має дві окремі голосові поверхні: realtime * Примітки: - `voice.tts` перевизначає `messages.tts` лише для голосового відтворення. -- `voice.model` перевизначає LLM, що використовується лише для відповідей у голосовому каналі Discord. Залиште не заданим, щоб успадкувати модель агента з маршрутизації. -- STT використовує `tools.media.audio`; `voice.model` не впливає на транскрипцію. -- Ходи голосового транскрипту визначають статус власника з Discord `allowFrom` (або `dm.allowFrom`); мовці, які не є власниками, не можуть отримати доступ до інструментів лише для власника (наприклад, `gateway` і `cron`). -- Голос увімкнено за замовчуванням; установіть `channels.discord.voice.enabled=false`, щоб вимкнути голосове середовище виконання та Gateway-інтент `GuildVoiceStates`. -- `channels.discord.intents.voiceStates` може явно перевизначити підписку на інтенти стану голосу. Залиште не заданим, щоб інтент відповідав `voice.enabled`. -- `voice.daveEncryption` і `voice.decryptionFailureTolerance` передаються в параметри підключення `@discordjs/voice`. -- Значення за замовчуванням `@discordjs/voice` — `daveEncryption=true` і `decryptionFailureTolerance=24`, якщо не задано. -- OpenClaw також відстежує збої розшифрування під час отримання й автоматично відновлюється, виходячи з голосового каналу та повторно приєднуючись до нього після повторних збоїв у короткому проміжку часу. -- Якщо після оновлення в журналах отримання повторно з’являється `DecryptionFailed(UnencryptedWhenPassthroughDisabled)`, зберіть звіт про залежності та журнали. Вбудована лінійка `@discordjs/voice` містить upstream-виправлення padding із discord.js PR #11449, яке закрило issue discord.js #11419. +- `voice.model` перевизначає LLM, що використовується лише для відповідей у голосовому каналі Discord. Залиште його незаданим, щоб успадкувати маршрутизовану модель агента. +- STT використовує `tools.media.audio`; `voice.model` не впливає на транскрибування. +- Ходи голосового транскрипту визначають статус власника з Discord `allowFrom` (або `dm.allowFrom`); мовці, які не є власниками, не можуть отримувати доступ до інструментів лише для власника (наприклад, `gateway` і `cron`). +- Голос увімкнено за замовчуванням; задайте `channels.discord.voice.enabled=false`, щоб вимкнути голосове середовище виконання та Gateway-намір `GuildVoiceStates`. +- `channels.discord.intents.voiceStates` може явно перевизначати підписку на намір стану голосу. Залиште незаданим, щоб намір відповідав `voice.enabled`. +- `voice.daveEncryption` і `voice.decryptionFailureTolerance` передаються в параметри приєднання `@discordjs/voice`. +- Значення за замовчуванням `@discordjs/voice`: `daveEncryption=true` і `decryptionFailureTolerance=24`, якщо їх не задано. +- OpenClaw також відстежує помилки розшифрування отриманих даних і автоматично відновлюється, виходячи з голосового каналу та повторно приєднуючись до нього після повторних помилок у короткому часовому вікні. +- Якщо після оновлення журнали отримання неодноразово показують `DecryptionFailed(UnencryptedWhenPassthroughDisabled)`, зберіть звіт про залежності та журнали. Вбудована лінія `@discordjs/voice` містить upstream-виправлення padding з PR discord.js #11449, який закрив issue discord.js #11419. Конвеєр голосового каналу: -- Захоплення PCM із Discord перетворюється на тимчасовий WAV-файл. +- Захоплення Discord PCM перетворюється на тимчасовий WAV-файл. - `tools.media.audio` обробляє STT, наприклад `openai/gpt-4o-mini-transcribe`. -- Транскрипт надсилається через звичайний вхід Discord і маршрутизацію. +- Транскрипт надсилається через звичайний вхідний потік і маршрутизацію Discord. - `voice.model`, якщо задано, перевизначає лише LLM відповіді для цього ходу голосового каналу. -- `voice.tts` об’єднується поверх `messages.tts`; отримане аудіо відтворюється в приєднаному каналі. +- `voice.tts` об’єднується поверх `messages.tts`; отримане аудіо відтворюється в каналі, до якого виконано приєднання. -Облікові дані визначаються для кожного компонента окремо: автентифікація маршруту LLM для `voice.model`, автентифікація STT для `tools.media.audio` і автентифікація TTS для `messages.tts`/`voice.tts`. +Облікові дані визначаються окремо для кожного компонента: автентифікація маршруту LLM для `voice.model`, автентифікація STT для `tools.media.audio` і автентифікація TTS для `messages.tts`/`voice.tts`. ### Голосові повідомлення -Голосові повідомлення Discord показують попередній перегляд хвилі та потребують аудіо OGG/Opus. OpenClaw генерує хвилю автоматично, але потребує `ffmpeg` і `ffprobe` на хості Gateway для аналізу та перетворення. +Голосові повідомлення Discord показують попередній перегляд форми хвилі та потребують аудіо OGG/Opus. OpenClaw генерує форму хвилі автоматично, але потребує `ffmpeg` і `ffprobe` на хості Gateway для інспектування та перетворення. -- Надайте **локальний шлях до файлу** (URL-адреси відхиляються). -- Не додавайте текстовий вміст (Discord відхиляє текст + голосове повідомлення в одному payload). -- Приймається будь-який аудіоформат; OpenClaw за потреби перетворює його на OGG/Opus. +- Надайте **локальний шлях до файлу** (URL відхиляються). +- Опустіть текстовий вміст (Discord відхиляє текст + голосове повідомлення в одному payload). +- Приймається будь-який аудіоформат; OpenClaw перетворює на OGG/Opus за потреби. ```bash message(action="send", channel="discord", target="channel:123", path="/path/to/audio.mp3", asVoice=true) @@ -1061,19 +1063,19 @@ message(action="send", channel="discord", target="channel:123", path="/path/to/a ## Усунення несправностей - + - увімкніть Message Content Intent - увімкніть Server Members Intent, коли ви залежите від визначення користувача/учасника - - перезапустіть Gateway після зміни інтентів + - перезапустіть Gateway після зміни намірів - + - перевірте `groupPolicy` - - перевірте allowlist гільдії в `channels.discord.guilds` - - якщо існує мапа `channels` для гільдії, дозволені лише перелічені канали + - перевірте список дозволених гільдій у `channels.discord.guilds` + - якщо існує мапа `channels` гільдії, дозволено лише перелічені канали - перевірте поведінку `requireMention` і шаблони згадок Корисні перевірки: @@ -1086,16 +1088,16 @@ openclaw logs --follow - + Поширені причини: - - `groupPolicy="allowlist"` без відповідного allowlist гільдії/каналу - - `requireMention` налаштовано не в тому місці (має бути в `channels.discord.guilds` або записі каналу) - - відправника заблоковано allowlist `users` гільдії/каналу + - `groupPolicy="allowlist"` без відповідного списку дозволених гільдій/каналів + - `requireMention` налаштовано в неправильному місці (має бути в `channels.discord.guilds` або записі каналу) + - відправника заблоковано списком дозволених `users` гільдії/каналу - + Типові журнали: @@ -1103,16 +1105,16 @@ openclaw logs --follow - `Slow listener detected ...` - `discord inbound worker timed out after ...` - Перемикач бюджету listener: + Регулятор бюджету слухача: - один обліковий запис: `channels.discord.eventQueue.listenerTimeout` - кілька облікових записів: `channels.discord.accounts..eventQueue.listenerTimeout` - Перемикач тайм-ауту виконання worker: + Регулятор часу очікування запуску worker: - один обліковий запис: `channels.discord.inboundWorker.runTimeoutMs` - кілька облікових записів: `channels.discord.accounts..inboundWorker.runTimeoutMs` - - за замовчуванням: `1800000` (30 хвилин); установіть `0`, щоб вимкнути + - за замовчуванням: `1800000` (30 хвилин); задайте `0`, щоб вимкнути Рекомендована базова конфігурація: @@ -1135,55 +1137,55 @@ openclaw logs --follow } ``` - Використовуйте `eventQueue.listenerTimeout` для повільного налаштування listener і `inboundWorker.runTimeoutMs` - лише якщо потрібен окремий запобіжний клапан для поставлених у чергу ходів агента. + Використовуйте `eventQueue.listenerTimeout` для повільного налаштування слухача, а `inboundWorker.runTimeoutMs` + лише якщо вам потрібен окремий запобіжник для поставлених у чергу ходів агента. - - OpenClaw отримує метадані Discord `/gateway/bot` перед підключенням. Тимчасові збої повертаються до стандартної Gateway URL-адреси Discord і обмежуються за частотою в журналах. + + OpenClaw отримує метадані Discord `/gateway/bot` перед підключенням. Тимчасові збої використовують стандартну URL-адресу Gateway Discord як резервну та обмежуються за частотою в журналах. - Перемикачі тайм-ауту метаданих: + Параметри тайм-ауту метаданих: - один обліковий запис: `channels.discord.gatewayInfoTimeoutMs` - кілька облікових записів: `channels.discord.accounts..gatewayInfoTimeoutMs` - - fallback через env, коли конфігурацію не задано: `OPENCLAW_DISCORD_GATEWAY_INFO_TIMEOUT_MS` - - за замовчуванням: `30000` (30 секунд), максимум: `120000` + - резервне значення env, коли конфігурацію не задано: `OPENCLAW_DISCORD_GATEWAY_INFO_TIMEOUT_MS` + - стандартне значення: `30000` (30 секунд), максимум: `120000` - - Перевірки дозволів `channels status --probe` працюють лише для числових ID каналів. + + Перевірки дозволів `channels status --probe` працюють лише для числових ідентифікаторів каналів. - Якщо ви використовуєте slug-ключі, зіставлення під час виконання все ще може працювати, але probe не може повністю перевірити дозволи. + Якщо ви використовуєте ключі-slug, зіставлення під час виконання все ще може працювати, але probe не може повністю перевірити дозволи. - + - DM вимкнено: `channels.discord.dm.enabled=false` - - політику DM вимкнено: `channels.discord.dmPolicy="disabled"` (legacy: `channels.discord.dm.policy`) + - політику DM вимкнено: `channels.discord.dmPolicy="disabled"` (застаріле: `channels.discord.dm.policy`) - очікується схвалення сполучення в режимі `pairing` - + За замовчуванням повідомлення, створені ботами, ігноруються. - Якщо ви встановлюєте `channels.discord.allowBots=true`, використовуйте строгі правила згадок і allowlist, щоб уникнути зациклення. + Якщо ви встановлюєте `channels.discord.allowBots=true`, використовуйте суворі правила згадок і списку дозволених, щоб уникнути циклічної поведінки. Надавайте перевагу `channels.discord.allowBots="mentions"`, щоб приймати лише повідомлення ботів, які згадують бота. - + - - підтримуйте OpenClaw актуальним (`openclaw update`), щоб логіка відновлення отримання голосу Discord була присутня - - підтвердьте `channels.discord.voice.daveEncryption=true` (за замовчуванням) - - почніть із `channels.discord.voice.decryptionFailureTolerance=24` (upstream-значення за замовчуванням) і налаштовуйте лише за потреби - - стежте в журналах за: + - підтримуйте OpenClaw актуальним (`openclaw update`), щоб була доступна логіка відновлення приймання голосу Discord + - підтвердьте `channels.discord.voice.daveEncryption=true` (стандартно) + - починайте з `channels.discord.voice.decryptionFailureTolerance=24` (стандартне значення upstream) і налаштовуйте лише за потреби + - стежте за журналами щодо: - `discord voice: DAVE decrypt failures detected` - `discord voice: repeated decrypt failures; attempting rejoin` - - якщо збої тривають після автоматичного повторного приєднання, зберіть журнали та порівняйте з upstream-історією отримання DAVE у [discord.js #11419](https://github.com/discordjs/discord.js/issues/11419) і [discord.js #11449](https://github.com/discordjs/discord.js/pull/11449) + - якщо збої тривають після автоматичного повторного приєднання, зберіть журнали та порівняйте з upstream-історією приймання DAVE у [discord.js #11419](https://github.com/discordjs/discord.js/issues/11419) і [discord.js #11449](https://github.com/discordjs/discord.js/pull/11449) @@ -1192,50 +1194,50 @@ openclaw logs --follow Основний довідник: [Довідник конфігурації - Discord](/uk/gateway/config-channels#discord). - + - запуск/автентифікація: `enabled`, `token`, `accounts.*`, `allowBots` - політика: `groupPolicy`, `dm.*`, `guilds.*`, `guilds.*.channels.*` - команда: `commands.native`, `commands.useAccessGroups`, `configWrites`, `slashCommand.*` -- черга подій: `eventQueue.listenerTimeout` (бюджет listener), `eventQueue.maxQueueSize`, `eventQueue.maxConcurrency` -- inbound worker: `inboundWorker.runTimeoutMs` +- черга подій: `eventQueue.listenerTimeout` (бюджет слухача), `eventQueue.maxQueueSize`, `eventQueue.maxConcurrency` +- вхідний worker: `inboundWorker.runTimeoutMs` - метадані Gateway: `gatewayInfoTimeoutMs` - відповідь/історія: `replyToMode`, `historyLimit`, `dmHistoryLimit`, `dms.*.historyLimit` -- доставка: `textChunkLimit`, `chunkMode`, `maxLinesPerMessage` -- streaming: `streaming` (legacy alias: `streamMode`), `streaming.preview.toolProgress`, `draftChunk`, `blockStreaming`, `blockStreamingCoalesce` -- медіа/повторна спроба: `mediaMaxMb` (обмежує вихідні завантаження Discord, за замовчуванням `100MB`), `retry` +- доставлення: `textChunkLimit`, `chunkMode`, `maxLinesPerMessage` +- потокове передавання: `streaming` (застарілий псевдонім: `streamMode`), `streaming.preview.toolProgress`, `draftChunk`, `blockStreaming`, `blockStreamingCoalesce` +- медіа/повторна спроба: `mediaMaxMb` (обмежує вихідні завантаження Discord, стандартно `100MB`), `retry` - дії: `actions.*` -- presence: `activity`, `status`, `activityType`, `activityUrl` +- присутність: `activity`, `status`, `activityType`, `activityUrl` - UI: `ui.components.accentColor` - функції: `threadBindings`, верхньорівневий `bindings[]` (`type: "acp"`), `pluralkit`, `execApprovals`, `intents`, `agentComponents`, `heartbeat`, `responsePrefix` -## Безпека та операції +## Безпека та експлуатація -- Вважайте токени ботів секретами (`DISCORD_BOT_TOKEN` бажано в керованих середовищах). +- Розглядайте токени ботів як секрети (`DISCORD_BOT_TOKEN` бажано в керованих середовищах). - Надавайте мінімально необхідні дозволи Discord. -- Якщо розгортання/стан команди застаріли, перезапустіть Gateway і повторно перевірте за допомогою `openclaw channels status --probe`. +- Якщо розгортання/стан команд застаріли, перезапустіть Gateway і повторно перевірте за допомогою `openclaw channels status --probe`. ## Пов’язане - + Сполучіть користувача Discord із Gateway. - - Груповий чат і поведінка allowlist. + + Поведінка групового чату та списку дозволених. - - Маршрутизуйте вхідні повідомлення до агентів. + + Спрямовуйте вхідні повідомлення до агентів. - - Модель загроз і посилення захисту. + + Модель загроз і зміцнення захисту. - + Зіставляйте гільдії та канали з агентами. - - Поведінка native-команд. + + Поведінка нативних команд. diff --git a/docs/uk/tools/exec-approvals-advanced.md b/docs/uk/tools/exec-approvals-advanced.md index f5b3272e4..c5563e5b7 100644 --- a/docs/uk/tools/exec-approvals-advanced.md +++ b/docs/uk/tools/exec-approvals-advanced.md @@ -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`), які можуть запускатися в режимі списку дозволених **без** явних записів у списку дозволених. Безпечні бінарні файли відхиляють позиційні аргументи файлів і токени, схожі на шляхи, тому вони можуть працювати лише з вхідним потоком. Розглядайте це як вузький швидкий шлях для потокових фільтрів, а не як загальний список довіри. -**Не** додавайте бінарні файли інтерпретаторів або середовищ виконання (наприклад `python3`, `node`, `ruby`, `bash`, `sh`, `zsh`) до `safeBins`. Якщо команда може оцінювати код, виконувати підкоманди або читати файли за своєю природою, віддавайте перевагу явним записам списку дозволених і залишайте запити схвалення ввімкненими. Користувацькі безпечні бінарні файли мають визначати явний профіль у `tools.exec.safeBinProfiles.`. +**Не** додавайте інтерпретатори або бінарні файли середовищ виконання (наприклад `python3`, `node`, `ruby`, `bash`, `sh`, `zsh`) до `safeBins`. Якщо команда може виконувати код, запускати підкоманди або читати файли за задумом, віддавайте перевагу явним записам у списку дозволених і залишайте запити на схвалення ввімкненими. Користувацькі безпечні бінарні файли мають визначати явний профіль у `tools.exec.safeBinProfiles.`. -Стандартні безпечні бінарні файли: +Безпечні бінарні файли за замовчуванням: [//]: # "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..allowlist` (або через Control UI / `openclaw approvals allowlist ...`). -- `openclaw security audit` попереджає через `tools.exec.safe_bins_interpreter_unprofiled`, коли бінарні файли інтерпретатора/середовища виконання з’являються в `safeBins` без явних профілів. -- `openclaw doctor --fix` може згенерувати відсутні користувацькі записи `safeBinProfiles.` як `{}` (перегляньте й посильте після цього). Бінарні файли інтерпретатора/середовища виконання не генеруються автоматично. +- `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..allowlist` (або через Control UI / `openclaw approvals allowlist ...`). +- `openclaw security audit` попереджає з `tools.exec.safe_bins_interpreter_unprofiled`, коли інтерпретатор/бінарні файли середовища виконання з’являються в `safeBins` без явних профілів. +- `openclaw doctor --fix` може створити відсутні користувацькі записи `safeBinProfiles.` як `{}` (після цього перегляньте й посильте їх). Інтерпретатор/бінарні файли середовища виконання не створюються автоматично. Приклад користувацького профілю: __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..execApprovals` керує тим, чи цей канал діє як нативний клієнт схвалення +- політика host exec надалі вирішує, чи потрібне схвалення exec +- `approvals.exec` керує пересиланням запитів на схвалення до інших чат-призначень +- `channels..execApprovals` керує тим, чи цей канал діє як нативний клієнт схвалень -Нативні клієнти схвалення автоматично вмикають доставку спершу в DM, коли істинні всі ці умови: +Нативні клієнти схвалень автоматично вмикають доставку спочатку в DM, коли виконуються всі ці умови: - канал підтримує нативну доставку схвалень - схвалювачів можна визначити з явних `execApprovals.approvers` або ідентичності власника, як-от `commands.ownerAllowFrom` -- `channels..execApprovals.enabled` не встановлено або має значення `"auto"` +- `channels..execApprovals.enabled` не задано або має значення `"auto"` -Установіть `enabled: false`, щоб явно вимкнути нативний клієнт схвалення. Установіть `enabled: true`, щоб примусово -ввімкнути його, коли схвалювачів визначено. Доставка в публічний початковий чат залишається явною через +Задайте `enabled: false`, щоб явно вимкнути нативний клієнт схвалень. Задайте `enabled: true`, щоб примусово +ввімкнути його, коли схвалювачів визначено. Публічна доставка до початкового чату лишається явною через `channels..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