Solução de problemas

Esta página é o runbook detalhado. Comece em /help/troubleshooting se quiser primeiro o fluxo rápido de triagem.

Sequência de comandos

Execute estes primeiro, nesta ordem:

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

Sinais esperados de integridade:

• openclaw gateway status mostra Runtime: running, Connectivity probe: ok e uma linha Capability: ....
• openclaw doctor não relata problemas bloqueantes de configuração/serviço.
• openclaw channels status --probe mostra o status de transporte ativo por conta e, quando houver suporte, resultados de sondagem/auditoria como works ou audit ok.

Depois de uma atualização

Use isto quando uma atualização termina, mas o Gateway está fora do ar, os canais estão vazios ou as chamadas de modelo começam a falhar com 401.

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

Procure por:

• Update restart em openclaw status / openclaw status --all. Transferências pendentes ou com falha incluem o próximo comando a executar.
• plugin load failed: dependency tree corrupted; run openclaw doctor --fix em Channels. Isso significa que a configuração do canal ainda existe, mas o registro do plugin falhou antes que o canal pudesse ser carregado.
• 401s do provedor após nova autenticação. openclaw doctor --fix verifica sombras antigas de autenticação OAuth por agente e remove as cópias antigas para que todos os agentes resolvam o perfil compartilhado atual.

Instalações split brain e proteção de configuração mais nova

Use isto quando um serviço de gateway para inesperadamente após uma atualização, ou os logs mostram que um binário openclaw é mais antigo que a versão que gravou openclaw.json pela última vez.

O OpenClaw marca gravações de configuração com meta.lastTouchedVersion. Comandos somente leitura ainda podem inspecionar uma configuração gravada por um OpenClaw mais novo, mas mutações de processo e serviço se recusam a continuar a partir de um binário mais antigo. Ações bloqueadas incluem iniciar, parar, reiniciar e desinstalar o serviço do gateway, reinstalação forçada do serviço, inicialização do gateway em modo de serviço e limpeza de porta com gateway --force.

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

openclaw gateway install --forceopenclaw gateway restart

Incompatibilidade de protocolo após rollback

Use isto quando os logs continuam imprimindo protocol mismatch depois que você faz downgrade ou rollback do OpenClaw. Isso significa que um Gateway mais antigo está em execução, mas um processo de cliente local mais novo ainda está tentando se reconectar com um intervalo de protocolo que o Gateway mais antigo não consegue falar.

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

Procure por:

• protocol mismatch ... client=... v<version> min=<n> max=<n> expected=<n> nos logs do Gateway.
• Established clients: em openclaw gateway status --deep ou Gateway clients em openclaw doctor --deep. Isso lista clientes TCP ativos conectados à porta do Gateway, incluindo PIDs e linhas de comando quando o SO permite.
• Um processo de cliente cuja linha de comando aponta para a instalação ou wrapper mais novo do OpenClaw do qual você fez rollback.

Correção:

1. Pare ou reinicie o processo de cliente OpenClaw obsoleto mostrado por gateway status --deep.
2. Reinicie apps ou wrappers que incorporam o OpenClaw, como dashboards locais, editores, auxiliares de app-server ou shells openclaw logs --follow de longa duração.
3. Execute novamente openclaw gateway status --deep ou openclaw doctor --deep e confirme que o PID do cliente obsoleto desapareceu.

Não faça um Gateway mais antigo aceitar um protocolo incompatível mais novo. Aumentos de protocolo protegem o contrato de comunicação; a recuperação de rollback é um problema de limpeza de processo/versão.

Symlink de Skill ignorado como escape de caminho

Use isto quando os logs incluírem:

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

O OpenClaw trata cada raiz de skill como um limite de contenção. Um symlink em ~/.agents/skills, <workspace>/.agents/skills, <workspace>/skills ou ~/.openclaw/skills é ignorado quando seu alvo real resolve para fora dessa raiz, a menos que o alvo seja explicitamente confiável.

Inspecione o link:

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

Se o alvo for intencional, configure tanto a raiz direta da skill quanto o alvo de symlink permitido:

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

Em seguida, inicie uma nova sessão ou aguarde o watcher de skills atualizar. Reinicie o gateway se o processo em execução for anterior à alteração de configuração.

Não use alvos amplos como ~, / ou uma pasta inteira de projeto sincronizado. Mantenha allowSymlinkTargets restrito à raiz real de skills que contém diretórios SKILL.md confiáveis.

