I tuoi agenti pilotano un vero browser.
Non uno finto.
AgentsRoom integra un vero browser Chromium in ogni progetto e include un server AgentsRoom Browser MCP che permette ai tuoi agenti IA di controllarlo. Il tuo QA agent apre il sito su localhost, clicca i pulsanti, riempie i form, fa screenshot, legge la console e verifica che la feature funzioni davvero prima di dire done. Browser automation end-to-end per Claude Code, Codex, OpenCode, Gemini CLI e Aider, con zero config Playwright.
Abbinalo ad Agent Teams: un agente Dev rilascia la feature, un QA agent carica il sito localhost nel browser integrato, esegue lo scenario di verifica, fa screenshot del risultato e approva. Anche la browser automation nativa e nella roadmap, con MCP server futuri previsti per app React Native ed Electron cosi gli agenti possono testare anche app mobile e desktop.
Demo AgentsRoom Browser MCP: testing end-to-end di web app guidato da un QA agent Claude Code attraverso il browser Chromium integrato.
La Browser Automation in AgentsRoom e due cose in una. Primo, un vero browser Chromium integrato in ogni room di progetto, con barra URL, back/forward, reload, history, screenshot in clipboard, open-in-default-browser, cookie e localStorage persistenti per progetto. Secondo, un server AgentsRoom Browser MCP (agentsroom-browser) che espone quel browser ai tuoi agenti IA tramite il Model Context Protocol. L'agente ottiene un'interfaccia pulita e scriptable: navigate, click, type, screenshot, evaluate JavaScript, wait per un elemento, get page state, get console logs, go back, go forward, reload.
Perche conta? Perche tutta la promessa degli agenti IA di coding crolla quando l'agente dice 'feature shipped' ma non apre mai la pagina per controllare. La maggior parte degli agenti oggi si affida a far girare gli unit test, poi spera. Con un vero browser MCP, l'agente carica il server localhost, esercita il flusso utente, vede cio che vedrebbe l'utente umano e solo allora approva. Il ruolo QA Engineer agent ha finalmente i tool che gli servono per fare vero QA, non solo analisi statica.
Il setup tecnico e invisibile per te. Quando spunti 'Browser access' su un agente, AgentsRoom unisce la entry agentsroom-browser nel .mcp.json del tuo progetto e l'agente parte con i tool del browser disponibili. Un bridge WebSocket che gira su una porta loopback (127.0.0.1, assegnata dall'OS, rigenerata a ogni boot, autenticata con un token hex di 32 byte) connette il subprocess MCP al WebContentsView Chromium nell'app Electron. Ogni click, ogni type, ogni screenshot e una chiamata JSON-RPC. L'agente vede un vero browser, non uno stub.
Pannello Browser di AgentsRoom: barra URL, history, screenshot e superficie di controllo MCP completa per agenti IA per navigare, cliccare, scrivere e verificare.
Un vero browser, non uno stub Playwright
La maggior parte delle demo di agenti IA che parlano di browser automation usa un'istanza Playwright headless avviata a ogni tool call. Funziona per i benchmark ma e doloroso nella vita reale: non vedi cosa sta facendo l'agente, ogni navigazione respawna Chromium, i cookie si perdono, localStorage e vuoto, il tuo dev server pensa che ogni visita sia una sessione nuova di zecca. AgentsRoom prende un'angolazione diversa. Il browser e gia aperto nella tua room di progetto (lo usi tu stesso, come un browser normale), e l'agente pilota quel browser. Sessioni, cookie, localStorage, stato di login, tutto preservato.
Ogni click e type dall'agente innesca un dispatch nativo reale tramite il WebContentsView di Electron, con eventi tastiera, eventi mouse e mutazioni del DOM appropriati. Gli screenshot sono veri PNG catturati dalla pagina effettivamente renderizzata (non un hack DOM-to-image). I log della console sono bufferizzati e queryabili, inclusi warning ed errori. L'agente vede la stessa cosa che vedresti tu con i DevTools aperti: prestazioni reali, comportamento di rete reale, CORS reale, auth reale.
L'isolamento cross-room e applicato. AgentsRoom crea un WebContentsView Chromium per progetto, con la sua session partition (persist:agentsroom-browser-<projectId>). I cookie del progetto A non finiscono mai nel progetto B. Quando cambi progetto, il browser precedente viene nascosto e il nuovo arriva online con il suo stato. L'agente atterra sempre sul progetto corretto, con le credenziali corrette.
Lo strato MCP e intenzionalmente piccolo e senza dipendenze. Il subprocess browser-mcp-server.cjs parla il protocollo MCP 2024-11-05 su stdio (initialize, tools/list, tools/call) e lo traduce in chiamate JSON-RPC sul bridge WebSocket loopback. Confrontato a un server SDK-based pesante, resta veloce (la prima tool call e sotto i 100ms) e facile da debuggare. Dopo ogni azione che cambia la pagina (click, type, navigate, reload, back, forward), la risposta include uno screenshot PNG base64 capped a 1.6 MB cosi l'agente vede sempre il risultato di cio che ha appena fatto. Si e rivelata la singola piu grande vittoria di affidabilita: gli agenti che vedono lo schermo fanno la cosa giusta molto piu spesso degli agenti che sperano.
Il toolkit Browser MCP che ottengono i tuoi agenti
Ogni agente IA con browser access parte con questi tool disponibili. Sono esposti tramite MCP standard, quindi qualsiasi CLI compatibile li vede: Claude Code, Codex CLI, OpenCode, Gemini CLI, Aider.
browser_navigate
Apre un URL nel browser integrato. Smart URL handling: localhost:3000 diventa http://localhost:3000 invece di triggerare un dialog 'cannot open application'. Ritorna l'URL finale e uno screenshot della pagina dopo il caricamento.
browser_click
Clicca un elemento per selettore o per testo visibile. Vero evento click nativo, non un dispatch JavaScript. Ritorna lo screenshot post-click cosi l'agente vede il risultato della sua azione.
browser_type
Scrive testo in un input o textarea. Supporta scorciatoie da tastiera e submit. Veri eventi tastiera, gli handler onChange della pagina partono. Ritorna lo screenshot dopo la scrittura.
browser_screenshot
Cattura il viewport corrente come PNG. Utile per controlli di regressione visiva, design QA, confronti before-and-after o per condividere lo stato di un bug con il resto del team.
browser_evaluate
Esegue un'espressione JavaScript nel main world della pagina. Restituisce il risultato serializzato. Usato dagli agenti per leggere lo stato della pagina, interrogare il DOM, ispezionare uno store Redux o triggerare un'azione che non ha un pulsante visibile.
browser_wait_for
Attende che appaia un elemento, che cambi l'URL, che finisca una richiesta di rete o che del JavaScript arbitrario ritorni true. Evita la classica race 'agent clicks too fast'.
browser_get_state
Legge URL, titolo, viewport, scroll position correnti e uno snapshot strutturato degli elementi accessibili della pagina. L'input primario dell'agente quando deve pianificare la prossima azione.
browser_get_logs
Tira il buffer della console (log, warn, error). L'agente vede gli stessi warning React, errori di hydration, fallimenti di rete ed eccezioni runtime che vedresti tu nei DevTools. I report di bug diventano 'ecco l'errore dalla console'.
browser_go_back / forward / reload
Navigazione standard del browser, scriptable. Usata dagli agenti per tornare indietro quando un flusso va male, o per ri-testare una pagina dopo un hot reload da Vite, Next.js o Expo Metro.
Cosa fanno davvero gli agenti con il browser
Workflow reali che puoi costruire oggi, con il ruolo QA Engineer e Agent Teams.
Smoke test end-to-end a ogni handoff
Cabla un team Dev verso QA. L'agente QA naviga al tuo dev server localhost, clicca attraverso i path critici (signup, checkout, dashboard), fa screenshot del risultato e approva solo se nulla viene lanciato. Becca le regressioni prima che un umano apra mai la pagina.
QA di regressione visiva
Screenshot before-and-after sui cambi UI. L'agente carica la pagina sul commit precedente, screenshot, cambia branch, screenshot, chiede a Claude di confrontare. QA con diff visivo economico senza Percy o Chromatic in the loop.
Caccia agli errori in console
L'agente naviga l'app, chiama browser_get_logs, trova warning di hydration React, warning useEffect, 404 di rete, errori CORS, deprecation notice. Li riporta come lista di rischi nel payload di handoff del team, il prossimo agente Dev li corregge.
Test di validazione form
L'agente riempie il form con dati validi, con campi vuoti, con edge case (stringhe XSS, input molto lunghi, non-ASCII). Verifica i messaggi di validazione, le richieste di rete, i redirect. Vero QA dei form, non unit test.
Audit di accessibilita
L'agente percorre la pagina, interroga l'accessibility tree via browser_get_state e browser_evaluate, controlla alt text, attributi ARIA, gestione del focus, navigazione da tastiera. Riporta i problemi con screenshot.
Design QA contro Figma
Combinalo con la feature Figma to AI agents. L'agente carica il frame Figma, screenshot, carica la pagina localhost, screenshot, confronta spaziature, font, colori, allineamenti. Apre una lista di mismatch.
Verifica del tunnel di preview live
Abbinalo al tunnel localhost di AgentsRoom. L'agente naviga all'URL pubblico HTTPS di preview (non localhost), verifica che il sito sia raggiungibile dall'esterno, fa screenshot e conferma che uno stakeholder possa davvero aprire il link.
Riprodurre un bug cliente da un ticket di backlog pubblico
Arriva un ticket di backlog pubblico con un URL e i passi per riprodurre. Il QA agent apre l'URL, segue i passi, cattura l'errore in console, allega lo screenshot, fa l'handoff al Dev con un repro pulito. Niente piu loop 'cannot reproduce'.
Come un agente ottiene un browser
Apri la tab Browser nella tua room
Nella tua room di progetto, il pannello destro espone tre tab: Files, Changes, Browser. Clicca Browser. Il pannello si allarga, la barra laterale collassa e appare una vera vista Chromium. Scrivi un URL o scegli dalla history del progetto.
Spunta 'Browser access' sull'agente
Apri il modale Edit Agent, espandi Capabilities, spunta Browser access. AgentsRoom unisce la entry agentsroom-browser nel .mcp.json del tuo progetto e l'agente vedra i tool del browser al prossimo avvio.
<project>/.mcp.jsonL'agente parte con il browser MCP
All'avvio dell'agente, Claude (o Codex, Gemini, ecc.) inizializza il server MCP agentsroom-browser, elenca i suoi tool (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 da quel momento puo pilotare il browser.
L'agente usa il browser
L'agente naviga, clicca, scrive, fa screenshot, legge la console. Ogni azione passa attraverso un bridge WebSocket loopback (127.0.0.1, porta assegnata dall'OS, token hex di 32 byte, rigenerato a ogni boot dell'app desktop). Dopo ogni azione che cambia la pagina, viene restituito uno screenshot inline cosi l'agente verifica visivamente la sua mossa.
Auto-target su localhost o sul tuo tunnel
Se un tunnel localhost e in esecuzione, la prima navigazione atterra sull'URL del tunnel. Altrimenti, sul primo dev server rilevato. Altrimenti, https://localhost:3000. Combinato con i Dev Terminals, l'agente letteralmente avvia il dev server, poi lo apre nel browser, poi lo testa.
Verifica, screenshot, handoff
Quando cablato in Agent Teams, il nodo QA esegue i suoi scenari, cattura screenshot, imposta flags.qaPassed nel payload di handoff. Il prossimo agente eredita il verdetto. Pass va al PM, fail torna al Dev con gli hint di test.
Sotto il cofano
Per i curiosi. Lo stack di browser automation e piccolo di proposito.
Ogni progetto ha un WebContentsView Chromium (l'API Electron moderna, non la BrowserView deprecata), sovrapposto alla finestra principale a bounds streamati dal renderer React. La session partition per progetto tiene cookie, localStorage e autenticazione isolati tra i progetti. I bounds default offscreen permettono agli agenti di chiamare i tool browser anche prima che l'umano apra la tab Browser, con un timeout di 5 secondi sugli screenshot per evitare hang.
Un server WebSocket leggero (browser-bridge.ts) gira su una porta loopback scelta dall'OS, bound solo a 127.0.0.1. L'autenticazione usa un token hex di 32 byte rigenerato a ogni boot del desktop. Il file bridge ~/.agentsroom/browser-bridge.json tiene porta, token e PID corrente, riscritto atomicamente a ogni boot, cosi il subprocess MCP prende sempre credenziali fresche con retry automatico.
Il server MCP stesso e browser-mcp-server.cjs, uno script Node zero-dipendenze che implementa il protocollo MCP 2024-11-05 su stdio (initialize, tools/list, tools/call). Parla JSON-RPC al bridge WebSocket attraverso un client WebSocket fatto a mano (no ws, no @modelcontextprotocol/sdk). Piccolo, veloce, facile da auditare. Bundle come file extraResources nell'app desktop, cosi ogni install lo include pronto all'uso.
Il supporto browser nativo (una feature browser di prima classe oltre al MCP) e nella roadmap di AgentsRoom. Oltre a quello, il piano a lungo termine include MCP aggiuntivi cosi gli agenti possono pilotare anche target non-web: un MCP React Native per app mobile e un MCP Electron per app desktop. Stessa idea, stessa UX: l'agente non si limita a scrivere codice, esercita davvero l'app in esecuzione.
FAQ
In cosa differisce da Playwright MCP o dai tool browser basati su Puppeteer?
Gli MCP basati su Playwright e Puppeteer avviano un browser headless fresco a ogni sessione. Va bene per task stateless, ma perde cookie, localStorage e auth tra le chiamate, e l'umano non puo vedere cosa sta facendo l'agente. AgentsRoom Browser e lo stesso browser che l'umano usa dentro l'app, con sessione persistente per progetto, visibile all'utente in tempo reale. L'agente pilota una finestra che puoi vedere e su cui puoi intervenire in qualsiasi momento. E una browser automation piu onesta, piu debuggabile.
Funziona con tutti i provider IA o solo con Claude Code?
Funziona con tutti i provider che AgentsRoom supporta: Claude Code, Codex CLI, OpenCode, Gemini CLI e Aider. I tool del browser sono esposti tramite il Model Context Protocol standard, che tutte queste CLI leggono da .mcp.json. L'agente non sa mai di essere in AgentsRoom, vede solo un set di tool MCP e li usa come userebbe qualsiasi altro tool.
L'agente puo pilotare un sito remoto, o solo localhost?
Entrambi. Scrivi qualsiasi URL e vai. Localhost (e forme host:port) sono smart-detected, prefissate con http:// e aperte direttamente. I siti pubblici funzionano come in qualsiasi browser normale, con cookie e stato di login preservati per progetto. Combinato con il tunnel localhost di AgentsRoom, l'agente puo anche pilotare il tuo dev server locale tramite un URL HTTPS pubblico, utile per QA cross-network e mobile.
Il browser MCP e sicuro? Cosa impedisce che venga abusato?
Il bridge si bind solo a 127.0.0.1, mai a 0.0.0.0. La porta e assegnata dall'OS (nessuna porta fissa per scanning collision-prone). E richiesto un token hex di 32 byte a ogni connessione, rigenerato a ogni boot del desktop. Il subprocess MCP riceve le credenziali solo via env var, mai in nessun file committato. Il browser access e opt-in per agente nel modale Edit Agent. Se lo rimuovi, la entry .mcp.json viene rimossa e l'agente non puo piu usare i tool.
L'agente vede la console del browser (errori, warning, network)?
Si, via browser_get_logs. Il buffer contiene messaggi console.log, console.warn e console.error dal main world della pagina. Molti bug reali (errori di hydration React, warning useEffect, fallimenti CORS) emergono solo nella console, mai negli unit test, quindi questo si rivela uno dei tool a piu alto segnale per il QA agent.
Cosa succede agli screenshot restituiti all'agente? Costano tanti token?
Dopo ogni azione che cambia la pagina, uno screenshot PNG base64 e accodato alla risposta del tool, capped a 1.6 MB. Sopra di che, viene mandato un text marker. Gli screenshot sono critici per l'affidabilita (un agente che vede lo schermo fa molti meno errori), quindi il trade-off vale la pena. Se vuoi disabilitare gli screenshot per ragioni di budget, le chiamate browser_evaluate semplici restituiscono solo testo.
L'agente puo riempire un form di login? Persistere la sua sessione?
Si. Cookie e localStorage sono persistenti per progetto sotto la session partition persist:agentsroom-browser-<projectId>. L'agente puo loggarsi una volta con browser_type e browser_click e restare loggato per tutto il resto del run. Quando cambi progetto, la sessione cambia, cosi le credenziali non finiscono mai tra progetti.
L'agente si rompe se il dev server non e in esecuzione?
Naviga all'URL e vede una pagina di errore Chromium. Puo leggere quell'errore via browser_get_state e browser_get_logs e reagire di conseguenza: chiederti di avviare il server, o chiamare un comando dei Dev Terminals per avviarlo. Con Agent Teams e Dev Terminals, puoi cablare un workflow che avvia il server, attende, poi apre il browser, tutto senza intervento umano.
Sono supportate anche app mobile e desktop?
Il web e in spedizione oggi, attraverso il Chromium integrato e l'AgentsRoom Browser MCP. La roadmap include un AgentsRoom Browser nativo come feature browser di prima classe. Oltre a quello, sono pianificati MCP server aggiuntivi: un MCP React Native cosi gli agenti possono pilotare bundle Expo iOS e Android, e un MCP Electron cosi gli agenti possono pilotare app desktop che non sono web. La stessa logica dell'agente, applicata a target non-web.
L'umano puo mettere in pausa l'agente e prendere il controllo del browser?
Si. Il browser e la stessa vista Chromium che l'umano usa. In qualsiasi momento, clicca nel pannello Browser e sei al comando. Una volta che smetti di interagire, l'agente puo riprendere le sue tool call. Non c'e il concetto di 'agent-locked browser', e una superficie condivisa, esattamente come una sessione di pair-programming.
Dai ai tuoi agenti veri occhi sul browser
Spunta Browser access su qualsiasi agente in AgentsRoom. Il Browser MCP parte automaticamente. Il tuo QA agent finalmente testa cio che spedisce.
App companion: monitora i tuoi agenti in movimento
Funziona con Claude, Codex, OpenCode, Gemini CLI e Aider
Invia bug e richieste direttamente nel tuo backlog pubblico.