Усунення несправностей

Ця сторінка — поглиблений runbook. Почніть із /help/troubleshooting, якщо спершу потрібен швидкий потік тріажу.

Драбина команд

Спершу виконайте ці команди в такому порядку:

openclaw statusopenclaw gateway statusopenclaw logs --followopenclaw doctoropenclaw channels status --probe

Очікувані ознаки справного стану:

• openclaw gateway status показує Runtime: running, Connectivity probe: ok і рядок Capability: ....
• openclaw doctor не повідомляє про блокувальні проблеми конфігурації чи сервісу.
• openclaw channels status --probe показує живий транспортний статус для кожного акаунта і, де підтримується, результати проби/аудиту, як-от works або audit ok.

Після оновлення

Використовуйте це, коли оновлення завершилося, але Gateway не працює, канали порожні або виклики моделей починають падати з 401.

openclaw status --allopenclaw update status --jsonopenclaw gateway status --deepopenclaw doctor --fixopenclaw gateway restart

Шукайте:

• Update restart в openclaw status / openclaw status --all. Відкладені або невдалі передавання керування містять наступну команду для запуску.
• plugin load failed: dependency tree corrupted; run openclaw doctor --fix у розділі Channels. Це означає, що конфігурація каналу ще існує, але реєстрація Plugin не вдалася до того, як канал зміг завантажитися.
• 401 від провайдера після повторної автентифікації. openclaw doctor --fix перевіряє застарілі OAuth-тіні автентифікації для окремих агентів і видаляє старі копії, щоб усі агенти знаходили поточний спільний профіль.

Роздвоєні інсталяції та захист від новішої конфігурації

Використовуйте це, коли сервіс Gateway несподівано зупиняється після оновлення або журнали показують, що один бінарний файл openclaw старіший за версію, яка востаннє записала openclaw.json.

OpenClaw позначає записи конфігурації через meta.lastTouchedVersion. Команди лише для читання все ще можуть перевіряти конфігурацію, записану новішим OpenClaw, але мутації процесів і сервісів відмовляються продовжувати роботу зі старішого бінарного файла. Заблоковані дії включають запуск, зупинку, перезапуск, видалення сервісу Gateway, примусове перевстановлення сервісу, запуск Gateway у режимі сервісу та очищення порту через gateway --force.

which openclawopenclaw --versionopenclaw gateway status --deepopenclaw config get meta.lastTouchedVersion

openclaw gateway install --forceopenclaw gateway restart

Невідповідність протоколу після відкату

Використовуйте це, коли журнали продовжують друкувати protocol mismatch після того, як ви знизили версію або відкотили OpenClaw. Це означає, що працює старіший Gateway, але новіший локальний клієнтський процес усе ще намагається повторно підключитися з діапазоном протоколу, який старіший Gateway не підтримує.

openclaw --versionwhich -a openclawopenclaw gateway status --deepopenclaw doctor --deepopenclaw logs --follow

Шукайте:

• protocol mismatch ... client=... v<version> min=<n> max=<n> expected=<n> у журналах Gateway.
• Established clients: в openclaw gateway status --deep або Gateway clients в openclaw doctor --deep. Тут наведено активних TCP-клієнтів, підключених до порту Gateway, зокрема PID і командні рядки, коли ОС це дозволяє.
• Клієнтський процес, командний рядок якого вказує на новішу інсталяцію OpenClaw або обгортку, з якої ви відкотилися.

Виправлення:

1. Зупиніть або перезапустіть застарілий клієнтський процес OpenClaw, показаний у gateway status --deep.
2. Перезапустіть застосунки або обгортки, які вбудовують OpenClaw, як-от локальні dashboards, редактори, допоміжні app-server процеси або довготривалі оболонки openclaw logs --follow.
3. Повторно виконайте openclaw gateway status --deep або openclaw doctor --deep і підтвердьте, що застарілий PID клієнта зник.

Не змушуйте старіший Gateway приймати новіший несумісний протокол. Підвищення версій протоколу захищають контракт передачі; відновлення після відкату — це проблема очищення процесів/версій.

Символічне посилання Skills пропущено як вихід за межі шляху

Використовуйте це, коли журнали містять:

Skipping escaped skill path outside its configured root: ... reason=symlink-escape