Se o apply do Skill Workshop também deve gravar por esses caminhos de skill de workspace com symlink confiável, habilite skills.workshop.allowSymlinkTargetWrites. Mantenha-o desabilitado para raízes de skills compartilhadas somente leitura.

Relacionado:

• Configuração de Skills
• Exemplos de configuração

Anthropic 429 exige uso extra para contexto longo

Use isto quando logs/erros incluírem: HTTP 429: rate_limit_error: Extra usage is required for long context requests.

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

Procure por:

• O modelo Anthropic selecionado é um modelo Claude 4.x de 1M com capacidade GA, ou o modelo tem params.context1m: true legado.
• A credencial Anthropic atual não é qualificada para uso de contexto longo.
• As solicitações falham apenas em sessões/execuções de modelo longas que precisam do caminho de contexto de 1M.

Opções de correção:

Relacionado:

• Anthropic
• Uso de tokens e custos
• Por que estou vendo HTTP 429 da Anthropic?

Respostas upstream 403 bloqueadas

Use isto quando um provedor LLM upstream retornar um 403 genérico, como Your request was blocked.

Não presuma que isso é sempre um problema de configuração do OpenClaw. A resposta pode vir de uma camada de segurança upstream, como CDN, WAF, regra de gerenciamento de bots ou proxy reverso na frente de um endpoint compatível com OpenAI.

openclaw statusopenclaw gateway statusopenclaw logs --follow

Procure por:

• vários modelos sob o mesmo provedor falhando da mesma forma
• HTML ou texto genérico de segurança em vez de um erro normal de API do provedor
• eventos de segurança do lado do provedor no mesmo horário da solicitação
• uma pequena sondagem direta com curl tendo sucesso enquanto solicitações normais no formato do SDK falham

Corrija primeiro a filtragem do lado do provedor quando as evidências apontarem para um bloqueio de WAF/CDN. Prefira uma regra de permissão ou exceção com escopo estreito para o caminho de API que o OpenClaw usa, e evite desabilitar a proteção para o site inteiro.

Relacionado:

• Endpoints compatíveis com OpenAI
• Configuração de provedor
• Logs

Backend local compatível com OpenAI passa em sondagens diretas, mas execuções de agente falham

Use isto quando:

• curl ... /v1/models funciona
• chamadas diretas pequenas para /v1/chat/completions funcionam
• execuções de modelo do OpenClaw falham apenas em turnos normais de agente

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

Procure por:

• chamadas diretas pequenas têm sucesso, mas execuções do OpenClaw falham apenas em prompts maiores
• erros model_not_found ou 404 mesmo que /v1/chat/completions direto funcione com o mesmo id de modelo simples
• erros do backend sobre messages[].content esperando uma string
• avisos intermitentes incomplete turn detected ... stopReason=stop payloads=0 com um backend local compatível com OpenAI
• falhas do backend que aparecem apenas com contagens maiores de tokens de prompt ou prompts completos de runtime de agente

Relacionado:

• Configuração
• Modelos locais
• Endpoints compatíveis com OpenAI

Sem respostas

Se os canais estiverem ativos, mas nada responder, verifique o roteamento e a política antes de reconectar qualquer coisa.

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

Procure por:

• Pareamento pendente para remetentes de DM.
• Bloqueio por menção em grupo (requireMention, mentionPatterns).
• Incompatibilidades de allowlist de canal/grupo.

Assinaturas comuns:

