chore(i18n): refresh uk translations

Author: openclaw-docs-i18n[bot]

docs/uk/cli/node.md

@@ -1,49 +1,49 @@
 ---
 read_when:
-    - Запуск headless хоста Node
+    - Запуск безголового хоста Node
     - Сполучення вузла не на macOS для system.run
-summary: Довідка CLI для `openclaw node` (headless хост Node)
+summary: Довідник CLI для `openclaw node` (безголовий хост Node)
 title: Node
 x-i18n:
-    generated_at: "2026-04-24T05:21:35Z"
+    generated_at: "2026-04-24T06:45:24Z"
     model: gpt-5.4
     provider: openai
-    source_hash: 61b16bdd0c52115bc9938a0fc975369159a4e45d743173ab4e65fce8292af51e
+    source_hash: 9f2bd6d61ee87d36f7691207d03a91c914e6460549256e0cc6ea7bebfa713923
     source_path: cli/node.md
     workflow: 15
 ---
 
 # `openclaw node`
 
-Запустіть **headless хост Node**, який підключається до WebSocket Gateway і надає
+Запускає **безголовий хост Node**, який підключається до WebSocket Gateway і надає
 `system.run` / `system.which` на цій машині.
 
 ## Навіщо використовувати хост Node?
 
 Використовуйте хост Node, коли хочете, щоб агенти **запускали команди на інших машинах** у вашій
-мережі без встановлення там повноцінного допоміжного застосунку для macOS.
+мережі без встановлення повноцінного супутнього застосунку macOS на цих машинах.
 
 Поширені сценарії використання:
 
 - Запуск команд на віддалених Linux/Windows машинах (сервери збірки, лабораторні машини, NAS).
-- Зберігайте **ізоляцію** exec на Gateway, але делегуйте дозволені запуски іншим хостам.
-- Надайте легку, headless ціль виконання для вузлів автоматизації або CI.
+- Зберігайте **ізоляцію** exec на Gateway, але делегуйте схвалені запуски іншим хостам.
+- Надайте легку, безголову ціль виконання для вузлів автоматизації або CI.
 
-Виконання все одно захищене **погодженнями exec** та списками дозволів для кожного агента на
-хості Node, тож ви можете зберігати доступ до команд обмеженим і явним.
+Виконання, як і раніше, захищене **схваленнями exec** та списками дозволів для кожного агента на
+хості Node, тож ви можете зберігати доступ до команд обмеженим і явно визначеним.
 
 ## Проксі браузера (нульова конфігурація)
 
 Хости Node автоматично оголошують проксі браузера, якщо `browser.enabled` не
-вимкнено на вузлі. Це дозволяє агенту використовувати автоматизацію браузера на цьому вузлі
-без додаткового налаштування.
+вимкнено на вузлі. Це дозволяє агенту використовувати автоматизацію браузера на
+цьому вузлі без додаткової конфігурації.
 
-За замовчуванням проксі надає доступ до звичайної поверхні профілю браузера вузла. Якщо ви
+Типово проксі відкриває поверхню звичайного профілю браузера вузла. Якщо ви
 встановите `nodeHost.browserProxy.allowProfiles`, проксі стане обмежувальним:
-націлювання на профілі поза списком дозволених буде відхилено, а маршрути
-створення/видалення постійних профілів буде заблоковано через проксі.
+націлювання на профілі, яких немає у списку дозволених, буде відхилено, а
+маршрути створення/видалення постійних профілів будуть заблоковані через проксі.
 
-За потреби вимкніть це на вузлі:
+За потреби вимкніть його на вузлі:
 
 ```json5
 {
@@ -55,7 +55,7 @@ x-i18n:
 }
 ```
 
