Pular para o conteúdo
Guias

Failed to start Chrome CDP on port 18800

Por que o Chromium snap quebra o controle do navegador do OpenClaw no Linux

7 min de leitura

Você pede ao agente para abrir uma página e a chamada de ferramenta volta com uma única linha de JSON: Failed to start Chrome CDP on port 18800 for profile openclaw. Nada nessa mensagem diz qual parte falhou, e em uma máquina Linux headless o navegador nunca chega a aparecer. A causa habitual não é o OpenClaw, é o navegador que o apt instalou para você.

Quatro mensagens de erro, quatro causas diferentes

  • Failed to start Chrome CDP on port 18800 for profile openclaw é o perfil gerenciado não conseguindo subir na sua porta de depuração. No Ubuntu, o motivo habitual é que o Chromium da máquina é um wrapper snap, e não um binário de navegador de verdade.
  • The profile appears to be in use by another Chromium process aponta para arquivos de lock Singleton obsoletos no diretório do perfil gerenciado. O OpenClaw remove esses locks e tenta de novo uma vez quando o lock indica um processo morto no host atual, mas locks que indicam outro nome de host são preservados até você confirmar que o perfil não está mais em uso, inclusive depois de renomear a máquina.
  • Missing X server or $DISPLAY significa que um navegador visível foi pedido explicitamente em um host sem sessão de área de trabalho. Os perfis gerenciados locais já recorrem ao modo headless no Linux quando DISPLAY e WAYLAND_DISPLAY estão ambos indefinidos, então ver esse erro significa que algo forçou um navegador com interface gráfica: OPENCLAW_BROWSER_HEADLESS=0, browser.headless definido como false ou a mesma chave em um único perfil.
  • O erro Port N is in use for profile NAME but not by openclaw aparece quando um serviço CDP externo em loopback já está configurado e attachOnly continua em false. A correção é parar de pedir ao OpenClaw que inicie o próprio navegador, que é o caminho attach-only descrito abaixo.
O confinamento AppArmor do snap interfere na forma como o OpenClaw inicia e monitora o processo do navegador.

Por que apt install chromium é a causa raiz

No Ubuntu e na maioria das distribuições Linux, apt install chromium não entrega um navegador. O pacote é resolvido para chromium-browser, o apt exibe um aviso de que selecionou chromium-browser em vez de chromium, e o que chega ao disco é um wrapper snap. Isso importa porque, quando o OpenClaw inicia um navegador localmente, ele pega o primeiro que encontra na ordem Chrome, Brave, Edge, Chromium, Chrome Canary, e o caminho de busca dele no Linux cobre /usr/bin, /snap/bin, /opt/google, /opt/brave.com, /usr/lib/chromium e /usr/lib/chromium-browser, além do Chromium gerenciado pelo Playwright em PLAYWRIGHT_BROWSERS_PATH ou ~/.cache/ms-playwright. Em um servidor novo em que o snap é o único binário da família Chromium presente, a detecção o encontra e toda inicialização gerenciada morre nele. Nenhuma combinação de flags resolve isso, e é por isso que a resposta documentada é um binário diferente, e não uma configuração diferente.

Três passos que resolvem

  • Instale o Google Chrome de verdade, que é a correção recomendada. Baixe google-chrome-stable_current_amd64.deb de dl.google.com, instale com dpkg -i e rode sudo apt --fix-broken install -y se as dependências reclamarem. Depois defina browser.executablePath como /usr/bin/google-chrome-stable em ~/.openclaw/openclaw.json, com enabled, headless e noSandbox todos em true.
  • Se o Chromium snap precisar ficar, use o modo attach-only. Defina browser.attachOnly como true para que o OpenClaw nunca inicie nada, e inicie você mesmo o navegador com chromium-browser --headless --no-sandbox --disable-gpu --remote-debugging-port=18800 --user-data-dir=$HOME/.openclaw/browser/openclaw/user-data about:blank.
  • Faça esse navegador manual sobreviver ao seu shell com um serviço systemd de usuário. Uma unidade em ~/.config/systemd/user/openclaw-browser.service que roda /snap/bin/chromium com as mesmas flags, mais Restart=on-failure e RestartSec=5, habilitada com systemctl --user enable --now openclaw-browser.service, deixa a porta CDP escutando antes de o OpenClaw pedir por ela.