• drop guild message (mention required → mensagem de grupo ignorada até haver menção.
• pairing request → o remetente precisa de aprovação.
• blocked / allowlist → o remetente/canal foi filtrado pela política.

Relacionado:

• Solução de problemas de canais
• Grupos
• Pareamento

Conectividade da IU de controle do painel

Quando o painel/IU de controle não conectar, valide a URL, o modo de autenticação e as premissas de contexto seguro.

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

Procure por:

• URL de probe e URL do painel corretas.
• Incompatibilidade de modo/token de autenticação entre cliente e Gateway.
• Uso de HTTP onde identidade do dispositivo é necessária.

Se um navegador local não conseguir conectar a 127.0.0.1:18789 após uma atualização, primeiro recupere o serviço local do Gateway e confirme que ele está servindo o painel:

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

Se curl retornar HTML do OpenClaw, o Gateway está funcionando e o problema restante provavelmente é cache do navegador, um link profundo antigo ou estado obsoleto de aba. Abra http://127.0.0.1:18789 diretamente e navegue a partir do painel. Se a reinicialização não deixar o serviço em execução, execute openclaw gateway start e verifique novamente openclaw gateway status.

Mapa rápido de códigos de detalhe de autenticação

Use error.details.code da resposta connect com falha para escolher a próxima ação:

Verificação de migração de autenticação de dispositivo v2:

openclaw --versionopenclaw doctoropenclaw gateway status

Se os logs mostrarem erros de nonce/assinatura, atualize o cliente que está conectando e verifique:

Se openclaw devices rotate / revoke / remove for negado inesperadamente:

• sessões de token de dispositivo pareado podem gerenciar apenas seu próprio dispositivo, a menos que o chamador também tenha operator.admin
• openclaw devices rotate --scope ... só pode solicitar escopos de operador que a sessão do chamador já possui

Relacionado:

• Configuração (modos de autenticação do Gateway)
• IU de controle
• Dispositivos
• Acesso remoto
• Autenticação de proxy confiável

Serviço do Gateway não está em execução

Use isto quando o serviço estiver instalado, mas o processo não permanecer ativo.

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

Procure por:

• Runtime: stopped com dicas de saída.
• Incompatibilidade de configuração de serviço (Config (cli) vs Config (service)).
• Conflitos de porta/listener.
• Instalações extras de launchd/systemd/schtasks quando --deep é usado.
• Dicas de limpeza de Other gateway-like services detected (best effort).

Relacionado:

• Execução em segundo plano e ferramenta de processo
• Configuração
• Doctor

Gateway do macOS para de responder silenciosamente e depois retoma quando você toca no painel

Use isto quando canais (Telegram, WhatsApp etc.) em um host macOS ficam silenciosos por minutos a horas de cada vez, e o Gateway parece voltar no momento em que você abre a IU de controle, acessa via SSH ou interage de outra forma com o host. Normalmente não há sintoma óbvio em openclaw status porque, quando você verifica, o Gateway já está ativo novamente.

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"

Procure por:

• Um ou mais pacotes *-uncaught_exception.json em ~/.openclaw/logs/stability/ com error.code definido como um código de rede transitório, como ENETDOWN, ENETUNREACH, EHOSTUNREACH ou ECONNREFUSED.
• Linhas de pmset -g log como Entering Sleep state due to 'Maintenance Sleep' ou en0 driver is slow (msg: WillChangeState to 0) alinhadas com os carimbos de data/hora da falha. Power Nap / Maintenance Sleep coloca brevemente o driver de Wi-Fi no estado 0; qualquer connect() de saída que caia nessa janela pode falhar com ENETDOWN, mesmo em um host que, de outra forma, tem conectividade de rede completa.
• Saída de launchctl print mostrando state = not running com várias runs recentes e um código de saída, especialmente quando o intervalo entre a falha e a próxima inicialização é da ordem de uma hora, em vez de segundos. O launchd do macOS aplica uma barreira de proteção de respawn não documentada após uma rajada de falhas que pode parar de honrar KeepAlive=true até que um gatilho externo, como login interativo, conexão do dashboard ou launchctl kickstart, a rearme.

Assinaturas comuns:

• Um pacote de estabilidade cujo error.code é ENETDOWN ou um código semelhante, com a pilha de chamadas apontando para Node net lookupAndConnect / Socket.connect. O OpenClaw 2026.5.26 e versões mais recentes classificam isso como erros de rede transitórios benignos, então eles não são mais propagados para o manipulador de exceções não capturadas de nível superior; se você estiver em uma versão mais antiga, atualize primeiro.
• Longos períodos silenciosos que terminam no instante em que você se conecta à Control UI ou acessa o host por SSH: a atividade visível para o usuário é o que rearma a barreira de respawn do launchd, não algo que o dashboard faz com o Gateway.
• Contagem de runs aumentando ao longo do dia sem uma linha correspondente received SIG*; shutting down em ~/Library/Logs/openclaw/gateway.log: desligamentos limpos registram um sinal; falhas transitórias não.

O que fazer:

1. Atualize o Gateway se você estiver executando uma versão anterior a 2026.5.26. Após a atualização, erros futuros ENETDOWN serão registrados como avisos, em vez de encerrar o processo.

2. Reduza a atividade de manutenção durante o repouso em hosts Mac mini / desktop destinados a funcionar como servidores sempre ativos:

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

   Isso reduz significativamente, mas não elimina por completo, a oscilação subjacente do driver. O sistema ainda pode executar alguns repousos de manutenção para TCP keepalive e manutenção de mDNS, independentemente dessas flags.

3. Adicione um watchdog de vivacidade para que uma futura rajada de falhas estacionada pelo launchd seja detectada rapidamente:

   # 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

   O objetivo é rearmar externamente a barreira de respawn; KeepAlive=true sozinho não é suficiente no macOS após uma rajada de falhas.

Relacionado:

• Notas da plataforma macOS
• Registro de logs
• Doctor

Gateway sai durante alto uso de memória

Use isto quando o Gateway desaparecer sob carga, o supervisor relatar uma reinicialização no estilo OOM, ou os logs mencionarem critical memory pressure bundle written.

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

Procure por:

• Reason: diagnostic.memory.pressure.critical no pacote de estabilidade mais recente.
• Memory pressure: com critical/rss_threshold, critical/heap_threshold ou critical/rss_growth.
• Valores de V8 heap: próximos ao limite de heap.
• Entradas de Largest session files:, como agents/<agent>/sessions/<session>.jsonl ou sessions/<session>.jsonl.
• Contadores de memória de cgroup do Linux quando o Gateway é executado dentro de um contêiner ou serviço com limite de memória.

Assinaturas comuns:

• critical memory pressure bundle written aparece pouco antes da reinicialização → o OpenClaw capturou um pacote de estabilidade pré-OOM. Inspecione-o com openclaw gateway stability --bundle latest.
• memory pressure: level=critical ... memoryPressureSnapshot=disabled aparece nos logs do Gateway → o OpenClaw detectou pressão de memória crítica, mas o snapshot de estabilidade pré-OOM está desativado.
• Largest session files: aponta para um caminho de transcrição redigida muito grande → reduza o histórico de sessões retido, inspecione o crescimento da sessão ou mova transcrições antigas para fora do armazenamento ativo antes de reiniciar.
• Bytes usados de V8 heap: estão próximos ao limite de heap → reduza a pressão de prompts/sessões, reduza o trabalho concorrente ou aumente o limite de heap do Node somente após confirmar que a carga de trabalho é esperada.
• Memory pressure: critical/rss_growth → a memória cresceu rapidamente dentro de uma janela de amostragem. Verifique os logs mais recentes em busca de uma importação grande, saída de ferramenta descontrolada, novas tentativas repetidas ou um lote de trabalho de agentes enfileirado.
• Pressão de memória crítica aparece nos logs, mas não existe pacote → esse é o padrão. Defina diagnostics.memoryPressureSnapshot: true para capturar o pacote de estabilidade pré-OOM em eventos futuros de pressão de memória crítica.

O pacote de estabilidade não contém payloads. Ele inclui evidências operacionais de memória e caminhos relativos de arquivos redigidos, não texto de mensagens, corpos de webhook, credenciais, tokens, cookies ou ids brutos de sessão. Anexe a exportação de diagnósticos a relatórios de bug em vez de copiar logs brutos.

Relacionado:

• Saúde do Gateway
• Exportação de diagnósticos
• Sessões

Gateway rejeitou configuração inválida

Use isto quando a inicialização do Gateway falhar com Invalid config ou os logs de hot reload disserem que uma edição inválida foi ignorada.

openclaw logs --followopenclaw config fileopenclaw config validateopenclaw doctor

Procure por:

• Invalid config at ...
• config reload skipped (invalid config): ...
• Config write rejected: ...
• Um arquivo openclaw.json.rejected.* com carimbo de data/hora ao lado da configuração ativa
• Um arquivo openclaw.json.clobbered.* com carimbo de data/hora se doctor --fix reparou uma edição direta quebrada
• O OpenClaw mantém os 32 arquivos .clobbered.* mais recentes para cada caminho de configuração e alterna os mais antigos

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

Relacionado:

• Configuração
• Configuração: hot reload
• Configuração: validação estrita
• Doctor

Avisos de probe do Gateway

Use isto quando openclaw gateway probe alcançar algo, mas ainda imprimir um bloco de aviso.

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

Procure por:

• warnings[].code e primaryTargetId na saída JSON.
• Se o aviso é sobre fallback de SSH, múltiplos gateways, escopos ausentes ou referências de autenticação não resolvidas.

Assinaturas comuns:

• SSH tunnel failed to start; falling back to direct probes. → a configuração de SSH falhou, mas o comando ainda tentou alvos diretos configurados/de loopback.
• multiple reachable gateway identities detected → gateways distintos responderam, ou o OpenClaw não conseguiu provar que os alvos alcançáveis são o mesmo Gateway. Um túnel SSH, URL de proxy ou URL remota configurada para o mesmo Gateway é tratado como um Gateway com vários transportes, mesmo quando as portas de transporte diferem.
• Read-probe diagnostics are limited by gateway scopes (missing operator.read) → a conexão funcionou, mas o RPC de detalhes é limitado por escopo; emparelhe a identidade do dispositivo ou use credenciais com operator.read.
• Gateway accepted the WebSocket connection, but follow-up read diagnostics failed → a conexão funcionou, mas o conjunto completo de RPCs de diagnóstico atingiu timeout ou falhou. Trate isso como um Gateway alcançável com diagnósticos degradados; compare connect.ok e connect.rpcOk na saída de --json.
• Capability: pairing-pending ou gateway closed (1008): pairing required → o Gateway respondeu, mas este cliente ainda precisa de emparelhamento/aprovação antes do acesso normal de operador.
• texto de aviso de SecretRef gateway.auth.* / gateway.remote.* não resolvido → o material de autenticação estava indisponível neste caminho de comando para o alvo com falha.

Relacionado:

• Gateway
• Múltiplos gateways no mesmo host
• Acesso remoto

Canal conectado, mensagens não fluem

Se o estado do canal está conectado, mas o fluxo de mensagens está parado, concentre-se em política, permissões e regras de entrega específicas do canal.

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

Procure por:

• Política de DM (pairing, allowlist, open, disabled).
• Allowlist de grupo e requisitos de menção.
• Permissões/escopos ausentes da API do canal.

Assinaturas comuns:

• mention required → mensagem ignorada pela política de menção do grupo.
• Rastros de pairing / aprovação pendente → o remetente não está aprovado.
• missing_scope, not_in_channel, Forbidden, 401/403 → problema de autenticação/permissões do canal.

Relacionado:

• Solução de problemas de canais
• Discord
• Telegram
• WhatsApp

Entrega de Cron e Heartbeat

Se Cron ou Heartbeat não executou ou não entregou, verifique primeiro o estado do agendador e depois o alvo de entrega.

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

Procure por:

• Cron habilitado e próximo despertar presente.
• Status do histórico de execução do job (ok, skipped, error).
• Motivos de pular Heartbeat (quiet-hours, requests-in-flight, cron-in-progress, lanes-busy, alerts-disabled, empty-heartbeat-file, no-tasks-due).

Relacionado:

• Heartbeat
• Tarefas agendadas
• Tarefas agendadas: solução de problemas

Nó pareado, ferramenta falha

Se um nó estiver pareado, mas as ferramentas falharem, isole o estado de primeiro plano, permissão e aprovação.

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

Procure por:

• Nó online com as capacidades esperadas.
• Concessões de permissão do SO para câmera/microfone/localização/tela.
• Aprovações de exec e estado da lista de permissões.

Assinaturas comuns:

• NODE_BACKGROUND_UNAVAILABLE → o app do nó deve estar em primeiro plano.
• *_PERMISSION_REQUIRED / LOCATION_PERMISSION_REQUIRED → permissão do SO ausente.
• SYSTEM_RUN_DENIED: approval required → aprovação de exec pendente.
• SYSTEM_RUN_DENIED: allowlist miss → comando bloqueado pela lista de permissões.

Relacionado:

• Aprovações de exec
• Solução de problemas de nós
• Nós

Ferramenta de navegador falha

Use isto quando as ações da ferramenta de navegador falharem, mesmo que o Gateway em si esteja íntegro.

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

Procure por:

• Se plugins.allow está definido e inclui browser.
• Caminho válido do executável do navegador.
• Acessibilidade do perfil CDP.
• Disponibilidade local do Chrome para perfis existing-session / user.

Relacionado:

• Navegador (gerenciado pelo OpenClaw)
• Solução de problemas de navegador

Se você atualizou e algo quebrou de repente

A maioria das quebras pós-atualização é desvio de configuração ou padrões mais rígidos sendo aplicados agora.

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

Se a configuração do serviço e o runtime ainda divergirem após as verificações, reinstale os metadados do serviço a partir do mesmo diretório de perfil/estado:

openclaw gateway install --forceopenclaw gateway restart

Relacionado:

• Autenticação
• Exec em segundo plano e ferramenta de processo
• Pareamento de propriedade do Gateway

Relacionado

• Doctor
• FAQ
• Runbook do Gateway