OpenClaw розглядає кожен корінь Skills як межу ізоляції. Символічне посилання в ~/.agents/skills, <workspace>/.agents/skills, <workspace>/skills або ~/.openclaw/skills пропускається, коли його реальна ціль знаходиться поза цим коренем, якщо ціль явно не довірена.

Перевірте посилання:

ls -l ~/.agents/skills/<name>realpath ~/.agents/skills/<name>openclaw config get skills.load

Якщо ціль навмисна, налаштуйте і прямий корінь Skills, і дозволену ціль символічного посилання:

{  skills: {    load: {      extraDirs: ["~/Projects/manager/skills"],      allowSymlinkTargets: ["~/Projects/manager/skills"],    },  },}

Потім почніть нову сесію або зачекайте, доки watcher Skills оновиться. Перезапустіть Gateway, якщо запущений процес передував зміні конфігурації.

Не використовуйте широкі цілі на кшталт ~, / або цілої синхронізованої теки проєкту. Тримайте allowSymlinkTargets обмеженим реальним коренем Skills, що містить довірені каталоги SKILL.md.

Якщо застосування Skill Workshop також має записувати через ці довірені символічні посилання на шляхи Skills у workspace, увімкніть skills.workshop.allowSymlinkTargetWrites. Залишайте це вимкненим для спільних коренів Skills лише для читання.

Пов’язане:

• Конфігурація Skills
• Приклади конфігурації

Anthropic 429 вимагає додаткового використання для довгого контексту

Використовуйте це, коли журнали/помилки містять: HTTP 429: rate_limit_error: Extra usage is required for long context requests.

openclaw logs --followopenclaw models statusopenclaw config get agents.defaults.models

Шукайте:

• Вибрана модель Anthropic є GA-сумісною моделлю Claude 4.x на 1M, або модель має застаріле params.context1m: true.
• Поточні облікові дані Anthropic не мають права на використання довгого контексту.
• Запити падають лише в довгих сесіях/запусках моделей, яким потрібен шлях контексту 1M.

Варіанти виправлення:

Пов’язане:

• Anthropic
• Використання токенів і витрати
• Чому я бачу HTTP 429 від Anthropic?

Відповіді upstream 403 заблоковано

Використовуйте це, коли upstream LLM-провайдер повертає загальний 403, наприклад Your request was blocked.

Не припускайте, що це завжди проблема конфігурації OpenClaw. Відповідь може надходити від upstream-рівня безпеки, як-от CDN, WAF, правило керування ботами або reverse proxy перед OpenAI-сумісною кінцевою точкою.

openclaw statusopenclaw gateway statusopenclaw logs --follow

Шукайте:

• кілька моделей у того самого провайдера падають однаково
• HTML або загальний текст безпеки замість звичайної помилки API провайдера
• події безпеки на боці провайдера для того самого часу запиту
• крихітна пряма проба curl успішна, тоді як звичайні SDK-подібні запити падають

Спершу виправте фільтрацію на боці провайдера, коли докази вказують на блокування WAF/CDN. Надавайте перевагу вузько обмеженому правилу дозволу або пропуску для API-шляху, який використовує OpenClaw, і уникайте вимкнення захисту для всього сайту.

Пов’язане:

• OpenAI-сумісні кінцеві точки
• Конфігурація провайдерів
• Журнали

Локальний OpenAI-сумісний backend проходить прямі проби, але запуски агента падають

Використовуйте це, коли:

• curl ... /v1/models працює
• крихітні прямі виклики /v1/chat/completions працюють
• Запуски моделей OpenClaw падають лише на звичайних ходах агента

curl http://127.0.0.1:1234/v1/modelscurl http://127.0.0.1:1234/v1/chat/completions \  -H 'content-type: application/json' \  -d '{"model":"<id>","messages":[{"role":"user","content":"hi"}],"stream":false}'openclaw infer model run --model <provider/model> --prompt "hi" --jsonopenclaw logs --follow

Шукайте:

• прямі крихітні виклики успішні, але запуски OpenClaw падають лише на більших prompts
• помилки model_not_found або 404, хоча прямий /v1/chat/completions працює з тим самим простим id моделі
• помилки backend про те, що messages[].content очікує рядок
• періодичні попередження incomplete turn detected ... stopReason=stop payloads=0 з OpenAI-сумісним локальним backend
• аварійні збої backend, які з’являються лише з більшими кількостями prompt-токенів або повними prompts runtime агента

Пов’язане:

• Конфігурація
• Локальні моделі
• OpenAI-сумісні кінцеві точки