-## Запуск (у передньому плані)
+## Запуск (на передньому плані)
 
 ```bash
 openclaw node run --host <gateway-host> --port 18789
@@ -65,30 +65,33 @@ openclaw node run --host <gateway-host> --port 18789
 
 - `--host <host>`: хост WebSocket Gateway (типово: `127.0.0.1`)
 - `--port <port>`: порт WebSocket Gateway (типово: `18789`)
-- `--tls`: використовувати TLS для підключення до gateway
-- `--tls-fingerprint <sha256>`: очікуваний відбиток TLS-сертифіката (sha256)
-- `--node-id <id>`: перевизначити id вузла (очищає токен сполучення)
+- `--tls`: використовувати TLS для з’єднання з gateway
+- `--tls-fingerprint <sha256>`: очікуваний відбиток сертифіката TLS (sha256)
+- `--node-id <id>`: перевизначити ідентифікатор вузла (очищає токен сполучення)
 - `--display-name <name>`: перевизначити відображувану назву вузла
 
 ## Автентифікація Gateway для хоста Node
 
 `openclaw node run` і `openclaw node install` визначають автентифікацію gateway з config/env (без прапорців `--token`/`--password` у командах node):
 
-- `OPENCLAW_GATEWAY_TOKEN` / `OPENCLAW_GATEWAY_PASSWORD` перевіряються першими.
-- Потім використовується резервне значення з локальної конфігурації: `gateway.auth.token` / `gateway.auth.password`.
+- Спочатку перевіряються `OPENCLAW_GATEWAY_TOKEN` / `OPENCLAW_GATEWAY_PASSWORD`.
+- Далі використовується локальний резервний варіант із config: `gateway.auth.token` / `gateway.auth.password`.
 - У локальному режимі хост Node навмисно не успадковує `gateway.remote.token` / `gateway.remote.password`.
-- Якщо `gateway.auth.token` / `gateway.auth.password` явно налаштовано через SecretRef і їх не вдається визначити, визначення автентифікації вузла завершується із закритою відмовою (без маскування резервним віддаленим варіантом).
-- У `gateway.mode=remote` поля віддаленого клієнта (`gateway.remote.token` / `gateway.remote.password`) також можуть використовуватися згідно з правилами пріоритету для віддаленого режиму.
+- Якщо `gateway.auth.token` / `gateway.auth.password` явно налаштовано через SecretRef і вони не розв’язані, визначення автентифікації вузла завершується в закритому режимі (без маскування резервним віддаленим варіантом).
+- У `gateway.mode=remote` поля віддаленого клієнта (`gateway.remote.token` / `gateway.remote.password`) також можуть використовуватися відповідно до правил пріоритету віддаленого режиму.
 - Визначення автентифікації хоста Node враховує лише змінні середовища `OPENCLAW_GATEWAY_*`.
 
-Для вузла, що підключається до не-loopback `ws://` Gateway у довіреній приватній
-мережі, встановіть `OPENCLAW_ALLOW_INSECURE_PRIVATE_WS=1`. Без цього запуск вузла
-завершиться із закритою відмовою і запропонує вам використовувати `wss://`, SSH-тунель або Tailscale.
-`openclaw node install` зберігає цю явну згоду в сервісі вузла під наглядом.
+Для вузла, що підключається до Gateway `ws://` не на loopback-адресі в довіреній приватній
+мережі, установіть `OPENCLAW_ALLOW_INSECURE_PRIVATE_WS=1`. Без цього запуск
+вузла завершується в закритому режимі та пропонує використовувати `wss://`,
+тунель SSH або Tailscale.
+Це opt-in через середовище процесу, а не ключ конфігурації `openclaw.json`.
+`openclaw node install` зберігає його в керованому сервісі вузла, якщо він
+присутній у середовищі команди встановлення.
 
 ## Сервіс (у фоновому режимі)
 
