chore(i18n): refresh uk translations

docs/uk/tools/exec-approvals.md

@@ -1,66 +1,71 @@
 ---
 read_when:
-    - Налаштування підтверджень exec або списків дозволів
-    - Реалізація UX підтвердження exec у застосунку macOS
-    - Перегляд запитів на вихід із sandbox і пов’язаних наслідків
-summary: Підтвердження exec, списки дозволів і запити на вихід із sandbox
-title: Підтвердження exec
+    - Налаштування підтверджень виконання або списків дозволених дій
+    - Реалізація UX підтвердження виконання в застосунку для macOS
+    - Перегляд запитів на вихід із пісочниці та їхніх наслідків
+summary: Запити на підтвердження виконання, списки дозволених дій і запити на вихід із пісочниці
+title: Підтвердження виконання
 x-i18n:
-    generated_at: "2026-04-07T18:43:49Z"
+    generated_at: "2026-04-10T06:17:33Z"
     model: gpt-5.4
     provider: openai
-    source_hash: 6041929185bab051ad873cc4822288cb7d6f0470e19e7ae7a16b70f76dfc2cd9
+    source_hash: 5f4a2e2f1f3c13a1d1926c9de0720513ea8a74d1ca571dbe74b188d8c560c14c
     source_path: tools/exec-approvals.md
     workflow: 15
 ---
 
-# Підтвердження exec
+# Підтвердження виконання
 
-Підтвердження exec — це **захисний механізм застосунку-компаньйона / хоста вузла** для дозволу sandbox-агенту запускати
-команди на реальному хості (`gateway` або `node`). Сприймайте це як запобіжне блокування:
-команди дозволяються лише тоді, коли політика + список дозволів + (необов’язкове) підтвердження користувача всі погоджуються.
-Підтвердження exec діють **додатково** до політики інструментів і elevated gating (якщо тільки elevated не встановлено в `full`, що пропускає підтвердження).
-Ефективна політика — це **суворіша** з `tools.exec.*` і типових значень підтверджень; якщо поле підтверджень пропущене, використовується значення `tools.exec`.
-Host exec також використовує локальний стан підтверджень на цій машині. Локальне для хоста
-`ask: "always"` у `~/.openclaw/exec-approvals.json` продовжує запитувати навіть якщо
-типові значення сесії або конфігурації вимагають `ask: "on-miss"`.
+Підтвердження виконання — це **захисний механізм companion app / хоста вузла** для того, щоб дозволити агенту в пісочниці запускати
+команди на реальному хості (`gateway` або `node`). Думайте про це як про захисне блокування:
+команди дозволяються лише тоді, коли політика + список дозволених дій + (необов’язкове) підтвердження користувача збігаються.
+Підтвердження виконання діють **додатково** до політики інструментів і шлюзу підвищених прав (якщо тільки для elevated не встановлено `full`, що пропускає підтвердження).
+Ефективна політика — це **суворіша** з `tools.exec.*` і типових налаштувань підтверджень; якщо поле підтверджень пропущене, використовується значення `tools.exec`.
+Виконання на хості також використовує локальний стан підтверджень на цій машині. Локальне для хоста
+`ask: "always"` у `~/.openclaw/exec-approvals.json` і далі показуватиме запити, навіть якщо
+сеанс або типові налаштування конфігурації вимагають `ask: "on-miss"`.
 Використовуйте `openclaw approvals get`, `openclaw approvals get --gateway` або
 `openclaw approvals get --node <id|name|ip>`, щоб переглянути запитану політику,
 джерела політики хоста та ефективний результат.
+Для локальної машини `openclaw exec-policy show` показує той самий об’єднаний вигляд, а
+`openclaw exec-policy set|preset` може синхронізувати запитану локальну політику з
+локальним файлом підтверджень хоста за один крок. Коли локальна область видимості запитує `host=node`,
+`openclaw exec-policy show` під час виконання повідомляє про цю область як таку, що керується вузлом, замість того
+щоб удавати, ніби локальний файл підтверджень є ефективним джерелом істини.
 
-Якщо UI застосунку-компаньйона **недоступний**, будь-який запит, що потребує підтвердження,
+Якщо UI companion app **недоступний**, будь-який запит, що потребує підтвердження,
 обробляється через **резервну поведінку ask** (типово: deny).
 
-Власні клієнти підтвердження в чаті також можуть надавати специфічні для каналу елементи інтерфейсу в повідомленні
-про очікуване підтвердження. Наприклад, Matrix може додавати швидкі реакції до
-запиту на підтвердження (`✅` дозволити один раз, `❌` відхилити та `♾️` завжди дозволяти, коли доступно),
-водночас залишаючи команди `/approve ...` у повідомленні як резервний варіант.
+Власні клієнти підтвердження в чаті також можуть показувати специфічні для каналу елементи керування в
+повідомленні про очікуване підтвердження. Наприклад, Matrix може додавати швидкі реакції до
+запиту на підтвердження (`✅` дозволити один раз, `❌` заборонити та `♾️` дозволити завжди, якщо доступно),
+при цьому залишаючи команди `/approve ...` у повідомленні як резервний варіант.
 
 ## Де це застосовується
 
-Підтвердження exec застосовуються локально на хості виконання:
+Підтвердження виконання примусово застосовуються локально на хості виконання:
 
-- **gateway host** → процес `openclaw` на машині gateway
-- **node host** → раннер вузла (застосунок-компаньйон macOS або headless node host)
+- **хост gateway** → процес `openclaw` на машині gateway
+- **хост node** → runner вузла (companion app для macOS або headless-хост вузла)
 
 Примітка щодо моделі довіри:
 
-- Викликачі, автентифіковані gateway, є довіреними операторами для цього Gateway.
+- Виклики, автентифіковані через Gateway, вважаються довіреними операторами для цього Gateway.
 - Спарені вузли розширюють цю можливість довіреного оператора на хост вузла.
-- Підтвердження exec зменшують ризик випадкового виконання, але не є межею автентифікації на рівні користувача.
-- Схвалені запуски на хості вузла прив’язують канонічний контекст виконання: канонічний cwd, точний argv, прив’язку env
-  за наявності та зафіксований шлях до виконуваного файла, де це застосовно.
-- Для shell-скриптів і прямих викликів файлів інтерпретатора/середовища виконання OpenClaw також намагається прив’язати
-  один конкретний локальний файловий операнд. Якщо цей прив’язаний файл змінюється після підтвердження, але до виконання,
-  запуск відхиляється замість виконання зміненого вмісту.
-- Ця прив’язка файлів навмисно є best-effort, а не повною семантичною моделлю для кожного шляху
-  завантажувача інтерпретатора/середовища виконання. Якщо режим підтвердження не може точно визначити один конкретний локальний
-  файл для прив’язки, він відмовляється створювати запуск із підтвердженням, а не вдає повне покриття.
+- Підтвердження виконання зменшують ризик випадкового виконання, але не є межею автентифікації на рівні користувача.
+- Підтверджені запуски на хості вузла прив’язують канонічний контекст виконання: канонічний cwd, точний argv, прив’язку env,
+  коли вона присутня, і зафіксований шлях до виконуваного файла, коли це застосовно.
+- Для shell-скриптів і прямого виклику файлів через інтерпретатор/середовище виконання OpenClaw також намагається прив’язати
+  один конкретний локальний файловий операнд. Якщо цей прив’язаний файл зміниться після підтвердження, але до виконання,
+  запуск буде заборонено замість виконання зміненого вмісту.
+- Ця прив’язка файла навмисно є механізмом best-effort, а не повною семантичною моделлю для кожного
+  шляху завантаження інтерпретатора/середовища виконання. Якщо режим підтвердження не може визначити рівно один конкретний локальний
+  файл для прив’язки, він відмовляється створювати запуск на основі підтвердження, а не удає повне покриття.
 
 Поділ у macOS:
 