Немає відповідей

Якщо канали працюють, але нічого не відповідає, перевірте маршрутизацію та політики, перш ніж щось перепідключати.

openclaw statusopenclaw channels status --probeopenclaw pairing list --channel <channel> [--account <id>]openclaw config get channelsopenclaw logs --follow

Шукайте:

• Pairing очікує для відправників DM.
• Обмеження згадування в групі (requireMention, mentionPatterns).
• Невідповідності allowlist каналу/групи.

Поширені ознаки:

• drop guild message (mention required → повідомлення групи ігнорується до згадування.
• pairing request → відправнику потрібне схвалення.
• blocked / allowlist → відправник/канал відфільтровано політикою.

Пов’язано:

• Усунення проблем із каналами
• Групи
• Pairing

Підключення Dashboard control UI

Коли dashboard/control UI не підключається, перевірте URL, режим автентифікації та припущення щодо безпечного контексту.

openclaw gateway statusopenclaw statusopenclaw logs --followopenclaw doctoropenclaw gateway status --json

Шукайте:

• Правильний URL проби та URL dashboard.
• Невідповідність режиму автентифікації/токена між клієнтом і gateway.
• Використання HTTP там, де потрібна ідентичність пристрою.

Якщо локальний браузер не може підключитися до 127.0.0.1:18789 після оновлення, спершу відновіть локальну службу Gateway і підтвердьте, що вона обслуговує dashboard:

openclaw gateway restartlsof -i :18789curl http://127.0.0.1:18789

Якщо curl повертає HTML OpenClaw, Gateway працює, а решта проблеми ймовірно пов’язана з кешем браузера, старим глибоким посиланням або застарілим станом вкладки. Відкрийте http://127.0.0.1:18789 напряму й перейдіть із dashboard. Якщо restart не залишає службу запущеною, виконайте openclaw gateway start і повторно перевірте openclaw gateway status.

Швидка мапа кодів деталей автентифікації

Використовуйте error.details.code з невдалої відповіді connect, щоб вибрати наступну дію:

Перевірка міграції device auth v2:

openclaw --versionopenclaw doctoropenclaw gateway status

Якщо журнали показують помилки nonce/signature, оновіть клієнт, що підключається, і перевірте його:

Якщо openclaw devices rotate / revoke / remove неочікувано відхилено:

• paired-device token sessions можуть керувати лише своїм власним пристроєм, якщо виклик також не має operator.admin
• openclaw devices rotate --scope ... може запитувати лише operator scopes, які вже має сесія виклику

Пов’язано:

• Конфігурація (режими автентифікації gateway)
• Control UI
• Пристрої
• Віддалений доступ
• Автентифікація trusted proxy

Служба Gateway не запущена

Використовуйте це, коли службу встановлено, але процес не залишається запущеним.

openclaw gateway statusopenclaw statusopenclaw logs --followopenclaw doctoropenclaw gateway status --deep   # also scan system-level services

Шукайте:

• Runtime: stopped з підказками щодо виходу.
• Невідповідність конфігурації служби (Config (cli) проти Config (service)).
• Конфлікти port/listener.
• Додаткові встановлення launchd/systemd/schtasks, коли використовується --deep.
• Підказки очищення Other gateway-like services detected (best effort).

Пов’язано:

• Фонове виконання та інструмент процесів
• Конфігурація
• Doctor

macOS gateway непомітно припиняє відповідати, а потім відновлюється, коли ви торкаєтеся dashboard

Використовуйте це, коли канали (Telegram, WhatsApp тощо) на macOS-хості затихають на хвилини або години, а gateway, здається, повертається саме в момент, коли ви відкриваєте Control UI, підключаєтеся через SSH або інакше взаємодієте з хостом. Зазвичай у openclaw status немає очевидного симптому, бо на момент перевірки gateway уже знову працює.

ls ~/.openclaw/logs/stability/ | tail -5openclaw gateway stability --bundle latestpmset -g log | grep -iE "sleep|wake|maintenance" | tail -50launchctl print gui/$UID/ai.openclaw.gateway | grep -E "state|last exit|runs"

Шукайте:

• Один або кілька пакетів *-uncaught_exception.json у ~/.openclaw/logs/stability/, де error.code має тимчасовий мережевий код, наприклад ENETDOWN, ENETUNREACH, EHOSTUNREACH або ECONNREFUSED.
• Рядки pmset -g log на кшталт Entering Sleep state due to 'Maintenance Sleep' або en0 driver is slow (msg: WillChangeState to 0), що збігаються з часовими мітками аварійного завершення. Power Nap / Maintenance Sleep короткочасно переводить драйвер Wi-Fi у стан 0; будь-який вихідний connect(), що потрапляє в це вікно, може завершитися помилкою ENETDOWN навіть на хості, який загалом має повне мережеве підключення.
• Вивід launchctl print, що показує state = not running із кількома нещодавніми runs і кодом виходу, особливо коли проміжок між аварійним завершенням і наступним запуском становить приблизно годину, а не секунди. macOS launchd застосовує недокументований запобіжник від повторних запусків після серії аварійних завершень, який може припинити виконання KeepAlive=true, доки зовнішній тригер, наприклад інтерактивний вхід, підключення до панелі керування або launchctl kickstart, знову його не активує.

Типові ознаки:

• Пакет стабільності, де error.code дорівнює ENETDOWN або спорідненому коду, а стек викликів вказує на Node net lookupAndConnect / Socket.connect. OpenClaw 2026.5.26 і новіші версії класифікують їх як безпечні тимчасові мережеві помилки, тому вони більше не доходять до верхньорівневого обробника неперехоплених винятків; якщо ви використовуєте старіший випуск, спочатку оновіться.
• Довгі періоди тиші, що завершуються саме в момент підключення до інтерфейсу керування або входу на хост через SSH: видима для користувача активність повторно активує запобіжник повторного запуску launchd, а не будь-яка дія панелі керування щодо Gateway.
• Лічильник runs зростає протягом дня без відповідного рядка received SIG*; shutting down у ~/Library/Logs/openclaw/gateway.log: коректні завершення роботи записують сигнал; тимчасові аварійні завершення цього не роблять.

Що робити:

1. Оновіть Gateway, якщо ви використовуєте випуск до 2026.5.26. Після оновлення майбутні помилки ENETDOWN записуватимуться як попередження, а не завершуватимуть процес.

2. Зменште активність maintenance sleep на Mac mini / настільних хостах, які мають працювати як постійно ввімкнені сервери:

   sudo pmset -a sleep 0 disksleep 0 standby 0 powernap 0

   Це суттєво зменшує, але не усуває повністю, базове перемикання драйвера. Система все одно може виконувати деякі maintenance sleep для TCP keepalive і підтримки mDNS незалежно від цих прапорців.

3. Додайте сторожовий механізм доступності, щоб майбутня серія аварійних завершень, яку launchd залишить у зупиненому стані, швидко виявлялася:

   # Example launchd-aware liveness check, suitable for a 5-minute cron or LaunchAgentstate=$(launchctl print gui/$UID/ai.openclaw.gateway 2>/dev/null | awk -F'= ' '/state =/ {print $2; exit}')if [ "$state" != "running" ]; then  launchctl kickstart -k gui/$UID/ai.openclaw.gatewayfi

   Суть у тому, щоб ззовні повторно активувати запобіжник повторного запуску; одного KeepAlive=true на macOS після серії аварійних завершень недостатньо.

Пов’язане:

• Примітки щодо платформи macOS
• Журналювання
• Doctor

Gateway завершується під час високого використання пам’яті

Використовуйте це, коли Gateway зникає під навантаженням, супервізор повідомляє про перезапуск у стилі OOM або журнали згадують critical memory pressure bundle written.

openclaw gateway status --deepopenclaw logs --followopenclaw gateway stability --bundle latestopenclaw gateway diagnostics export

Шукайте:

• Reason: diagnostic.memory.pressure.critical в останньому пакеті стабільності.
• Memory pressure: із critical/rss_threshold, critical/heap_threshold або critical/rss_growth.
• Значення V8 heap: поблизу межі heap.
• Записи Largest session files:, наприклад agents/<agent>/sessions/<session>.jsonl або sessions/<session>.jsonl.
• Лічильники пам’яті cgroup Linux, коли Gateway працює всередині контейнера або служби з обмеженням пам’яті.

Типові ознаки:

• critical memory pressure bundle written з’являється незадовго до перезапуску → OpenClaw зібрав пакет стабільності перед OOM. Перегляньте його через openclaw gateway stability --bundle latest.
• memory pressure: level=critical ... memoryPressureSnapshot=disabled з’являється в журналах Gateway → OpenClaw виявив критичний тиск на пам’ять, але знімок стабільності перед OOM вимкнено.
• Largest session files: вказує на дуже великий шлях редагованого транскрипту → зменште збережену історію сеансів, перевірте зростання сеансу або перемістіть старі транскрипти з активного сховища перед перезапуском.
• Використані байти V8 heap: близькі до межі heap → зменште навантаження промптів/сеансів, скоротіть паралельну роботу або збільште межу heap Node лише після підтвердження, що навантаження очікуване.
• Memory pressure: critical/rss_growth → пам’ять швидко зросла в межах одного інтервалу вибірки. Перевірте останні журнали на великий імпорт, неконтрольований вивід інструмента, повторні спроби або пакет поставлених у чергу завдань агентів.
• Критичний тиск на пам’ять з’являється в журналах, але пакета немає → це типовий режим. Установіть diagnostics.memoryPressureSnapshot: true, щоб збирати пакет стабільності перед OOM для майбутніх подій критичного тиску на пам’ять.

Пакет стабільності не містить payload. Він включає операційні дані про пам’ять і редаговані відносні шляхи файлів, а не текст повідомлень, тіла Webhook, облікові дані, токени, cookies або необроблені ідентифікатори сеансів. Додавайте експорт діагностики до звітів про помилки замість копіювання сирих журналів.

Пов’язане:

• Стан Gateway
• Експорт діагностики
• Сеанси

Gateway відхилив недійсну конфігурацію

Використовуйте це, коли запуск Gateway завершується помилкою Invalid config або журнали гарячого перезавантаження повідомляють, що недійсну зміну пропущено.

openclaw logs --followopenclaw config fileopenclaw config validateopenclaw doctor

Шукайте:

• Invalid config at ...
• config reload skipped (invalid config): ...
• Config write rejected: ...
• Файл із часовою міткою openclaw.json.rejected.* поруч з активною конфігурацією
• Файл із часовою міткою openclaw.json.clobbered.*, якщо doctor --fix виправив пошкоджену пряму зміну
• OpenClaw зберігає останні 32 файли .clobbered.* для кожного шляху конфігурації та ротує старіші

CONFIG="$(openclaw config file)"ls -lt "$CONFIG".clobbered.* "$CONFIG".rejected.* 2>/dev/null | headdiff -u "$CONFIG" "$(ls -t "$CONFIG".clobbered.* 2>/dev/null | head -n 1)"openclaw config validateopenclaw doctor

Пов’язане:

• Конфігурація
• Конфігурація: гаряче перезавантаження
• Конфігурація: сувора перевірка
• Doctor

Попередження probe Gateway

Використовуйте це, коли openclaw gateway probe досягає чогось, але все одно друкує блок попереджень.

openclaw gateway probeopenclaw gateway probe --jsonopenclaw gateway probe --ssh user@gateway-host

Шукайте:

• warnings[].code і primaryTargetId у JSON-виводі.
• Чи попередження стосується резервного SSH, кількох Gateway, відсутніх scopes або нерозв’язаних auth refs.

Типові ознаки:

• SSH tunnel failed to start; falling back to direct probes. → налаштування SSH завершилося помилкою, але команда все одно спробувала прямі налаштовані/loopback цілі.
• multiple reachable gateway identities detected → відповіли різні Gateway або OpenClaw не зміг довести, що доступні цілі є тим самим Gateway. SSH-тунель, proxy URL або налаштований віддалений URL до того самого Gateway вважається одним Gateway із кількома транспортами, навіть коли порти транспортів відрізняються.
• Read-probe diagnostics are limited by gateway scopes (missing operator.read) → підключення спрацювало, але детальний RPC обмежений scope; спарте ідентичність пристрою або використовуйте облікові дані з operator.read.
• Gateway accepted the WebSocket connection, but follow-up read diagnostics failed → підключення спрацювало, але повний набір діагностичних RPC вичерпав час або завершився помилкою. Розглядайте це як доступний Gateway із погіршеною діагностикою; порівняйте connect.ok і connect.rpcOk у виводі --json.
• Capability: pairing-pending або gateway closed (1008): pairing required → Gateway відповів, але цьому клієнту все ще потрібне pairing/approval перед звичайним operator-доступом.
• Нерозв’язаний текст попередження gateway.auth.* / gateway.remote.* SecretRef → auth-матеріал був недоступний у цьому шляху команди для цілі, що завершилася помилкою.

Пов’язане:

• Gateway
• Кілька Gateway на одному хості
• Віддалений доступ

Канал підключено, але повідомлення не проходять

Якщо стан каналу підключений, але потік повідомлень не працює, зосередьтеся на політиці, дозволах і правилах доставлення, специфічних для каналу.

openclaw channels status --probeopenclaw pairing list --channel <channel> [--account <id>]openclaw status --deepopenclaw logs --followopenclaw config get channels

Шукайте:

• Політику DM (pairing, allowlist, open, disabled).
• Allowlist груп і вимоги щодо згадок.
• Відсутні дозволи/scopes API каналу.

Типові ознаки:

• mention required → повідомлення проігноровано політикою згадок у групі.
• Траси pairing / pending approval → відправника не схвалено.
• missing_scope, not_in_channel, Forbidden, 401/403 → проблема auth/дозволів каналу.

Пов’язане:

• Усунення несправностей каналів
• Discord
• Telegram
• WhatsApp

Доставлення Cron і Heartbeat

Якщо Cron або Heartbeat не запустився чи не доставився, спочатку перевірте стан планувальника, а потім ціль доставлення.

openclaw cron statusopenclaw cron listopenclaw cron runs --id <jobId> --limit 20openclaw system heartbeat lastopenclaw logs --follow

Шукайте:

• Cron увімкнено, і наявне наступне пробудження.
• Статус історії запусків завдань (ok, skipped, error).
• Причини пропуску Heartbeat (quiet-hours, requests-in-flight, cron-in-progress, lanes-busy, alerts-disabled, empty-heartbeat-file, no-tasks-due).

Пов’язане:

• Heartbeat
• Заплановані завдання
• Заплановані завдання: усунення несправностей

Node спарено, інструмент не працює

Якщо node спарено, але інструменти не працюють, ізолюйте стан переднього плану, дозволів і схвалень.

openclaw nodes statusopenclaw nodes describe --node <idOrNameOrIp>openclaw approvals get --node <idOrNameOrIp>openclaw logs --followopenclaw status

Шукайте:

• Node онлайн з очікуваними можливостями.
• Надані дозволи ОС для камери/мікрофона/місцезнаходження/екрана.
• Стан схвалень виконання та списку дозволених команд.

Поширені сигнатури:

• NODE_BACKGROUND_UNAVAILABLE → застосунок node має бути на передньому плані.
• *_PERMISSION_REQUIRED / LOCATION_PERMISSION_REQUIRED → бракує дозволу ОС.
• SYSTEM_RUN_DENIED: approval required → очікується схвалення виконання.
• SYSTEM_RUN_DENIED: allowlist miss → команду заблоковано списком дозволених.

Пов’язане:

• Схвалення виконання
• Усунення несправностей Node
• Nodes

Інструмент браузера не працює

Використовуйте це, коли дії інструмента браузера не працюють, хоча сам Gateway справний.

openclaw browser statusopenclaw browser start --browser-profile openclawopenclaw browser profilesopenclaw logs --followopenclaw doctor

Шукайте:

• Чи встановлено plugins.allow і чи містить він browser.
• Дійсний шлях до виконуваного файлу браузера.
• Досяжність профілю CDP.
• Наявність локального Chrome для профілів existing-session / user.

Пов’язане:

• Браузер (керований OpenClaw)
• Усунення несправностей браузера

Якщо ви оновилися, і щось раптово зламалося

Більшість поломок після оновлення спричинені дрейфом конфігурації або суворішими типовими значеннями, які тепер застосовуються.

openclaw gateway statusopenclaw config get gateway.modeopenclaw config get gateway.remote.urlopenclaw config get gateway.auth.mode

openclaw config get gateway.bindopenclaw config get gateway.auth.modeopenclaw config get gateway.auth.tokenopenclaw gateway statusopenclaw logs --follow

openclaw devices listopenclaw pairing list --channel <channel> [--account <id>]openclaw logs --followopenclaw doctor

Якщо конфігурація сервісу та runtime все ще не збігаються після перевірок, перевстановіть метадані сервісу з того самого каталогу профілю/стану:

openclaw gateway install --forceopenclaw gateway restart

Пов’язане:

• Автентифікація
• Фонове виконання та інструмент процесів
• Спарювання, яким керує Gateway

Пов’язане

• Doctor
• FAQ
• Runbook Gateway