A superfície de configuração se resume a seis opções, e os padrões servem para um notebook, não para um servidor. browser.enabled ativa o controle do navegador e já vem como true. browser.executablePath é o caminho para um binário baseado em Chromium (Chrome, Brave, Edge ou Chromium), detectado automaticamente quando você o omite, com preferência pelo navegador padrão do sistema quando ele é baseado em Chromium. browser.headless roda sem interface gráfica e tem false como padrão, então um servidor precisa defini-lo explicitamente, com OPENCLAW_BROWSER_HEADLESS disponível como substituição por processo, indefinida por padrão. browser.noSandbox adiciona a flag --no-sandbox de que algumas instalações Linux precisam, padrão false, e browser.attachOnly impede o OpenClaw de iniciar qualquer navegador, padrão false. O attach-only também é a resposta documentada em um Raspberry Pi, em um host VPS mais antigo ou em armazenamento lento, quando o Chrome precisa de mais tempo para expor o endpoint HTTP do CDP do que o prazo do navegador gerenciado permite. OpenClaw no Linux cobre a instalação no Linux em geral, e OpenClaw em uma VPS é a checklist para um servidor sem ninguém na frente dele.

Falha de inicialização do CDP ou bloqueio de navegação

Com o navegador configurado, verifique-o antes de procurar em qualquer outro lugar. Essas verificações vão para o serviço de controle do navegador do OpenClaw, e não para a porta CDP do Chrome usada na inicialização, e a porta dele é derivada de gateway.port: 18791 por padrão, a porta do gateway mais dois, então ajuste-a se você mudou o Gateway de porta. Peça o caminho raiz com curl e você recebe running, pid e chosenBrowser; faça um POST em /start; depois um GET em /tabs. Agora rode a sequência de verificações que separa as duas classes de falha: openclaw browser --browser-profile openclaw start, depois tabs, depois open https://example.com. Se start falhar com not reachable after start, o plano de controle não está saudável e é a prontidão do CDP que você deve investigar. Se start funcionar e tabs falhar, ainda é um problema de alcançabilidade, não um problema da página. Se start e tabs passarem e só open ou navigate falhar, o navegador está saudável e você está diante da política de navegação ou da própria página, que é um caminho de código separado: a configuração do navegador usa por padrão um objeto de política SSRF fail-closed mesmo quando você nunca escreveu browser.ssrfPolicy, e um start ou tabs bem-sucedido não concede nada para o próximo endereço. Quando uma exceção for necessária, uma entrada estreita com o nome de host exato em allowedHostnames é melhor do que abrir a rede privada, e dangerouslyAllowPrivateNetwork só cabe em um ambiente que você revisou de propósito. A ferramenta de navegador do OpenClaw é a ferramenta que o agente realmente chama, e a API de controle do navegador é a referência completa da API de controle e da linha de comando.

Na Diali

A Diali hospeda o OpenClaw, então você não passa por essa noite. Cada cliente roda o próprio assistente, e não uma fatia de um assistente compartilhado, e a configuração de execução é gerada a partir do que você define no painel e reescrita a cada nova versão, então não há openclaw.json em um servidor para consertar depois de uma atualização, nem decisão entre snap e deb a tomar. Tudo o que o assistente guarda fica em um volume persistente, com snapshots diários e restauração com um clique disponíveis pelo complemento Backups (incluído no plano Max). OpenClaw hospedado na Diali descreve a configuração hospedada e a página de preços da Diali mostra quanto custa.

  • apt install chromium entrega um wrapper snap, não um navegador.
  • Chrome de verdade primeiro; attach-only com uma unidade systemd em segundo lugar.
  • start e tabs passam, mas open falha: é política, não CDP.
Começar

Pare de ler sobre isso e crie o seu

Configure um agente, escolha um canal e coloque-o para trabalhar dentro do app que você já deixa aberto.