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

​
openclaw node

Запустіть безголовий хост вузла, який підключається до Gateway WebSocket і надає system.run / system.which на цій машині.

​
Навіщо використовувати хост вузла?

Використовуйте хост вузла, коли хочете, щоб агенти виконували команди на інших машинах у вашій мережі без установлення там повного супутнього застосунку macOS. Поширені сценарії використання:
  • Виконання команд на віддалених машинах Linux/Windows (сервери збірки, лабораторні машини, NAS).
  • Тримати exec ізольованим у sandbox на шлюзі, але делегувати схвалені запуски іншим хостам.
  • Надати легку, безголову ціль виконання для автоматизації або вузлів CI.
Виконання все одно захищене схваленнями exec і allowlist для кожного агента на хості вузла, тож доступ до команд можна залишати обмеженим і явним.

​
Проксі браузера (без конфігурації)

Хости вузлів автоматично оголошують проксі браузера, якщо browser.enabled не вимкнено на вузлі. Це дає агенту змогу використовувати автоматизацію браузера на цьому вузлі без додаткової конфігурації. За замовчуванням проксі відкриває звичайну поверхню профілю браузера вузла. Якщо ви задасте nodeHost.browserProxy.allowProfiles, проксі стане обмежувальним: цільові профілі поза allowlist відхиляються, а маршрути створення/видалення постійних профілів блокуються через проксі. За потреби вимкніть це на вузлі: 
{
  nodeHost: {
    browserProxy: {
      enabled: false,
    },
  },
}

​
Запуск (передній план)

openclaw node run --host <gateway-host> --port 18789
Параметри:
  • --host <host>: хост Gateway WebSocket (за замовчуванням: 127.0.0.1)
  • --port <port>: порт Gateway WebSocket (за замовчуванням: 18789)
  • --context-path <path>: шлях контексту Gateway WebSocket (наприклад, /openclaw-gw). Додається до URL WebSocket.
  • --tls: використовувати TLS для підключення до gateway
  • --tls-fingerprint <sha256>: очікуваний відбиток TLS-сертифіката (sha256)
  • --node-id <id>: перевизначити ідентифікатор вузла (очищає токен спарювання)
  • --display-name <name>: перевизначити відображуване ім’я вузла

​
Автентифікація Gateway для хоста вузла

openclaw node run і openclaw node install визначають автентифікацію gateway з config/env (без прапорців --token/--password у командах вузла):
  • Спочатку перевіряються OPENCLAW_GATEWAY_TOKEN / OPENCLAW_GATEWAY_PASSWORD.
  • Потім локальний резервний варіант конфігурації: gateway.auth.token / gateway.auth.password.
  • У локальному режимі хост вузла навмисно не успадковує gateway.remote.token / gateway.remote.password.
  • Якщо gateway.auth.token / gateway.auth.password явно налаштовано через SecretRef і не розв’язано, визначення автентифікації вузла завершується закритою відмовою (без маскування віддаленим резервним варіантом).
  • У gateway.mode=remote поля віддаленого клієнта (gateway.remote.token / gateway.remote.password) також можуть використовуватися відповідно до правил віддаленого пріоритету.
  • Визначення автентифікації хоста вузла враховує лише змінні середовища OPENCLAW_GATEWAY_*.
Для вузла, що підключається до незашифрованого Gateway ws://, приймаються loopback, літерали приватних IP, .local і хости Tailnet *.ts.net. Для інших довірених приватних DNS-імен задайте OPENCLAW_ALLOW_INSECURE_PRIVATE_WS=1; без цього запуск вузла завершується закритою відмовою і просить використати wss://, SSH-тунель або Tailscale. Це opt-in через середовище процесу, а не ключ конфігурації openclaw.json. openclaw node install зберігає його в контрольованій службі вузла, коли він присутній у середовищі команди встановлення.

​
Служба (фоновий режим)

Установіть безголовий хост вузла як користувацьку службу. 
openclaw node install --host <gateway-host> --port 18789
Параметри:
  • --host <host>: хост Gateway WebSocket (за замовчуванням: 127.0.0.1)
  • --port <port>: порт Gateway WebSocket (за замовчуванням: 18789)
  • --context-path <path>: шлях контексту Gateway WebSocket (наприклад, /openclaw-gw). Додається до URL WebSocket.
  • --tls: використовувати TLS для підключення до gateway
  • --tls-fingerprint <sha256>: очікуваний відбиток TLS-сертифіката (sha256)
  • --node-id <id>: перевизначити ідентифікатор вузла (очищає токен спарювання)
  • --display-name <name>: перевизначити відображуване ім’я вузла
  • --runtime <runtime>: середовище виконання служби (node або bun)
  • --force: перевстановити/перезаписати, якщо вже встановлено
Керуйте службою: 
openclaw node status
openclaw node start
openclaw node stop
openclaw node restart
openclaw node uninstall
Використовуйте openclaw node run для хоста вузла на передньому плані (без служби). Команди служби приймають --json для машинозчитуваного виводу. Хост вузла повторює спроби після перезапуску Gateway і закриття мережевого з’єднання в межах процесу. Якщо Gateway повідомляє про термінальну паузу автентифікації токена/пароля/bootstrap, хост вузла записує деталі закриття в журнал і завершується з ненульовим кодом, щоб launchd/systemd міг перезапустити його зі свіжою конфігурацією та обліковими даними. Паузи, що потребують спарювання, залишаються в потоці переднього плану, щоб очікуваний запит можна було схвалити.

​
Спарювання

Перше підключення створює на Gateway очікуваний запит на спарювання пристрою (role: node). Схваліть його через: 
openclaw devices list
openclaw devices approve <requestId>
У суворо контрольованих мережах вузлів оператор Gateway може явно погодитися автоматично схвалювати перше спарювання вузлів із довірених CIDR: 
{
  gateway: {
    nodes: {
      pairing: {
        autoApproveCidrs: ["192.168.1.0/24"],
      },
    },
  },
}
За замовчуванням це вимкнено. Це застосовується лише до нового спарювання role: node без запитаних scopes. Клієнти оператора/браузера, Control UI, WebChat, а також оновлення ролі, scope, метаданих або публічного ключа все одно потребують ручного схвалення. Якщо вузол повторює спарювання зі зміненими деталями автентифікації (роль/scopes/публічний ключ), попередній очікуваний запит замінюється, і створюється новий requestId. Перед схваленням знову виконайте openclaw devices list. Хост вузла зберігає свій ідентифікатор вузла, токен, відображуване ім’я та інформацію про підключення до gateway у ~/.openclaw/node.json.

​
Схвалення exec

system.run керується локальними схваленнями exec:
  • $OPENCLAW_STATE_DIR/exec-approvals.json, або ~/.openclaw/exec-approvals.json, коли змінну не задано
  • Схвалення exec
  • openclaw approvals --node <id|name|ip> (редагування з Gateway)
Для схваленого асинхронного exec вузла OpenClaw готує канонічний systemRunPlan перед запитом. Подальше схвалене переспрямування system.run повторно використовує цей збережений план, тому зміни полів command/cwd/session після створення запиту на схвалення відхиляються замість того, щоб змінювати те, що виконує вузол.

​
Пов’язане