-- **служба хоста вузла** пересилає `system.run` до **застосунку macOS** через локальний IPC.
-- **застосунок macOS** застосовує підтвердження + виконує команду в контексті UI.
+- **сервіс хоста вузла** пересилає `system.run` до **застосунку macOS** через локальний IPC.
+- **застосунок macOS** примусово застосовує підтвердження + виконує команду в контексті UI.
 
 ## Налаштування та зберігання
 
@@ -103,30 +108,30 @@ Host exec також використовує локальний стан під
 }
 ```
 
-## Режим "YOLO" без підтверджень
+## Режим "YOLO" без підтвердження
 
-Якщо ви хочете, щоб host exec запускався без запитів на підтвердження, потрібно відкрити **обидва** шари політики:
+Якщо ви хочете, щоб виконання на хості працювало без запитів на підтвердження, потрібно відкрити **обидва** рівні політики:
 
-- запитану політику exec у конфігурації OpenClaw (`tools.exec.*`)
-- локальну для хоста політику підтверджень у `~/.openclaw/exec-approvals.json`
+- запитана політика виконання в конфігурації OpenClaw (`tools.exec.*`)
+- локальна політика підтверджень хоста в `~/.openclaw/exec-approvals.json`
 
-Тепер це типова поведінка хоста, якщо ви явно не зробите її суворішою:
+Тепер це типова поведінка хоста, якщо ви явно її не зробите суворішою:
 
 - `tools.exec.security`: `full` на `gateway`/`node`
 - `tools.exec.ask`: `off`
-- host `askFallback`: `full`
+- хост `askFallback`: `full`
 
 Важливе розрізнення:
 
-- `tools.exec.host=auto` вибирає, де виконується exec: у sandbox, коли доступно, інакше на gateway.
-- YOLO вибирає, як схвалюється host exec: `security=full` плюс `ask=off`.
-- У режимі YOLO OpenClaw не додає окремий евристичний бар’єр підтвердження обфускації команд поверх налаштованої політики host exec.
-- `auto` не робить маршрутизацію через gateway вільним обходом із sandbox-сесії. Запит `host=node` на рівні окремого виклику дозволений із `auto`, а `host=gateway` дозволяється з `auto` лише тоді, коли немає активного runtime sandbox. Якщо вам потрібен стабільний типово не-`auto` режим, задайте `tools.exec.host` або використовуйте `/exec host=...` явно.
+- `tools.exec.host=auto` вибирає, де виконується exec: у пісочниці, якщо вона доступна, інакше на gateway.
+- YOLO вибирає, як підтверджується виконання на хості: `security=full` плюс `ask=off`.
+- У режимі YOLO OpenClaw не додає окремий евристичний шлюз підтвердження для обфускації команд поверх налаштованої політики виконання на хості.
+- `auto` не робить маршрутизацію через gateway безкоштовним способом обходу із сеансу в пісочниці. Запит `host=node` на рівні окремого виклику дозволений із `auto`, а `host=gateway` дозволений із `auto` лише тоді, коли активне середовище виконання в пісочниці відсутнє. Якщо вам потрібне стабільне нетипове значення замість auto, установіть `tools.exec.host` або явно використовуйте `/exec host=...`.
 
-Якщо вам потрібне більш консервативне налаштування, знову зробіть суворішим будь-який із шарів до `allowlist` / `on-miss`
+Якщо вам потрібніше більш консервативне налаштування, зробіть суворішим будь-який із рівнів назад до `allowlist` / `on-miss`
 або `deny`.
 
-Постійне налаштування gateway host "ніколи не запитувати":
+Постійне налаштування "ніколи не запитувати" для хоста gateway:
 
 ```bash
 openclaw config set tools.exec.host gateway
@@ -135,7 +140,7 @@ openclaw config set tools.exec.ask off
 openclaw gateway restart
 ```
 
-Потім приведіть файл підтверджень хоста у відповідність:
+Потім установіть відповідний файл підтверджень хоста:
 
 ```bash
 openclaw approvals set --stdin <<'EOF'
@@ -150,7 +155,22 @@ openclaw approvals set --stdin <<'EOF'
 EOF
 ```
 
-Для хоста вузла замість цього застосуйте той самий файл підтверджень на цьому вузлі:
+Локальний ярлик для тієї самої політики хоста gateway на поточній машині:
+
+```bash
+openclaw exec-policy preset yolo
+```
+
+Цей локальний ярлик оновлює обидва:
+
+- локальні `tools.exec.host/security/ask`
+- локальні типові значення `~/.openclaw/exec-approvals.json`
+
+Він навмисно працює лише локально. Якщо вам потрібно змінити підтвердження для хоста gateway або хоста вузла
+віддалено, і далі використовуйте `openclaw approvals set --gateway` або
+`openclaw approvals set --node <id|name|ip>`.
+
+Для хоста вузла застосуйте той самий файл підтверджень на цьому вузлі:
 
 ```bash
 openclaw approvals set --node <id|name|ip> --stdin <<'EOF'
