O relay de navegador do OpenClaw

Seu agente consegue buscar uma página, mas buscar não é o mesmo que usar. A aba que importa já está com login feito, fica em um notebook em outro cômodo, e o Gateway roda em um servidor em um lugar completamente diferente. A resposta do OpenClaw é retransmitir as ações do navegador para a máquina onde o navegador realmente está e, depois, mantê-las lá.

Quatro lugares onde o navegador pode ficar

• Controle local, o padrão. O Gateway inicia o serviço de controle em loopback e pode abrir um navegador local. Ações sem alvo, como open, navigate ou openclaw browser start, podem iniciá-lo; uma ação que identifica uma aba por targetId, ID de aba ou rótulo nunca inicia um navegador parado, porque um navegador recém-aberto não pode conter essa aba.
• Controle remoto por um node host. Você roda um node host na máquina que tem o navegador, e o Gateway faz proxy das ações do navegador para ele. O nó expõe o próprio servidor local de controle do navegador por meio de um comando de proxy, então o Gateway nunca precisa do binário do navegador.
• CDP remoto. Defina a chave cdpUrl no seu perfil em browser.profiles, ou o antigo browser.cdpUrl de perfil único, para se conectar a um navegador remoto baseado em Chromium. Nesse caso, o OpenClaw não abre um navegador local próprio.
• Serviços em loopback attach-only. Para um serviço CDP gerenciado externamente e publicado em 127.0.0.1 (o Browserless no Docker é o caso comum), defina também attachOnly: true. Um CDP em loopback sem attachOnly é tratado como um perfil local gerenciado pelo OpenClaw, e o OpenClaw pode informar que a porta está em uso, mas não pertence ao OpenClaw.

Depois que uma ação chega ao nó, o snapshot ou as configurações seguintes ficam nesse nó, em vez de trocar de navegador.

O roteamento é decidido uma vez, e não por ação

O roteamento automático prefere o host, incluindo um navegador gerenciado parado cujo executável apenas está instalado. Um target node explícito, um seletor de nó ou gateway.nodes.browser.node substitui essa preferência, enquanto target=host sempre fica no host. O dono selecionado, seja qual for, fica então com tudo: conexões existing-session, extension, attach-only e de CDP remoto pertencem a ele mesmo quando não há nenhum executável de navegador gerenciado, e falhas de inicialização, configurações de executável inválidas, erros de permissão e falhas de ação na página ficam nesse dono, em vez de serem repetidas em outra máquina. O fallback automático para o host a partir de um nó selecionado só é permitido antes que esse nó tenha atendido uma requisição, que é a frase acima na prática. É isso que torna coerente uma tarefa de navegador em várias etapas: o snapshot sobre o qual você age e as refs de elementos que ele devolveu descrevem um navegador, e não dois.

Limites que o relay mantém

• Os perfis vêm da própria configuração browser.profiles do nó, exatamente como se você estivesse sentado diante daquela máquina. O Gateway não projeta a própria lista de perfis no nó.
• Mutações persistentes de perfil são recusadas pelo comando de proxy, não importa como ele esteja configurado: create-profile, delete-profile e reset-profile ficam bloqueados independentemente de allowProfiles. Faça essas alterações diretamente no nó.
• nodeHost.browserProxy.allowProfiles é opcional. Se ficar vazio, todos os perfis configurados continuam acessíveis pelo proxy, que é o comportamento padrão legado. Se você o definir, o OpenClaw o trata como uma fronteira de privilégio mínimo que limita quais nomes de perfil o proxy vai atingir. Para desligar o caminho inteiro, use nodeHost.browserProxy.enabled=false no nó ou gateway.nodes.browser.mode=off no Gateway, que também aceita auto e manual.

O agente vê uma única ferramenta para os quatro arranjos: uma ferramenta browser que cobre doctor, status, start, stop, tabs, open, focus, close, snapshot, screenshot, navigate, act, requests, errors, text e emulate, com um argumento profile para escolher o navegador e um argumento target com sandbox, host ou node para escolher a máquina. O mesmo verbo pode significar coisas diferentes em cada modo. Stop em um perfil local gerenciado encerra o processo que o OpenClaw iniciou, enquanto em perfis attach-only e de CDP remoto ele fecha a sessão de controle ativa e libera as substituições de emulação do Playwright e do CDP para viewport, esquema de cores, localidade, fuso horário e modo offline, mesmo que o OpenClaw nunca tenha iniciado um processo de navegador ali. A configuração headless segue a mesma regra, já que só afeta perfis locais gerenciados que o OpenClaw inicia. A lista completa de ações e argumentos está nas ações da ferramenta browser, e o que um node host realmente é, como ele é pareado e o que mais ele pode carregar está nos nós de navegador.

Navegadores hospedados e os três formatos de URL

O OpenClaw aceita três formatos de URL de CDP e escolhe automaticamente a estratégia de conexão para cada um. Uma base http:// ou https:// significa descoberta: o OpenClaw chama /json/version, lê a URL do depurador WebSocket e se conecta, sem fallback de WebSocket. Um endpoint direto ws:// ou wss:// com um caminho /devtools/browser, page, worker, shared_worker ou service_worker pula /json/version por completo. Uma raiz WebSocket simples, sem caminho /devtools, que é o que o Browserless e o Browserbase entregam, tenta primeiro a descoberta HTTP e recorre a um handshake direto na raiz se a descoberta não devolver nada utilizável. Essas URLs costumam carregar a autorização como um token na query ou como credenciais HTTP Basic, e o OpenClaw preserva essa autenticação tanto ao chamar os endpoints /json/* quanto ao abrir o WebSocket do CDP; então trate a URL inteira como um segredo e mantenha-a em uma variável de ambiente ou em um gerenciador de segredos, e não em um arquivo de configuração. O diagnóstico usa a mesma lógica de descoberta primeiro e fallback de WebSocket de um attach em tempo de execução, então uma raiz simples que conecta não é informada como inacessível pela API de controle do navegador. O único modo de navegador com login feito que não tem nenhum cdpUrl é o relay da extensão do Chrome, cujo relay controla o próprio endpoint de loopback e comanda abas reais sem ninguém diante do computador.

Na Diali

A Diali hospeda o OpenClaw como serviço gerenciado. Cada cliente recebe o próprio assistente, no próprio runtime, em vez de um lugar em um pool compartilhado. A configuração do runtime é gerada a partir do seu painel e reescrita a cada versão, então o bloco browser que você define na interface é aquele com que o agente inicia. Tudo o que o agente guarda fica em um volume persistente, com snapshots diários e restauração com um clique disponíveis pelo complemento Backups (incluído no Max). O OpenClaw hospedado na Diali descreve o runtime hospedado, e a página de preços da Diali lista os planos.

• Um node host retransmite as ações do navegador para a máquina dona do navegador.
• Depois que uma ação chega a um nó, o resto da tarefa fica lá.
• attachOnly impede que um serviço CDP em loopback seja confundido com um perfil gerenciado.