Skip to main content
A tool @browser controla um Chrome/Chromium local de verdade para que o agente possa ver e interagir com páginas web como uma pessoa faria: abrir uma URL, ler a página renderizada como texto, clicar e digitar em elementos, rodar JavaScript, capturar screenshots e inspecionar a atividade de console e rede da página. É o loop de verificação para trabalho web — o agente constrói ou altera um frontend, então realmente olha para ele e o depura a partir do que a página registrou e requisitou, em vez de adivinhar pelo código-fonte.
O @browser fala o Chrome DevTools Protocol (CDP) diretamente sobre o cliente websocket que o ChatCLI já embarca — zero dependência nova, sem driver, sem runtime baixado, sem chave de API. Só precisa de um navegador da família Chromium instalado localmente (Google Chrome, Chromium, Brave ou Edge).

Como funciona

  1. Início preguiçoso — o primeiro open inicia um navegador; todo comando seguinte reaproveita essa sessão única com estado.
  2. CDP sobre websocket — navegação, leitura do DOM, screenshots e captura de eventos fluem pelo websocket do DevTools. Sem Selenium/Playwright, sem binário externo.
  3. Snapshot como texto — a página é renderizada em texto amigável ao modelo, com cada elemento interativo marcado e numerado para o agente endereçá-los com precisão.
  4. Captura contínua — mensagens de console (incluindo erros) e respostas de rede são capturadas em rings limitados, então você pode perguntar “o que a página registrou?” depois do fato.
  5. Morre com a sessão — um navegador headless nunca sobrevive ao ChatCLI; é fechado no encerramento do CLI (ou explicitamente com close).

Subcomandos

Invoque com um envelope JSON {cmd, args} ou a forma argv plana. O modelo chama @browser automaticamente em /agent e /coder quando precisa olhar uma página.

Refs vs. seletores CSS

Todo snapshot marca cada elemento interativo com um atributo data-chatcli-ref e retorna uma listagem numerada. click e type aceitam tanto esse número de ref [n] quanto um seletor CSS puro:
As refs são estáveis até a próxima navegação. Depois de open numa nova URL ou de um click que dispara navegação, tire um snapshot novo antes de endereçar elementos por [n] de novo.

Um exemplo prático

Construa uma página no /coder, então verifique-a de ponta a ponta:
O agente agora sabe que o botão funcionou na UI mas o backend retornou 500, e o erro exato do console — o loop completo de verificar-e-corrigir sem sair do ChatCLI.

Variáveis de ambiente


Segurança

Comandos de observação são read-only e pulam a confirmação — o agente pode olhar à vontade: open, snapshot, screenshot, console, network, scroll, back, status, close. Comandos que agem sobre a página — click, type e eval — podem disparar ações reais em sites remotos, então passam pelo gate de segurança padrão como qualquer outra tool que muta estado. Veja Segurança do Modo Coder.
O @browser controla um navegador de verdade logado em qualquer perfil que ele inicie. Prefira a sessão descartável default para páginas não confiáveis, e trate click/type/eval em sites externos como as operações com efeito colateral que são.

Notas

  • Uma sessão por processo, iniciada preguiçosamente no primeiro open e reaproveitada em toda chamada.
  • Console e rede são capturados continuamente em rings limitados — console/network leem o histórico recente, não precisam ser “armados” antes.
  • screenshot grava um PNG (default no diretório temporário, ou --file path). Combine com @view para o modelo olhar o screenshot que acabou de tirar.
  • O navegador é sempre fechado no encerramento do ChatCLI; um Chrome headless perdido nunca sobrevive à sessão.

Próximos passos

Entrada de Imagem (@view)

Anexe um screenshot que o @browser capturou para o modelo ver com os próprios olhos.

Plugin @coder

Ler, escrever, aplicar patch e executar — combine com @browser para construir e então verificar.

Plugins Agênticos

O catálogo completo de tools builtin e como o agente as usa.

Web Tools

@webfetch, @websearch e o cliente HTTP endurecido compartilhado.