@@ -165,39 +185,45 @@ openclaw approvals set --node <id|name|ip> --stdin <<'EOF'
 EOF
 ```
 
-Ярлик лише для сесії:
+Важливе локальне обмеження:
 
-- `/exec security=full ask=off` змінює лише поточну сесію.
-- `/elevated full` — це аварійний shortcut, який також пропускає підтвердження exec для цієї сесії.
+- `openclaw exec-policy` не синхронізує підтвердження вузла
+- `openclaw exec-policy set --host node` відхиляється
+- підтвердження виконання вузла отримуються з вузла під час виконання, тож оновлення, націлені на вузол, потрібно робити через `openclaw approvals --node ...`
 
-Якщо файл підтверджень хоста залишається суворішим за конфігурацію, усе одно перемагає суворіша політика хоста.
+Ярлик лише для сеансу:
+
+- `/exec security=full ask=off` змінює лише поточний сеанс.
+- `/elevated full` — це аварійний ярлик, який також пропускає підтвердження виконання для цього сеансу.
+
+Якщо файл підтверджень хоста залишається суворішим, ніж конфігурація, суворіша політика хоста все одно має пріоритет.
 
 ## Параметри політики
 
 ### Security (`exec.security`)
 
-- **deny**: блокувати всі запити host exec.
-- **allowlist**: дозволяти лише команди зі списку дозволів.
-- **full**: дозволяти все (еквівалентно elevated).
+- **deny**: блокувати всі запити на виконання на хості.
+- **allowlist**: дозволяти лише команди зі списку дозволених дій.
+- **full**: дозволяти все (еквівалент elevated).
 
 ### Ask (`exec.ask`)
 
-- **off**: ніколи не запитувати.
-- **on-miss**: запитувати лише коли список дозволів не збігається.
-- **always**: запитувати для кожної команди.
-- довіреність `allow-always` не пригнічує запити, коли ефективний режим ask — `always`
+- **off**: ніколи не показувати запит.
+- **on-miss**: показувати запит лише тоді, коли список дозволених дій не збігається.
+- **always**: показувати запит для кожної команди.
+- тривала довіра `allow-always` не пригнічує запити, коли ефективний режим ask — `always`
 
 ### Ask fallback (`askFallback`)
 
-Якщо потрібне підтвердження, але жоден UI недосяжний, резервна поведінка вирішує:
+Якщо потрібен запит, але UI недосяжний, резервна поведінка визначає результат:
 
 - **deny**: блокувати.
-- **allowlist**: дозволяти лише якщо є збіг зі списком дозволів.
+- **allowlist**: дозволяти лише за збігу зі списком дозволених дій.
 - **full**: дозволяти.
 
-### Посилення для inline eval інтерпретатора (`tools.exec.strictInlineEval`)
+### Посилення inline eval інтерпретаторів (`tools.exec.strictInlineEval`)
 
-Коли `tools.exec.strictInlineEval=true`, OpenClaw розглядає inline-форми виконання коду лише як такі, що потребують підтвердження, навіть якщо сам бінарний файл інтерпретатора є в списку дозволів.
+Коли `tools.exec.strictInlineEval=true`, OpenClaw розглядає форми inline eval коду як такі, що потребують лише підтвердження, навіть якщо сам двійковий файл інтерпретатора є у списку дозволених.
 
 Приклади:
 
@@ -209,18 +235,18 @@ EOF
 - `lua -e`
 - `osascript -e`
 
-Це defense-in-depth для завантажувачів інтерпретаторів, які не можна чисто відобразити на один стабільний файловий операнд. У strict mode:
+Це захист у глибину для завантажувачів інтерпретаторів, які не відображаються чисто на один стабільний файловий операнд. У суворому режимі:
 
 - ці команди все одно потребують явного підтвердження;
-- `allow-always` не зберігає для них нові записи списку дозволів автоматично.
+- `allow-always` не зберігає для них нові записи списку дозволених автоматично.
 
-## Список дозволів (для кожного агента)
+## Список дозволених дій (для кожного агента)
 
-Списки дозволів є **окремими для кожного агента**. Якщо існує кілька агентів, перемкніть, якого агента ви
-редагуєте, у застосунку macOS. Шаблони — це **нечутливі до регістру glob-збіги**.
-Шаблони мають вказувати на **шляхи до бінарних файлів** (записи лише з basename ігноруються).
-Застарілі записи `agents.default` мігрують до `agents.main` під час завантаження.
-Shell-ланцюжки на кшталт `echo ok && pwd` усе одно вимагають, щоб кожен верхньорівневий сегмент відповідав правилам списку дозволів.
+Списки дозволених дій — **окремі для кожного агента**. Якщо існує кілька агентів, перемкніть агента,
+якого редагуєте, у застосунку macOS. Шаблони — це **нечутливі до регістру glob-збіги**.
+Шаблони мають вказувати на **шляхи до двійкових файлів** (записи лише з базовою назвою ігноруються).
+Застарілі записи `agents.default` під час завантаження мігрують до `agents.main`.
+Ланцюжки shell-команд на кшталт `echo ok && pwd` усе одно вимагають, щоб кожен сегмент верхнього рівня відповідав правилам списку дозволених дій.
 
 Приклади:
 
@@ -228,45 +254,45 @@ Shell-ланцюжки на кшталт `echo ok && pwd` усе одно вим
 - `~/.local/bin/*`
 - `/opt/homebrew/bin/rg`
 
-Кожен запис списку дозволів відстежує:
+Кожен запис списку дозволених дій відстежує:
 
-- **id** стабільний UUID, який використовується для ідентичності в UI (необов’язково)
-- **last used** мітка часу
+- **id** стабільний UUID, що використовується для ідентичності в UI (необов’язково)
+- **last used** часову мітку
 - **last used command**
 - **last resolved path**
 
 ## Автодозвіл для CLI Skills
 
-Коли **Auto-allow skill CLIs** увімкнено, виконувані файли, на які посилаються відомі Skills,
-вважаються такими, що входять до списку дозволів на вузлах (macOS node або headless node host). Для цього
-використовується `skills.bins` через Gateway RPC, щоб отримати список бінарних файлів skill. Вимкніть це, якщо вам потрібні суворі ручні списки дозволів.
+Коли ввімкнено **Автодозвіл для CLI Skills**, виконувані файли, на які посилаються відомі Skills,
+вважаються такими, що є у списку дозволених дій на вузлах (вузол macOS або headless-хост вузла). Для цього використовується
+`skills.bins` через Gateway RPC, щоб отримати список двійкових файлів Skills. Вимкніть це, якщо вам потрібні суворі ручні списки дозволених дій.
 
 Важливі примітки щодо довіри:
 
-- Це **неявний зручний список дозволів**, окремий від ручних записів списку дозволів для шляхів.
-- Він призначений для середовищ із довіреними операторами, де Gateway і вузол перебувають в одній межі довіри.
-- Якщо вам потрібна сувора явна довіра, залиште `autoAllowSkills: false` і використовуйте лише ручні записи списку дозволів для шляхів.
+- Це **неявний зручний список дозволених дій**, окремий від ручних записів списку дозволених шляхів.
+- Він призначений для довірених операторських середовищ, де Gateway і вузол перебувають у межах однієї моделі довіри.
+- Якщо вам потрібна сувора явна довіра, залиште `autoAllowSkills: false` і використовуйте лише ручні записи списку дозволених шляхів.
 
 ## Safe bins (лише stdin)
 
-`tools.exec.safeBins` визначає невеликий список **бінарних файлів лише для stdin** (наприклад, `cut`),
-які можуть запускатися в режимі списку дозволів **без** явних записів у списку дозволів. Safe bins відхиляють
-позиційні файлові аргументи та токени, схожі на шляхи, тому можуть працювати лише з вхідним потоком.
-Розглядайте це як вузький fast-path для потокових фільтрів, а не як загальний список довіри.
-**Не** додавайте до `safeBins` бінарні файли інтерпретаторів або середовищ виконання (наприклад, `python3`, `node`, `ruby`, `bash`, `sh`, `zsh`).
-Якщо команда за задумом може обчислювати код, виконувати підкоманди або читати файли, краще використовувати явні записи списку дозволів і залишати ввімкненими запити на підтвердження.
+`tools.exec.safeBins` визначає невеликий список **двійкових файлів лише для stdin** (наприклад, `cut`),
+які можуть працювати в режимі allowlist **без** явних записів у списку дозволених дій. Safe bins відхиляють
+позиційні файлові аргументи та токени, схожі на шляхи, тож вони можуть працювати лише з вхідним потоком.
+Сприймайте це як вузький швидкий шлях для потокових фільтрів, а не як загальний список довіри.
+**Не** додавайте двійкові файли інтерпретаторів або середовищ виконання (наприклад, `python3`, `node`, `ruby`, `bash`, `sh`, `zsh`) до `safeBins`.
+Якщо команда за своєю природою може виконувати eval коду, запускати підкоманди або читати файли, надавайте перевагу явним записам у списку дозволених дій і залишайте запити на підтвердження ввімкненими.
 Користувацькі safe bins мають визначати явний профіль у `tools.exec.safeBinProfiles.<bin>`.
 Перевірка є детермінованою лише за формою argv (без перевірок існування у файловій системі хоста), що
-запобігає поведінці оракула існування файлів через різницю між allow/deny.
-Файлоорієнтовані параметри відхиляються для типових safe bins (наприклад, `sort -o`, `sort --output`,
+запобігає поведінці oracle щодо існування файлів через відмінності allow/deny.
+Опції, орієнтовані на файли, заборонені для типових safe bins (наприклад, `sort -o`, `sort --output`,
 `sort --files0-from`, `sort --compress-program`, `sort --random-source`,
 `sort --temporary-directory`/`-T`, `wc --files0-from`, `jq -f/--from-file`,
 `grep -f/--file`).
-Safe bins також застосовують явну політику для прапорців кожного бінарного файла окремо щодо параметрів, які порушують поведінку
-лише для stdin (наприклад, `sort -o/--output/--compress-program` і рекурсивні прапорці grep).
-Довгі параметри перевіряються в режимі safe-bin fail-closed: невідомі прапорці й неоднозначні
+Safe bins також примусово застосовують явну політику прапорців для кожного двійкового файла для опцій, які порушують
+поведінку лише через stdin (наприклад, `sort -o/--output/--compress-program` і рекурсивні прапорці grep).
+Довгі опції в режимі safe-bin перевіряються за fail-closed принципом: невідомі прапорці та неоднозначні
 скорочення відхиляються.
-Відхилені прапорці за профілем safe-bin:
+Заборонені прапорці за профілем safe-bin:
 
 [//]: # "SAFE_BIN_DENIED_FLAGS:START"
 
@@ -278,31 +304,31 @@ Safe bins також застосовують явну політику для
 [//]: # "SAFE_BIN_DENIED_FLAGS:END"
 
 Safe bins також примусово обробляють токени argv як **буквальний текст** під час виконання (без globbing
-і без розгортання `$VARS`) для сегментів лише зі stdin, тому шаблони на кшталт `*` або `$HOME/...` не можуть бути
-використані для прихованого читання файлів.
-Safe bins також мають визначатися з довірених каталогів бінарних файлів (системні типові плюс необов’язкові
-`tools.exec.safeBinTrustedDirs`). Записи `PATH` ніколи не вважаються автоматично довіреними.
+і без розгортання `$VARS`) для сегментів лише зі stdin, тож шаблони на кшталт `*` або `$HOME/...` не можуть
+використовуватися для прихованого читання файлів.
+Safe bins також мають визначатися з довірених каталогів двійкових файлів (системні типові каталоги плюс необов’язкові
+`tools.exec.safeBinTrustedDirs`). Записи `PATH` ніколи не вважаються довіреними автоматично.
 Типові довірені каталоги safe-bin навмисно мінімальні: `/bin`, `/usr/bin`.
-Якщо ваш виконуваний файл safe-bin знаходиться в шляхах пакетного менеджера/користувача (наприклад
+Якщо ваш виконуваний файл safe-bin розташований у шляхах package manager або користувача (наприклад,
 `/opt/homebrew/bin`, `/usr/local/bin`, `/opt/local/bin`, `/snap/bin`), додайте їх явно
 до `tools.exec.safeBinTrustedDirs`.
-Shell-ланцюжки та перенаправлення не дозволяються автоматично в режимі списку дозволів.
+Ланцюжки shell-команд і перенаправлення не дозволяються автоматично в режимі allowlist.
 
-Shell-ланцюжки (`&&`, `||`, `;`) дозволяються, коли кожен верхньорівневий сегмент відповідає списку дозволів
-(включно із safe bins або автодозволом для skill). Перенаправлення залишаються непідтримуваними в режимі списку дозволів.
-Підстановка команд (`$()` / зворотні лапки) відхиляється під час розбору списку дозволів, зокрема всередині
+Ланцюжки shell-команд (`&&`, `||`, `;`) дозволені, якщо кожен сегмент верхнього рівня відповідає списку дозволених дій
+(включно з safe bins або автодозволом для Skills). Перенаправлення в режимі allowlist, як і раніше, не підтримуються.
+Підстановка команд (`$()` / зворотні лапки) відхиляється під час розбору allowlist, зокрема всередині
 подвійних лапок; використовуйте одинарні лапки, якщо вам потрібен буквальний текст `$()`.
-У підтвердженнях застосунку-компаньйона macOS сирий shell-текст, що містить синтаксис керування shell або розгортання
-(`&&`, `||`, `;`, `|`, `` ` ``, `$`, `<`, `>`, `(`, `)`), розглядається як промах списку дозволів, якщо
-сам бінарний файл shell не входить до списку дозволів.
-Для shell-обгорток (`bash|sh|zsh ... -c/-lc`) перевизначення env у межах запиту зводяться до
-невеликого явного списку дозволів (`TERM`, `LANG`, `LC_*`, `COLORTERM`, `NO_COLOR`, `FORCE_COLOR`).
-Для рішень allow-always у режимі списку дозволів відомі dispatch-обгортки
+У підтвердженнях companion app для macOS сирий текст shell, що містить керівні або розгортувальні конструкції shell
+(`&&`, `||`, `;`, `|`, `` ` ``, `$`, `<`, `>`, `(`, `)`), розглядається як незбіг зі списком дозволених дій, якщо
+сам двійковий файл shell не є у списку дозволених.
+Для обгорток shell (`bash|sh|zsh ... -c/-lc`) перевизначення env у межах запиту зводяться до
+невеликого явного списку дозволених значень (`TERM`, `LANG`, `LC_*`, `COLORTERM`, `NO_COLOR`, `FORCE_COLOR`).
+Для рішень allow-always у режимі allowlist відомі обгортки диспетчеризації
 (`env`, `nice`, `nohup`, `stdbuf`, `timeout`) зберігають внутрішні шляхи до виконуваних файлів, а не шляхи
 до самих обгорток. Shell-мультиплексори (`busybox`, `toybox`) також розгортаються для shell-аплетів (`sh`, `ash`,
-тощо), щоб зберігалися внутрішні виконувані файли, а не бінарні файли мультиплексора. Якщо обгортку або
-мультиплексор неможливо безпечно розгорнути, запис списку дозволів не зберігається автоматично.
-Якщо ви вносите до списку дозволів інтерпретатори на кшталт `python3` або `node`, віддавайте перевагу `tools.exec.strictInlineEval=true`, щоб inline eval усе одно вимагав явного підтвердження. У strict mode `allow-always` усе ще може зберігати нешкідливі виклики інтерпретатора/скрипта, але носії inline-eval автоматично не зберігаються.
+тощо), тож зберігаються внутрішні виконувані файли, а не двійкові файли мультиплексора. Якщо обгортку або
+мультиплексор не можна безпечно розгорнути, запис списку дозволених дій автоматично не зберігається.
+Якщо ви додаєте інтерпретатори, як-от `python3` або `node`, до списку дозволених, надавайте перевагу `tools.exec.strictInlineEval=true`, щоб inline eval і далі вимагав явного підтвердження. У суворому режимі `allow-always` усе ще може зберігати нешкідливі виклики інтерпретатора/скрипта, але носії inline-eval автоматично не зберігаються.
 
 Типові safe bins:
 
@@ -312,64 +338,64 @@ Shell-ланцюжки (`&&`, `||`, `;`) дозволяються, коли ко
 
 [//]: # "SAFE_BIN_DEFAULTS:END"
 
-`grep` і `sort` не входять до типового списку. Якщо ви явно вмикаєте їх, зберігайте явні записи списку дозволів для
-їхніх сценаріїв, не пов’язаних лише зі stdin.
+`grep` і `sort` не входять до типового списку. Якщо ви явно їх увімкнете, зберігайте явні записи списку дозволених дій для
+їхніх сценаріїв, що не обмежуються stdin.
 Для `grep` у режимі safe-bin передавайте шаблон через `-e`/`--regexp`; позиційна форма шаблону
-відхиляється, щоб файлові операнди не могли бути приховано передані як неоднозначні позиційні аргументи.
+відхиляється, щоб файлові операнди не можна було приховати як неоднозначні позиційні аргументи.
 
-### Safe bins проти списку дозволів
+### Safe bins у порівнянні зі списком дозволених дій
 
-| Тема             | `tools.exec.safeBins`                                  | Список дозволів (`exec-approvals.json`)                      |
+| Тема             | `tools.exec.safeBins`                                  | Список дозволених дій (`exec-approvals.json`)                |
 | ---------------- | ------------------------------------------------------ | ------------------------------------------------------------ |
-| Мета             | Автоматично дозволяти вузькі stdin-фільтри             | Явно довіряти конкретним виконуваним файлам                  |
+| Мета             | Автодозвіл для вузьких stdin-фільтрів                  | Явна довіра до конкретних виконуваних файлів                 |
 | Тип збігу        | Назва виконуваного файла + політика argv safe-bin      | Glob-шаблон шляху до визначеного виконуваного файла          |
-| Обсяг аргументів | Обмежений профілем safe-bin і правилами буквальних токенів | Лише збіг шляху; за аргументи в іншому ви відповідаєте самі |
+| Область аргументів | Обмежена профілем safe-bin і правилами буквальних токенів | Лише збіг шляху; відповідальність за аргументи інакше на вас |
 | Типові приклади  | `head`, `tail`, `tr`, `wc`                             | `jq`, `python3`, `node`, `ffmpeg`, користувацькі CLI         |
-| Найкраще використання | Текстові перетворення з низьким ризиком у конвеєрах | Будь-який інструмент із ширшою поведінкою або побічними ефектами |
+| Найкраще застосування | Низькоризикові текстові перетворення в конвеєрах      | Будь-який інструмент із ширшою поведінкою або побічними ефектами |
 
 Розташування конфігурації:
 
-- `safeBins` надходить із конфігурації (`tools.exec.safeBins` або для окремого агента `agents.list[].tools.exec.safeBins`).
-- `safeBinTrustedDirs` надходить із конфігурації (`tools.exec.safeBinTrustedDirs` або для окремого агента `agents.list[].tools.exec.safeBinTrustedDirs`).
-- `safeBinProfiles` надходить із конфігурації (`tools.exec.safeBinProfiles` або для окремого агента `agents.list[].tools.exec.safeBinProfiles`). Ключі профілів окремого агента мають пріоритет над глобальними ключами.
-- записи списку дозволів зберігаються в локальному для хоста `~/.openclaw/exec-approvals.json` у `agents.<id>.allowlist` (або через Control UI / `openclaw approvals allowlist ...`).
-- `openclaw security audit` попереджає через `tools.exec.safe_bins_interpreter_unprofiled`, коли бінарні файли інтерпретаторів/середовищ виконання з’являються в `safeBins` без явних профілів.
-- `openclaw doctor --fix` може створити відсутні записи `safeBinProfiles.<bin>` як `{}` (після цього перегляньте й посильте їх). Бінарні файли інтерпретаторів/середовищ виконання не створюються автоматично.
+- `safeBins` надходить із конфігурації (`tools.exec.safeBins` або `agents.list[].tools.exec.safeBins` для окремого агента).
+- `safeBinTrustedDirs` надходить із конфігурації (`tools.exec.safeBinTrustedDirs` або `agents.list[].tools.exec.safeBinTrustedDirs` для окремого агента).
+- `safeBinProfiles` надходить із конфігурації (`tools.exec.safeBinProfiles` або `agents.list[].tools.exec.safeBinProfiles` для окремого агента). Ключі профілю для окремого агента мають пріоритет над глобальними ключами.
+- записи allowlist зберігаються в локальному для хоста `~/.openclaw/exec-approvals.json` у `agents.<id>.allowlist` (або через Control UI / `openclaw approvals allowlist ...`).
+- `openclaw security audit` показує попередження `tools.exec.safe_bins_interpreter_unprofiled`, коли двійкові файли інтерпретаторів/середовищ виконання з’являються в `safeBins` без явних профілів.
+- `openclaw doctor --fix` може створити заготовки відсутніх записів `safeBinProfiles.<bin>` як `{}` (після цього перегляньте й посильте їх). Для двійкових файлів інтерпретаторів/середовищ виконання заготовки автоматично не створюються.
 
 Приклад користувацького профілю:
-__OC_I18N_900004__
-Якщо ви явно додаєте `jq` до `safeBins`, OpenClaw усе одно відхиляє builtin `env` у режимі safe-bin,
-тому `jq -n env` не може вивести env процесу хоста без явного шляху у списку дозволів
+__OC_I18N_900005__
+Якщо ви явно додаєте `jq` до `safeBins`, OpenClaw усе одно відхиляє вбудовану команду `env` у режимі safe-bin,
+щоб `jq -n env` не міг вивантажити середовище процесу хоста без явного шляху allowlist
 або запиту на підтвердження.
 
 ## Редагування в Control UI
 
-Використовуйте картку **Control UI → Nodes → Exec approvals**, щоб редагувати типові значення, перевизначення
-для окремих агентів і списки дозволів. Виберіть область дії (Defaults або агент), налаштуйте політику,
-додайте/видаліть шаблони списку дозволів, а потім натисніть **Save**. UI показує метадані **last used**
-для кожного шаблону, щоб вам було легше підтримувати порядок у списку.
+Використовуйте картку **Control UI → Nodes → Exec approvals**, щоб редагувати типові налаштування, перевизначення
+для окремих агентів і списки дозволених дій. Виберіть область видимості (Defaults або агент), змініть політику,
+додайте/видаліть шаблони списку дозволених дій, а потім натисніть **Save**. UI показує метадані **last used**
+для кожного шаблону, щоб вам було легше підтримувати список у впорядкованому стані.
 
 Селектор цілі вибирає **Gateway** (локальні підтвердження) або **Node**. Вузли
-мають оголошувати `system.execApprovals.get/set` (застосунок macOS або headless node host).
-Якщо вузол ще не оголошує exec approvals, відредагуйте його локальний
+мають оголошувати `system.execApprovals.get/set` (застосунок macOS або headless-хост вузла).
+Якщо вузол ще не оголошує підтвердження виконання, відредагуйте його локальний
 `~/.openclaw/exec-approvals.json` безпосередньо.
 
-CLI: `openclaw approvals` підтримує редагування gateway або node (див. [Approvals CLI](/cli/approvals)).
+CLI: `openclaw approvals` підтримує редагування gateway або вузла (див. [CLI підтверджень](/cli/approvals)).
 
 ## Потік підтвердження
 
-Коли потрібне підтвердження, gateway транслює `exec.approval.requested` клієнтам операторів.
-Control UI та застосунок macOS обробляють це через `exec.approval.resolve`, після чого gateway пересилає
-схвалений запит на хост вузла.
+Коли потрібен запит на підтвердження, gateway транслює `exec.approval.requested` клієнтам операторів.
+Control UI і застосунок macOS обробляють його через `exec.approval.resolve`, після чого gateway пересилає
+підтверджений запит хосту вузла.
 
-Для `host=node` запити на підтвердження містять канонічний payload `systemRunPlan`. Gateway використовує
-цей план як авторитетний контекст команди/cwd/сесії під час пересилання схвалених запитів `system.run`.
+Для `host=node` запити на підтвердження містять канонічне корисне навантаження `systemRunPlan`. Gateway використовує
+цей план як авторитетний контекст команди/cwd/сеансу під час пересилання підтверджених запитів `system.run`.
 
-Це важливо для затримки асинхронного підтвердження:
+Це важливо для асинхронної затримки підтвердження:
 
-- шлях exec вузла готує один канонічний план наперед
+- шлях виконання вузла готує один канонічний план наперед
 - запис підтвердження зберігає цей план і його метадані прив’язки
-- після схвалення фінальний пересланий виклик `system.run` повторно використовує збережений план
+- після підтвердження остаточний пересланий виклик `system.run` повторно використовує збережений план
   замість довіри до пізніших змін викликача
 - якщо викликач змінює `command`, `rawCommand`, `cwd`, `agentId` або
   `sessionKey` після створення запиту на підтвердження, gateway відхиляє
@@ -377,32 +403,32 @@ Control UI та застосунок macOS обробляють це через
 
 ## Команди інтерпретатора/середовища виконання
 
-Запуски інтерпретатора/середовища виконання з підтвердженням навмисно є консервативними:
+Запуски інтерпретатора/середовища виконання на основі підтвердження навмисно є консервативними:
 
 - Точний контекст argv/cwd/env завжди прив’язується.
-- Форми прямого shell-скрипта і прямого runtime-файла best-effort прив’язуються до одного конкретного snapshot локального
-  файла.
-- Поширені форми обгорток пакетних менеджерів, які все ще зводяться до одного прямого локального файла (наприклад
+- Форми прямого shell-скрипта і прямого файла середовища виконання прив’язуються в режимі best-effort до одного конкретного локального
+  знімка файла.
+- Поширені форми обгорток package manager, які все ще визначаються в один прямий локальний файл (наприклад,
   `pnpm exec`, `pnpm node`, `npm exec`, `npx`), розгортаються перед прив’язкою.
 - Якщо OpenClaw не може визначити рівно один конкретний локальний файл для команди інтерпретатора/середовища виконання
-  (наприклад package scripts, eval-форми, ланцюжки завантажувачів, специфічні для runtime, або неоднозначні форми
-  з кількома файлами), виконання з підтвердженням відхиляється замість заяв про семантичне покриття, якого
+  (наприклад, package scripts, форми eval, специфічні для середовища виконання ланцюжки завантажувачів або неоднозначні форми
+  з кількома файлами), виконання на основі підтвердження забороняється замість того, щоб стверджувати семантичне покриття, якого
   насправді немає.
-- Для таких сценаріїв віддавайте перевагу sandboxing, окремій межі хоста або явному довіреному
-  workflow зі списком дозволів/full, де оператор приймає ширшу семантику runtime.
+- Для таких робочих процесів надавайте перевагу пісочниці, окремій межі хоста або явному
+  довіреному процесу allowlist/full, де оператор приймає ширшу семантику середовища виконання.
 
-Коли потрібні підтвердження, інструмент exec негайно повертає id підтвердження. Використовуйте цей id, щоб
-співвідносити подальші системні події (`Exec finished` / `Exec denied`). Якщо жодне рішення не надходить до
-закінчення часу очікування, запит вважається тайм-аутом підтвердження й відображається як причина відмови.
+Коли потрібні підтвердження, інструмент exec одразу повертає id підтвердження. Використовуйте цей id, щоб
+пов’язати подальші системні події (`Exec finished` / `Exec denied`). Якщо жодне рішення не надійде до завершення
+часу очікування, запит вважається таким, що перевищив час очікування підтвердження, і показується як причина відмови.
 
-### Поведінка доставки followup
+### Поведінка доставлення followup
 
-Після завершення схваленого асинхронного exec OpenClaw надсилає followup-turn `agent` у ту саму сесію.
+Після завершення підтвердженого асинхронного exec OpenClaw надсилає followup-хід `agent` у той самий сеанс.
 
-- Якщо існує дійсна зовнішня ціль доставки (канал, у який можна доставити, плюс ціль `to`), followup-доставка використовує цей канал.
-- У потоках лише webchat або внутрішньосесійних потоках без зовнішньої цілі доставка followup залишається лише в межах сесії (`deliver: false`).
-- Якщо викликач явно запитує сувору зовнішню доставку без зовнішнього каналу, який можна визначити, запит завершується помилкою `INVALID_REQUEST`.
-- Якщо ввімкнено `bestEffortDeliver` і неможливо визначити зовнішній канал, доставку знижують до режиму лише в сесії замість помилки.
+- Якщо існує дійсна зовнішня ціль доставлення (канал доставлення плюс ціль `to`), доставлення followup використовує цей канал.
+- У потоках лише з webchat або внутрішнім сеансом без зовнішньої цілі доставлення followup залишається лише в межах сеансу (`deliver: false`).
+- Якщо викликач явно запитує суворе зовнішнє доставлення без жодного зовнішнього каналу, що може бути визначений, запит завершується помилкою `INVALID_REQUEST`.
+- Якщо ввімкнено `bestEffortDeliver` і не вдається визначити жоден зовнішній канал, доставлення знижується до режиму лише для сеансу замість помилки.
 
 Діалог підтвердження містить:
 
@@ -410,81 +436,82 @@ Control UI та застосунок macOS обробляють це через
 - cwd
 - id агента
 - визначений шлях до виконуваного файла
-- хост + метадані політики
+- метадані хоста + політики
 
 Дії:
 
-- **Allow once** → запустити зараз
-- **Always allow** → додати до списку дозволів + запустити
+- **Allow once** → виконати зараз
+- **Always allow** → додати до списку дозволених дій + виконати
 - **Deny** → заблокувати
 
 ## Пересилання підтверджень до чат-каналів
 
-Ви можете пересилати запити на підтвердження exec до будь-якого чат-каналу (включно з каналами plugin) і підтверджувати
-їх через `/approve`. Для цього використовується звичайний конвеєр вихідної доставки.
+Ви можете пересилати запити на підтвердження exec до будь-якого чат-каналу (включно з каналами плагінів) і підтверджувати
+їх за допомогою `/approve`. Для цього використовується звичайний конвеєр вихідного доставлення.
 
 Конфігурація:
-__OC_I18N_900005__
-Відповідь у чаті:
 __OC_I18N_900006__
-Команда `/approve` обробляє як підтвердження exec, так і підтвердження plugin. Якщо ID не збігається з очікуваним підтвердженням exec, вона автоматично перевіряє підтвердження plugin.
-
-### Пересилання підтверджень plugin
-
-Пересилання підтверджень plugin використовує той самий конвеєр доставки, що й підтвердження exec, але має власну
-незалежну конфігурацію в `approvals.plugin`. Увімкнення або вимкнення одного не впливає на інше.
+Відповідь у чаті:
 __OC_I18N_900007__
-Форма конфігурації ідентична `approvals.exec`: `enabled`, `mode`, `agentFilter`,
-`sessionFilter` і `targets` працюють однаково.
+Команда `/approve` обробляє як підтвердження exec, так і підтвердження плагінів. Якщо ID не збігається з жодним очікуваним підтвердженням exec, вона автоматично перевіряє підтвердження плагінів.
 
-Канали, які підтримують спільні інтерактивні відповіді, відображають однакові кнопки підтвердження як для exec, так і для
-підтверджень plugin. Канали без спільного інтерактивного UI повертаються до звичайного тексту з інструкціями `/approve`.
+### Пересилання підтверджень плагінів
+
+Пересилання підтверджень плагінів використовує той самий конвеєр доставлення, що й підтвердження exec, але має власну
+незалежну конфігурацію в `approvals.plugin`. Увімкнення або вимкнення одного не впливає на інше.
+__OC_I18N_900008__
+Форма конфігурації ідентична `approvals.exec`: `enabled`, `mode`, `agentFilter`,
+`sessionFilter` і `targets` працюють так само.
+
+Канали, що підтримують спільні інтерактивні відповіді, показують однакові кнопки підтвердження як для exec, так і для
+підтверджень плагінів. Канали без спільного інтерактивного UI використовують звичайний текст із
+інструкціями `/approve`.
 
 ### Підтвердження в тому самому чаті на будь-якому каналі
 
-Коли запит на підтвердження exec або plugin походить із чат-поверхні, у яку можна доставити повідомлення, цей самий чат
-тепер може типово підтвердити його через `/approve`. Це застосовується до таких каналів, як Slack, Matrix і
-Microsoft Teams, на додачу до наявних потоків Web UI і terminal UI.
+Коли запит на підтвердження exec або плагіна надходить із чату, який підтримує доставлення, цей самий чат
+тепер за замовчуванням може підтверджувати його через `/approve`. Це стосується таких каналів, як Slack, Matrix і
+Microsoft Teams, а також наявних потоків Web UI і terminal UI.
 
-Цей спільний шлях текстової команди використовує звичайну модель автентифікації каналу для цієї розмови. Якщо чат-
-джерело вже може надсилати команди й отримувати відповіді, запитам на підтвердження більше не потрібен
-окремий власний адаптер доставки лише для того, щоб залишатися в очікуванні.
+Цей спільний шлях текстової команди використовує звичайну модель автентифікації каналу для цієї розмови. Якщо вихідний чат
+вже може надсилати команди й отримувати відповіді, запитам на підтвердження більше не потрібен
+окремий власний адаптер доставлення лише для того, щоб залишатися в очікуванні.
 
-Discord і Telegram також підтримують `/approve` у тому самому чаті, але ці канали все одно використовують свій
-визначений список схвалювачів для авторизації, навіть коли власну доставку підтверджень вимкнено.
+Discord і Telegram також підтримують `/approve` у тому самому чаті, але ці канали все ще використовують свій
+визначений список тих, хто може підтверджувати, для авторизації, навіть коли власне доставлення підтверджень вимкнено.
 
-Для Telegram та інших власних клієнтів підтвердження, які напряму викликають Gateway,
-цей fallback навмисно обмежений помилками типу "підтвердження не знайдено". Реальна
-відмова/помилка підтвердження exec не повторюється мовчки як підтвердження plugin.
+Для Telegram та інших власних клієнтів підтвердження, які викликають Gateway безпосередньо,
+цей резервний механізм навмисно обмежено збоями типу "підтвердження не знайдено". Реальна
+відмова/помилка підтвердження exec не повторюється мовчки як підтвердження плагіна.
 
-### Власна доставка підтверджень
+### Власне доставлення підтверджень
 
-Деякі канали також можуть діяти як власні клієнти підтвердження. Власні клієнти додають DM для схвалювачів, fanout у чат-
-джерело та специфічний для каналу інтерактивний UX підтвердження поверх спільного потоку `/approve` у тому самому чаті.
+Деякі канали також можуть працювати як власні клієнти підтвердження. Власні клієнти додають приватні повідомлення тим, хто може підтверджувати, fanout у вихідний чат
+і специфічний для каналу інтерактивний UX підтвердження поверх спільного потоку `/approve` у тому самому чаті.
 
 Коли доступні власні картки/кнопки підтвердження, цей власний UI є основним
-шляхом для агента. Агент не повинен також дублювати звичайну чат-команду
-`/approve`, якщо тільки результат інструмента не каже, що чат-підтвердження недоступні або
+шляхом взаємодії для агента. Агент також не повинен дублювати звичайну команду чату
+`/approve`, якщо тільки результат інструмента не вказує, що підтвердження через чат недоступні або
 ручне підтвердження — це єдиний шлях, що залишився.
 
 Загальна модель:
 
-- політика host exec, як і раніше, визначає, чи потрібне підтвердження exec
-- `approvals.exec` керує пересиланням запитів на підтвердження до інших чат-призначень
-- `channels.<channel>.execApprovals` керує тим, чи діє цей канал як власний клієнт підтвердження
+- політика виконання на хості й далі визначає, чи потрібне підтвердження exec
+- `approvals.exec` керує пересиланням запитів на підтвердження в інші чат-призначення
+- `channels.<channel>.execApprovals` керує тим, чи цей канал виступає власним клієнтом підтвердження
 
-Власні клієнти підтвердження автоматично вмикають доставку спочатку в DM, коли всі ці умови істинні:
+Власні клієнти підтвердження автоматично вмикають доставлення спочатку в DM, якщо виконуються всі ці умови:
 
-- канал підтримує власну доставку підтверджень
-- схвалювачів можна визначити з явних `execApprovals.approvers` або з
-  документованих fallback-джерел цього каналу
+- канал підтримує власне доставлення підтверджень
+- тих, хто може підтверджувати, можна визначити з явних `execApprovals.approvers` або з
+  задокументованих резервних джерел цього каналу
 - `channels.<channel>.execApprovals.enabled` не задано або має значення `"auto"`
 
 Установіть `enabled: false`, щоб явно вимкнути власний клієнт підтвердження. Установіть `enabled: true`, щоб примусово
-ввімкнути його, коли схвалювачів визначено. Публічна доставка в чат-джерело, як і раніше, вмикається явно через
+ввімкнути його, коли тих, хто може підтверджувати, вдається визначити. Доставлення в публічний вихідний чат і далі явно керується через
 `channels.<channel>.execApprovals.target`.
 
-FAQ: [Чому існують дві конфігурації підтверджень exec для чат-підтверджень?](/help/faq#why-are-there-two-exec-approval-configs-for-chat-approvals)
+FAQ: [Чому для підтверджень exec у чаті існує дві конфігурації?](/help/faq#why-are-there-two-exec-approval-configs-for-chat-approvals)
 
 - Discord: `channels.discord.execApprovals.*`
 - Slack: `channels.slack.execApprovals.*`
@@ -495,29 +522,29 @@ FAQ: [Чому існують дві конфігурації підтвердж
 
 Спільна поведінка:
 
-- Slack, Matrix, Microsoft Teams та подібні чати з доставкою використовують звичайну модель автентифікації каналу
+- Slack, Matrix, Microsoft Teams та подібні чати, що підтримують доставлення, використовують звичайну модель автентифікації каналу
   для `/approve` у тому самому чаті
-- коли власний клієнт підтвердження вмикається автоматично, типовою власною ціллю доставки є DM схвалювачів
-- для Discord і Telegram лише визначені схвалювачі можуть схвалювати або відхиляти
-- схвалювачі Discord можуть бути явними (`execApprovals.approvers`) або виводитися з `commands.ownerAllowFrom`
-- схвалювачі Telegram можуть бути явними (`execApprovals.approvers`) або виводитися з наявної конфігурації owner (`allowFrom`, плюс `defaultTo` для direct-message, де це підтримується)
-- схвалювачі Slack можуть бути явними (`execApprovals.approvers`) або виводитися з `commands.ownerAllowFrom`
-- власні кнопки Slack зберігають тип id підтвердження, тому id `plugin:` можуть визначати підтвердження plugin
-  без другого локального fallback-рівня Slack
-- власна маршрутизація Matrix у DM/канал і shortcut-реакції обробляють як підтвердження exec, так і plugin;
-  авторизація plugin, як і раніше, походить із `channels.matrix.dm.allowFrom`
-- запитувач не обов’язково має бути схвалювачем
-- чат-джерело може схвалити напряму через `/approve`, коли цей чат уже підтримує команди та відповіді
-- власні кнопки підтвердження Discord маршрутизують за типом id підтвердження: id `plugin:` переходять
-  безпосередньо до підтверджень plugin, усе інше — до підтверджень exec
-- власні кнопки підтвердження Telegram дотримуються того самого обмеженого fallback exec-to-plugin, що й `/approve`
-- коли власний `target` вмикає доставку в чат-джерело, запити на підтвердження містять текст команди
-- очікувані підтвердження exec типово спливають через 30 хвилин
+- коли власний клієнт підтвердження автоматично вмикається, типовою ціллю власного доставлення стають DM тим, хто може підтверджувати
+- для Discord і Telegram лише визначені особи, які можуть підтверджувати, можуть підтверджувати або відхиляти
+- осіб, які можуть підтверджувати в Discord, можна задати явно (`execApprovals.approvers`) або вивести з `commands.ownerAllowFrom`
+- осіб, які можуть підтверджувати в Telegram, можна задати явно (`execApprovals.approvers`) або вивести з наявної конфігурації власника (`allowFrom`, а також `defaultTo` для direct-message, де це підтримується)
+- осіб, які можуть підтверджувати в Slack, можна задати явно (`execApprovals.approvers`) або вивести з `commands.ownerAllowFrom`
+- власні кнопки Slack зберігають тип id підтвердження, тож id `plugin:` можуть визначати підтвердження плагінів
+  без другого локального резервного шару Slack
+- власна маршрутизація DM/каналу та швидкі реакції Matrix обробляють як підтвердження exec, так і підтвердження плагінів;
+  авторизація плагінів і далі походить із `channels.matrix.dm.allowFrom`
+- запитувач не обов’язково має бути особою, що може підтверджувати
+- вихідний чат може підтверджувати безпосередньо через `/approve`, коли цей чат уже підтримує команди та відповіді
+- власні кнопки підтвердження Discord маршрутизують за типом id підтвердження: id `plugin:` одразу переходять
+  до підтверджень плагінів, усе інше — до підтверджень exec
+- власні кнопки підтвердження Telegram дотримуються того самого обмеженого резервного переходу від exec до плагіна, що й `/approve`
+- коли власний `target` вмикає доставлення у вихідний чат, запити на підтвердження містять текст команди
+- очікувані підтвердження exec типово протерміновуються через 30 хвилин
 - якщо жоден UI оператора або налаштований клієнт підтвердження не може прийняти запит, запит переходить до `askFallback`
 
-Telegram типово використовує DM схвалювачів (`target: "dm"`). Ви можете перемкнути на `channel` або `both`, якщо
-хочете, щоб запити на підтвердження також з’являлися в початковому чаті/темі Telegram. Для тем форуму Telegram
-OpenClaw зберігає тему для запиту на підтвердження й follow-up після підтвердження.
+Telegram типово використовує DM для тих, хто може підтверджувати (`target: "dm"`). Ви можете переключити це на `channel` або `both`, якщо
+хочете, щоб запити на підтвердження також з’являлися у вихідному чаті/темі Telegram. Для тем форуму Telegram
+OpenClaw зберігає тему для запиту на підтвердження і follow-up після підтвердження.
 
 Дивіться:
 
@@ -525,12 +552,12 @@ OpenClaw зберігає тему для запиту на підтвердже
 - [Telegram](/channels/telegram)
 
 ### Потік IPC у macOS
-__OC_I18N_900008__
+__OC_I18N_900009__
 Примітки щодо безпеки:
 
-- Режим Unix-сокета `0600`, токен зберігається в `exec-approvals.json`.
-- Перевірка peer з тим самим UID.
-- Challenge/response (nonce + HMAC token + hash запиту) + короткий TTL.
+- Режим Unix socket `0600`, токен зберігається в `exec-approvals.json`.
+- Перевірка однотипного UID однорангового процесу.
+- Challenge/response (nonce + HMAC token + хеш запиту) + короткий TTL.
 
 ## Системні події
 
@@ -540,36 +567,36 @@ __OC_I18N_900008__
 - `Exec finished`
 - `Exec denied`
 
-Вони публікуються в сесії агента після того, як вузол повідомляє про подію.
-Підтвердження exec на gateway host надсилають ті самі події життєвого циклу, коли команда завершується (і, за потреби, коли виконується довше за поріг).
+Вони публікуються в сеанс агента після того, як вузол повідомляє про подію.
+Підтвердження exec на хості gateway надсилають ті самі події життєвого циклу, коли команда завершується (і, за потреби, коли вона виконується довше за поріг).
 Exec із підтвердженням повторно використовують id підтвердження як `runId` у цих повідомленнях для зручної кореляції.
 
-## Поведінка при відхиленому підтвердженні
+## Поведінка у разі відхиленого підтвердження
 
-Коли асинхронне підтвердження exec відхиляється, OpenClaw забороняє агенту повторно використовувати
-вивід будь-якого попереднього запуску тієї самої команди в сесії. Причина відхилення
-передається разом із явною вказівкою, що жодного виводу команди немає, що заважає
+Коли асинхронне підтвердження exec відхилене, OpenClaw не дозволяє агенту повторно використовувати
+вивід будь-якого попереднього запуску тієї самої команди в сеансі. Причина відхилення
+передається з явною вказівкою, що жодного виводу команди немає, що не дозволяє
 агенту стверджувати, що є новий вивід, або повторювати відхилену команду зі
 застарілими результатами попереднього успішного запуску.
 
 ## Наслідки
 
-- **full** — це потужний режим; за можливості віддавайте перевагу спискам дозволів.
-- **ask** залишає вас у циклі, водночас даючи можливість швидко підтверджувати.
-- Списки дозволів для окремих агентів не дають підтвердженням одного агента просочуватися до інших.
+- **full** має широкі можливості; за можливості надавайте перевагу спискам дозволених дій.
+- **ask** залишає вас у циклі, водночас дозволяючи швидко підтверджувати.
+- Окремі для кожного агента списки дозволених дій не дають підтвердженням одного агента потрапляти до інших.
 - Підтвердження застосовуються лише до запитів host exec від **авторизованих відправників**. Неавторизовані відправники не можуть виконувати `/exec`.
-- `/exec security=full` — це зручність на рівні сесії для авторизованих операторів і за задумом пропускає підтвердження.
-  Щоб жорстко заборонити host exec, установіть безпеку підтверджень у `deny` або забороніть інструмент `exec` через політику інструментів.
+- `/exec security=full` — це зручний параметр на рівні сеансу для авторизованих операторів, який навмисно пропускає підтвердження.
+  Щоб жорстко заборонити host exec, установіть для security підтверджень значення `deny` або забороніть інструмент `exec` через політику інструментів.
 
 Пов’язане:
 
-- [Exec tool](/uk/tools/exec)
-- [Elevated mode](/uk/tools/elevated)
+- [Інструмент Exec](/uk/tools/exec)
+- [Режим Elevated](/uk/tools/elevated)
 - [Skills](/uk/tools/skills)
 
 ## Пов’язане
 
 - [Exec](/uk/tools/exec) — інструмент виконання shell-команд
-- [Sandboxing](/uk/gateway/sandboxing) — режими sandbox і доступ до workspace
-- [Security](/uk/gateway/security) — модель безпеки та посилення
-- [Sandbox vs Tool Policy vs Elevated](/uk/gateway/sandbox-vs-tool-policy-vs-elevated) — коли використовувати кожен варіант
+- [Пісочниця](/uk/gateway/sandboxing) — режими пісочниці та доступ до робочого простору
+- [Безпека](/uk/gateway/security) — модель безпеки та посилення захисту
+- [Пісочниця vs Політика інструментів vs Elevated](/uk/gateway/sandbox-vs-tool-policy-vs-elevated) — коли що використовувати