-Встановіть headless хост Node як користувацький сервіс.
+Встановіть безголовий хост Node як сервіс користувача.
 
 ```bash
 openclaw node install --host <gateway-host> --port 18789
@@ -98,11 +101,11 @@ openclaw node install --host <gateway-host> --port 18789
 
 - `--host <host>`: хост WebSocket Gateway (типово: `127.0.0.1`)
 - `--port <port>`: порт WebSocket Gateway (типово: `18789`)
-- `--tls`: використовувати TLS для підключення до gateway
-- `--tls-fingerprint <sha256>`: очікуваний відбиток TLS-сертифіката (sha256)
-- `--node-id <id>`: перевизначити id вузла (очищає токен сполучення)
+- `--tls`: використовувати TLS для з’єднання з gateway
+- `--tls-fingerprint <sha256>`: очікуваний відбиток сертифіката TLS (sha256)
+- `--node-id <id>`: перевизначити ідентифікатор вузла (очищає токен сполучення)
 - `--display-name <name>`: перевизначити відображувану назву вузла
-- `--runtime <runtime>`: runtime сервісу (`node` або `bun`)
+- `--runtime <runtime>`: середовище виконання сервісу (`node` або `bun`)
 - `--force`: перевстановити/перезаписати, якщо вже встановлено
 
 Керування сервісом:
@@ -114,41 +117,42 @@ openclaw node restart
 openclaw node uninstall
 ```
 
-Використовуйте `openclaw node run` для хоста Node у передньому плані (без сервісу).
+Використовуйте `openclaw node run` для запуску хоста Node на передньому плані (без сервісу).
 
 Команди сервісу приймають `--json` для машиночитаного виводу.
 
 ## Сполучення
 
-Під час першого підключення на Gateway створюється запит на сполучення пристрою, що очікує підтвердження (`role: node`).
-Підтвердьте його за допомогою:
+Перше з’єднання створює очікуваний запит на сполучення пристрою (`role: node`) на Gateway.
+Схваліть його за допомогою:
 
 ```bash
 openclaw devices list
 openclaw devices approve <requestId>
 ```
 
 Якщо вузол повторно намагається виконати сполучення зі зміненими даними автентифікації (role/scopes/public key),
-попередній запит, що очікує підтвердження, замінюється, і створюється новий `requestId`.
-Перед підтвердженням знову виконайте `openclaw devices list`.
+попередній очікуваний запит замінюється, і створюється новий `requestId`.
+Перед схваленням знову виконайте `openclaw devices list`.
 
-Хост Node зберігає id вузла, токен, відображувану назву та інформацію про підключення до gateway у
+Хост Node зберігає свій ідентифікатор вузла, токен, відображувану назву та інформацію про з’єднання з gateway у
 `~/.openclaw/node.json`.
 
-## Погодження exec
+## Схвалення exec
 
-`system.run` захищено локальними погодженнями exec:
+`system.run` контролюється локальними схваленнями exec:
 
 - `~/.openclaw/exec-approvals.json`
-- [Погодження exec](/uk/tools/exec-approvals)
+- [Схвалення exec](/uk/tools/exec-approvals)
 - `openclaw approvals --node <id|name|ip>` (редагування з Gateway)
 
-Для схваленого асинхронного exec вузла OpenClaw готує канонічний `systemRunPlan`
-перед запитом підтвердження. Подальше переспрямування схваленого `system.run` повторно використовує цей збережений
-план, тому редагування полів command/cwd/session після створення запиту
-на погодження буде відхилено замість зміни того, що виконує вузол.
+Для схваленого асинхронного exec на вузлі OpenClaw готує канонічний `systemRunPlan`
+перед запитом підтвердження. Пізніше переспрямування схваленого `system.run`
+повторно використовує цей збережений план, тож зміни до полів command/cwd/session
+після створення запиту на схвалення будуть відхилені замість зміни того, що
+виконує вузол.
 
 ## Пов’язане
 
-- [Довідка CLI](/uk/cli)
+- [Довідник CLI](/uk/cli)
 - [Вузли](/uk/nodes)