Os teus agentes pilotam um navegador real.
Não um falso.
AgentsRoom integra um navegador Chromium real em cada projeto, e inclui um servidor AgentsRoom Browser MCP que deixa os teus agentes IA controlá-lo. O teu agente QA abre o teu site localhost, clica nos botões, preenche os formulários, tira screenshots, lê a consola, e verifica que a feature realmente funciona antes de dizer done. Automação de navegador end-to-end para Claude Code, Codex, OpenCode, Gemini CLI e Aider, com zero configuração Playwright.
Combina-o com Agent Teams: um agente Dev entrega a feature, um agente QA carrega o site localhost no navegador integrado, executa o cenário de verificação, captura o resultado, e assina. A automação de navegador nativa também está no roadmap, com futuros servidores MCP planeados para apps React Native e Electron para que os agentes também possam testar apps mobile e desktop.
Demo do AgentsRoom Browser MCP: testes end-to-end de web apps dirigidos por um agente QA Claude Code através do navegador Chromium integrado.
Browser Automation no AgentsRoom são duas coisas numa só. Primeiro, um navegador Chromium real integrado em cada room de projeto, com barra de URL, atrás/frente, reload, histórico, captura para a área de transferência, abrir-no-navegador-por-defeito, cookies persistentes e localStorage por projeto. Segundo, um servidor AgentsRoom Browser MCP (agentsroom-browser) que expõe esse navegador aos teus agentes IA através do Model Context Protocol. O agente recebe uma interface limpa e scriptável: navigate, click, type, screenshot, evaluate JavaScript, wait for an element, get the page state, get the console logs, go back, go forward, reload.
Porque é que isto importa? Porque toda a promessa dos agentes IA de código desmorona-se quando o agente diz 'feature entregue' mas nunca abre a página para verificar. A maioria dos agentes hoje baseia-se em correr unit tests, e depois espera. Com um Browser MCP real, o agente carrega o servidor localhost, exercita o flow do utilizador, vê o que o utilizador humano veria, e só então assina. O papel de agente QA Engineer finalmente tem as tools de que precisa para fazer QA real, não só análise estática.
O setup técnico é invisível para ti. Quando marcas 'Browser access' num agente, AgentsRoom faz merge da entrada agentsroom-browser no .mcp.json do teu projeto e o agente arranca com as tools de browser disponíveis. Uma ponte WebSocket que corre num porto loopback (127.0.0.1, atribuído pelo OS, regenerado em cada arranque, autenticado com um token hex de 32 bytes) liga o subprocesso MCP ao WebContentsView Chromium na app Electron. Cada clique, cada escrita, cada screenshot é uma chamada JSON-RPC. O agente vê um navegador real, não um stub.
Painel Browser do AgentsRoom: barra de URL, histórico, captura, e superfície de controlo MCP completa para os agentes IA navegarem, clicarem, escreverem e verificarem.
Um navegador real, não um stub Playwright
A maioria das demos de agentes IA que falam de browser automation usa uma instância Playwright headless spawnada em cada chamada de tool. Isso funciona para benchmarks mas é uma dor na vida real: não vês o que o agente está a fazer, cada navegação respawna Chromium, as cookies perdem-se, o localStorage está vazio, o teu servidor de dev pensa que cada visita é uma sessão novíssima. AgentsRoom toma um ângulo diferente. O navegador já está aberto na tua room de projeto (usá-lo tu mesmo, como um navegador normal), e o agente pilota esse navegador. Sessões, cookies, localStorage, estado de login, tudo preservado.
Cada clique e escrita do agente dispara um dispatch nativo real através do WebContentsView do Electron, com eventos de teclado, eventos de rato e mutações DOM reais. Os screenshots são PNGs reais capturados da página renderizada real (não um hack DOM-para-imagem). Os logs de consola são bufferizados e consultáveis, incluindo warnings e errors. O agente vê o mesmo que verias com as DevTools abertas: performance real, comportamento de rede real, CORS real, auth real.
O isolamento cross-room é aplicado. AgentsRoom cria um WebContentsView Chromium por projeto, com a sua própria partição de sessão (persist:agentsroom-browser-<projectId>). As cookies do projeto A nunca vazam para o projeto B. Quando mudas de projeto, o navegador anterior é escondido e o novo entra em linha com o seu próprio estado. O agente aterra sempre no projeto correto, com as credenciais corretas.
A camada MCP é intencionalmente pequena e sem dependências. O subprocesso browser-mcp-server.cjs fala o protocolo MCP 2024-11-05 sobre stdio (initialize, tools/list, tools/call) e traduz isso em chamadas JSON-RPC sobre a ponte WebSocket loopback. Comparado com um servidor pesado baseado em SDK, isto mantém-se rápido (primeira chamada de tool abaixo de 100ms) e fácil de debuggar. Depois de cada ação que muda a página (click, type, navigate, reload, back, forward), a resposta inclui um screenshot PNG em base64 com tecto de 1.6 MB para que o agente veja sempre o resultado do que acabou de fazer. Isto revelou-se o maior ganho único de fiabilidade: agentes que veem o ecrã fazem o certo muito mais vezes do que agentes que esperam.
O toolkit Browser MCP que os teus agentes recebem
Cada agente IA com browser access arranca com estas tools disponíveis. Estão expostas através de MCP standard, por isso qualquer CLI compatível vê-as: Claude Code, Codex CLI, OpenCode, Gemini CLI, Aider.
browser_navigate
Abre uma URL no navegador integrado. Tratamento inteligente de URL: localhost:3000 torna-se http://localhost:3000 em vez de disparar um diálogo 'cannot open application'. Devolve a URL final e um screenshot da página depois do load.
browser_click
Clica num elemento por seletor ou por texto visível. Evento de click nativo real, não um dispatch JavaScript. Devolve o screenshot pós-clique para o agente ver o resultado da sua ação.
browser_type
Escreve texto num input ou textarea. Suporta atalhos de teclado e submit. Eventos de teclado reais, os handlers onChange da página disparam. Devolve o screenshot depois de escrever.
browser_screenshot
Captura o viewport atual como PNG. Útil para checks de regressão visual, design QA, comparações antes-e-depois, ou para partilhar o estado de um bug com o resto da equipa.
browser_evaluate
Executa uma expressão JavaScript no main world da página. Recebe o resultado serializado de volta. Usado pelos agentes para ler o estado da página, consultar o DOM, inspecionar uma store Redux, ou disparar uma ação que não tem botão visível.
browser_wait_for
Espera por um elemento aparecer, pela URL mudar, por um pedido de rede terminar, ou por JavaScript arbitrário devolver true. Evita a clássica race 'o agente clica demasiado rápido'.
browser_get_state
Lê a URL atual, o título, o viewport, a posição de scroll, e um snapshot estruturado dos elementos acessíveis da página. O input principal do agente quando precisa de planear a sua próxima ação.
browser_get_logs
Busca o buffer de consola (log, warn, error). O agente pode ver os mesmos warnings React, erros de hidratação, falhas de rede e exceções de runtime que verias nas DevTools. Os bug reports tornam-se 'aqui está o erro da consola'.
browser_go_back / forward / reload
Navegação standard de navegador, scriptável. Usada pelos agentes para retroceder quando um flow corre mal, ou para re-testar uma página depois de um hot reload de Vite, Next.js ou Expo Metro.
O que os agentes fazem mesmo com o navegador
Workflows reais que podes construir hoje, com o papel QA Engineer e Agent Teams.
Smoke test end-to-end em cada handoff
Liga uma equipa Dev para QA. O agente QA navega para o teu servidor de dev localhost, clica pelos caminhos críticos (signup, checkout, dashboard), captura o resultado, e assina só se nada lançar erros. Apanha regressões antes que um humano abra a página.
QA de regressão visual
Screenshots antes-e-depois em alterações de UI. O agente carrega a página no commit anterior, captura, muda de branch, captura, pede ao Claude para comparar. Diff visual barato para QA sem Percy ou Chromatic no loop.
Caça a erros de consola
O agente navega a app, chama browser_get_logs, encontra warnings de hidratação React, warnings useEffect, 404s de rede, erros CORS, notices de deprecation. Reporta-os como uma lista de riscos no payload de handoff da equipa, o agente Dev seguinte corrige-os.
Testes de validação de formulário
O agente preenche o formulário com dados válidos, com campos vazios, com casos limite (strings XSS, inputs muito longos, não-ASCII). Verifica as mensagens de validação, os pedidos de rede, os redirects. QA de formulário real, não unit tests.
Auditoria de acessibilidade
O agente percorre a página, consulta a árvore de acessibilidade via browser_get_state e browser_evaluate, verifica alt textos, atributos ARIA, gestão de focus, navegação por teclado. Reporta problemas com screenshots.
Design QA contra Figma
Combina com a feature Figma para agentes IA. O agente carrega a frame Figma, captura, carrega a página localhost, captura, compara espaçamentos, fontes, cores, alinhamentos. Apresenta uma lista de discrepâncias.
Verificação de túnel de live preview
Combina com o túnel localhost do AgentsRoom. O agente navega para a URL HTTPS de preview pública (não localhost), verifica que o site é alcançável de fora, captura, e confirma que um stakeholder pode mesmo abrir o link.
Reproduzir um bug de cliente a partir de um ticket de backlog público
Um ticket de backlog público chega com uma URL e passos para reproduzir. O agente QA abre a URL, segue os passos, captura o erro de consola, anexa o screenshot, faz handoff ao Dev com uma repro limpa. Acabaram-se os loops 'cannot reproduce'.
Como um agente obtém um navegador
Abre o separador Browser na tua room
Na tua room de projeto, o painel direito expõe três separadores: Files, Changes, Browser. Carrega em Browser. O painel alarga, a sidebar colapsa, e uma vista Chromium real aparece. Escreve uma URL ou escolhe do histórico do projeto.
Marca 'Browser access' no agente
Abre a modal Edit Agent, expande Capabilities, marca Browser access. AgentsRoom faz merge da entrada agentsroom-browser no .mcp.json do teu projeto e o agente verá as tools de browser no próximo arranque.
<project>/.mcp.jsonO agente arranca com o browser MCP
No spawn do agente, Claude (ou Codex, Gemini, etc.) inicializa o servidor MCP agentsroom-browser, lista as suas tools (browser_navigate, browser_click, browser_type, browser_screenshot, browser_evaluate, browser_wait_for, browser_get_state, browser_get_logs, browser_go_back, browser_go_forward, browser_reload), e a partir daí pode pilotar o navegador.
O agente usa o navegador
O agente navega, clica, escreve, captura, lê a consola. Cada ação passa por uma ponte WebSocket loopback (127.0.0.1, porto atribuído pelo OS, token hex de 32 bytes, regenerado em cada arranque da app desktop). Depois de cada ação que muda a página, um screenshot é devolvido inline para o agente verificar visualmente o seu movimento.
Auto-targeting localhost ou o teu túnel
Se um túnel localhost está a correr, a primeira navegação aterra na URL do túnel. Senão, no primeiro servidor de dev detetado. Senão, https://localhost:3000. Combinado com Dev Terminals, o agente literalmente arranca o servidor de dev, depois abre-o no navegador, depois testa-o.
Verifica, captura, faz handoff
Quando ligado em Agent Teams, o node QA executa os seus cenários, captura screenshots, põe flags.qaPassed no payload de handoff. O agente seguinte herda o veredito. Pass vai ao PM, fail volta ao Dev com as pistas de teste.
Por baixo do capô
Para os curiosos. A stack de browser automation é pequena de propósito.
Cada projeto tem um WebContentsView Chromium (a API moderna do Electron, não o BrowserView deprecated), sobreposto na janela principal com bounds streamados do renderer React. A partição de sessão por projeto mantém cookies, localStorage e autenticação isolados entre projetos. Bounds offscreen por defeito deixam os agentes chamar tools de browser mesmo antes do humano abrir o separador Browser, com um timeout de 5 segundos nos screenshots para evitar pendurar.
Um servidor WebSocket leve (browser-bridge.ts) corre num porto loopback escolhido pelo OS, ligado só a 127.0.0.1. A autenticação usa um token hex de 32 bytes regenerado em cada arranque desktop. O ficheiro de ponte ~/.agentsroom/browser-bridge.json contém o porto, o token e o PID atuais, reescrito atomicamente em cada arranque, para que o subprocesso MCP apanhe sempre credenciais frescas com retry automático.
O servidor MCP em si é browser-mcp-server.cjs, um script Node sem dependências que implementa o protocolo MCP 2024-11-05 sobre stdio (initialize, tools/list, tools/call). Fala JSON-RPC com a ponte WebSocket através de um cliente WebSocket feito à mão (sem ws, sem @modelcontextprotocol/sdk). Pequeno, rápido, fácil de auditar. Empacotado como ficheiro extraResources na app desktop, por isso cada install é entregue com ele pronto a correr.
O suporte de navegador nativo (uma feature de browser de primeira classe além do MCP) está no roadmap do AgentsRoom. Para além disso, o plano a longo prazo inclui MCPs adicionais para que os agentes piloten também targets não-web: um MCP React Native para apps mobile e um MCP Electron para apps desktop. Mesma ideia, mesma UX: o agente não escreve só código, exercita mesmo a app que está a correr.
FAQ
Em que é que isto é diferente do Playwright MCP ou de tools de navegador baseadas em Puppeteer?
Os MCPs baseados em Playwright e Puppeteer spawnam um navegador headless fresco em cada sessão. Está bem para tarefas sem estado, mas perde cookies, localStorage e auth entre chamadas, e o humano não pode ver o que o agente está a fazer. AgentsRoom Browser é o mesmo navegador que o humano usa dentro da app, com sessão persistente por projeto, visível para o utilizador em tempo real. O agente pilota uma janela que podes ver e tomar conta a qualquer momento. É uma automação de navegador mais honesta, mais debuggável.
Isto funciona com todos os providers IA, ou só com Claude Code?
Funciona com todos os providers que o AgentsRoom suporta: Claude Code, Codex CLI, OpenCode, Gemini CLI e Aider. As tools de browser são expostas através do Model Context Protocol standard, que todos estes CLIs lêem do .mcp.json. O agente nunca sabe que está no AgentsRoom, vê só um conjunto de tools MCP e usa-as como usaria qualquer outra tool.
O agente pode pilotar um site remoto, ou só localhost?
Ambos. Escreve qualquer URL e go. As formas localhost (e host:port) são smart-detetadas, prefixadas com http://, e abertas diretamente. Os sites públicos funcionam como em qualquer navegador normal, com cookies e estado de login preservados por projeto. Combinado com o túnel localhost do AgentsRoom, o agente também pode pilotar o teu servidor de dev local através de uma URL HTTPS pública, o que é útil para QA cross-network e mobile.
O browser MCP é seguro? O que é que impede o abuso?
A ponte liga só a 127.0.0.1, nunca a 0.0.0.0. O porto é atribuído pelo OS (sem porto fixo propício a scanning de colisão). Um token hex de 32 bytes é necessário em cada ligação, regenerado em cada arranque desktop. O subprocesso MCP recebe as credenciais só via variáveis de ambiente, nunca num ficheiro commitado. O acesso ao navegador é opt-in por agente na modal Edit Agent. Se o tirares, a entrada .mcp.json é tirada e o agente já não pode usar as tools.
O agente vê a consola do navegador (errors, warnings, network)?
Sim, via browser_get_logs. O buffer contém mensagens console.log, console.warn e console.error do main world da página. Muitos bugs reais (erros de hidratação React, warnings useEffect, falhas CORS) só emergem na consola, nunca em unit tests, por isso isto revela-se uma das tools de maior sinal para o agente QA.
O que acontece com os screenshots devolvidos ao agente? Custam muitos tokens?
Depois de cada ação que muda a página, um screenshot PNG em base64 é anexado à resposta da tool, com tecto de 1.6 MB. Acima disso, é enviado um marcador de texto. Os screenshots são críticos para a fiabilidade (um agente que vê o ecrã faz bastantes menos erros), por isso o trade-off vale a pena. Se quiseres desativar os screenshots por razões de orçamento, as chamadas browser_evaluate simples devolvem só texto.
O agente pode preencher um formulário de login? Persistir a sua sessão?
Sim. Cookies e localStorage são persistidos por projeto sob a partição de sessão persist:agentsroom-browser-<projectId>. O agente pode fazer login uma vez com browser_type e browser_click, e ficar logado durante o resto do run. Quando mudas de projeto, a sessão muda, por isso as credenciais nunca vazam entre projetos.
O agente parte se o servidor de dev não estiver a correr?
Vai navegar para a URL e ver uma página de erro Chromium. Pode ler esse erro via browser_get_state e browser_get_logs e reagir em conformidade: pedir-te para arrancar o servidor, ou chamar um comando Dev Terminals para o arrancar. Com Agent Teams e Dev Terminals, podes ligar um workflow que arranca o servidor, espera, depois abre o navegador, tudo sem intervenção humana.
As apps mobile e desktop também são suportadas?
A web está entregue hoje, através do Chromium integrado e do AgentsRoom Browser MCP. O roadmap inclui um AgentsRoom Browser nativo como feature de browser de primeira classe. Para além disso, há servidores MCP adicionais planeados: um MCP React Native para que os agentes piloten bundles iOS e Android Expo, e um MCP Electron para que os agentes piloten apps desktop que não são web. A mesma lógica de agente, aplicada a targets não-web.
O humano pode pausar o agente e tomar conta do navegador?
Sim. O navegador é a mesma vista Chromium que o humano usa. A qualquer momento, carrega no painel Browser e tu tens o controlo. Assim que parares de interagir, o agente pode retomar as suas chamadas de tool. Não há conceito de 'navegador bloqueado pelo agente', é uma superfície partilhada, exatamente como uma sessão de pair programming.
Dá aos teus agentes olhos de navegador reais
Marca Browser access em qualquer agente no AgentsRoom. O Browser MCP arranca automaticamente. O teu agente QA finalmente testa o que entrega.
App complementar: acompanhe seus agentes em qualquer lugar
Compatível com Claude, Codex, OpenCode, Gemini CLI e Aider
Envie bugs e pedidos direto para o seu backlog público.