Tes agents pilotent un vrai navigateur.
Pas un faux.
AgentsRoom embarque un vrai navigateur Chromium dans chaque projet, et livre un serveur AgentsRoom Browser MCP qui laisse tes agents IA le contrôler. Ton agent QA ouvre ton site localhost, clique sur les boutons, remplit les formulaires, prend des captures, lit la console, et vérifie que la feature marche vraiment avant de dire done. De la vraie automatisation navigateur end-to-end pour Claude Code, Codex, OpenCode, Gemini CLI et Aider, avec zéro config Playwright.
Combine-le avec Agent Teams : un agent Dev livre la feature, un agent QA charge le site localhost dans le navigateur intégré, exécute le scénario de vérification, screenshote le résultat, et signe. L'automatisation native du navigateur est aussi sur la roadmap, avec des futurs serveurs MCP prévus pour les apps React Native et Electron pour que les agents puissent tester le mobile et le desktop.
Demo AgentsRoom Browser MCP : tests end-to-end d'app web pilotés par un agent QA Claude Code à travers le navigateur Chromium intégré.
Browser Automation dans AgentsRoom, c'est deux choses en une. Premièrement, un vrai navigateur Chromium intégré à chaque room projet, avec barre d'URL, back/forward, reload, historique, capture vers presse-papiers, ouvrir-dans-navigateur-par-défaut, cookies persistants et localStorage par projet. Deuxièmement, un serveur AgentsRoom Browser MCP (agentsroom-browser) qui expose ce navigateur à tes agents IA via le Model Context Protocol. L'agent reçoit une interface propre et scriptable : navigate, click, type, screenshot, evaluate JavaScript, wait for an element, get the page state, get the console logs, go back, go forward, reload.
Pourquoi c'est important ? Parce que toute la promesse des agents IA de code s'effondre quand l'agent dit 'feature livrée' mais n'ouvre jamais la page pour vérifier. La plupart des agents aujourd'hui se contentent de lancer des tests unitaires, et après ils espèrent. Avec un vrai Browser MCP, l'agent charge le serveur localhost, exécute le user flow, voit ce que verrait l'utilisateur humain, et seulement après il signe. Le rôle agent QA Engineer a enfin les outils dont il a besoin pour faire de la vraie QA, pas juste de l'analyse statique.
Le setup technique t'est invisible. Quand tu coches 'Browser access' sur un agent, AgentsRoom merge l'entrée agentsroom-browser dans le .mcp.json de ton projet et l'agent boote avec les outils browser disponibles. Un bridge WebSocket qui tourne sur un port loopback (127.0.0.1, attribué par l'OS, régénéré à chaque boot, authentifié avec un token hex de 32 octets) connecte le sous-process MCP à la WebContentsView Chromium dans l'app Electron. Chaque clic, chaque saisie, chaque capture est un appel JSON-RPC. L'agent voit un vrai navigateur, pas un stub.
Panel Browser AgentsRoom : barre d'URL, historique, capture, et surface de contrôle MCP complète pour que les agents IA naviguent, cliquent, tapent et vérifient.
Un vrai navigateur, pas un stub Playwright
La plupart des démos d'agents IA qui parlent d'automatisation navigateur utilisent une instance Playwright headless spawnée à chaque appel d'outil. Ça marche pour les benchmarks mais c'est pénible dans la vraie vie : tu ne vois pas ce que fait l'agent, chaque navigation respawn Chromium, les cookies sont perdus, le localStorage est vide, ton serveur de dev pense que chaque visite est une nouvelle session toute neuve. AgentsRoom prend un angle différent. Le navigateur est déjà ouvert dans ta room projet (tu l'utilises toi-même, comme un navigateur normal), et l'agent pilote ce navigateur. Sessions, cookies, localStorage, état de connexion, tout est préservé.
Chaque clic et chaque saisie de l'agent déclenchent un vrai dispatch natif via la WebContentsView d'Electron, avec de vrais events clavier, events souris et mutations DOM. Les captures sont de vrais PNG capturés depuis la page rendue réelle (pas un hack DOM-vers-image). Les logs de console sont bufférisés et interrogeables, y compris les warnings et les errors. L'agent voit la même chose que tu verrais avec les DevTools ouvertes : vraie performance, vrai comportement réseau, vrai CORS, vraie auth.
L'isolation cross-room est appliquée. AgentsRoom crée une WebContentsView Chromium par projet, avec sa propre session partition (persist:agentsroom-browser-<projectId>). Les cookies du projet A ne fuient jamais dans le projet B. Quand tu changes de projet, le navigateur précédent est caché et le nouveau arrive en ligne avec son propre état. L'agent atterrit toujours sur le bon projet, avec les bons credentials.
La couche MCP est volontairement petite et sans dépendances. Le sous-process browser-mcp-server.cjs parle le protocole MCP 2024-11-05 sur stdio (initialize, tools/list, tools/call) et le traduit en appels JSON-RPC sur le bridge WebSocket loopback. Comparé à un serveur lourd basé sur SDK, ça reste rapide (premier appel d'outil sous les 100ms) et facile à debugger. Après chaque action qui change la page (click, type, navigate, reload, back, forward), la réponse inclut une capture PNG en base64 plafonnée à 1.6 MB pour que l'agent voie toujours le résultat de ce qu'il vient de faire. C'est le plus gros gain de fiabilité qu'on a constaté : les agents qui voient l'écran font le bon truc bien plus souvent que les agents qui espèrent.
La toolkit Browser MCP que tes agents reçoivent
Chaque agent IA avec accès navigateur boote avec ces outils disponibles. Ils sont exposés via MCP standard, donc tout CLI compatible les voit : Claude Code, Codex CLI, OpenCode, Gemini CLI, Aider.
browser_navigate
Ouvre une URL dans le navigateur intégré. Gestion intelligente des URL : localhost:3000 devient http://localhost:3000 au lieu de déclencher un dialogue 'cannot open application'. Retourne l'URL finale et une capture de la page après chargement.
browser_click
Clique sur un élément par sélecteur ou par texte visible. Vrai event de clic natif, pas un dispatch JavaScript. Retourne la capture post-clic pour que l'agent voie le résultat de son action.
browser_type
Tape du texte dans un input ou une textarea. Supporte les raccourcis clavier et le submit. Vrais events clavier, les handlers onChange de la page sont déclenchés. Retourne la capture après la saisie.
browser_screenshot
Capture le viewport courant en PNG. Utile pour les checks de régression visuelle, le design QA, les comparaisons before-and-after, ou pour partager l'état d'un bug avec le reste de l'équipe.
browser_evaluate
Exécute une expression JavaScript dans le main world de la page. Récupère le résultat sérialisé. Utilisé par les agents pour lire l'état de la page, interroger le DOM, inspecter un store Redux, ou déclencher une action qui n'a pas de bouton visible.
browser_wait_for
Attend qu'un élément apparaisse, que l'URL change, qu'une requête réseau finisse, ou qu'un JavaScript arbitraire retourne true. Évite la classique race 'l'agent clique trop vite'.
browser_get_state
Lit l'URL courante, le titre, le viewport, la position de scroll, et un snapshot structuré des éléments accessibles de la page. L'input principal de l'agent quand il a besoin de planifier sa prochaine action.
browser_get_logs
Récupère le buffer de console (log, warn, error). L'agent peut voir les mêmes warnings React, erreurs d'hydratation, échecs réseau et exceptions runtime que tu verrais dans les DevTools. Les bug reports deviennent 'voici l'erreur de la console'.
browser_go_back / forward / reload
Navigation standard de navigateur, scriptable. Utilisée par les agents pour revenir en arrière quand un flow part en vrille, ou pour re-tester une page après un hot reload de Vite, Next.js ou Expo Metro.
Ce que les agents font vraiment avec le navigateur
Vrais workflows que tu peux construire dès aujourd'hui, avec le rôle QA Engineer et Agent Teams.
Smoke test end-to-end à chaque handoff
Câble une équipe Dev vers QA. L'agent QA navigue vers ton serveur de dev localhost, clique à travers les chemins critiques (signup, checkout, dashboard), screenshote le résultat, et signe seulement si rien ne crash. Attrape les régressions avant qu'un humain ouvre la page.
QA de régression visuelle
Captures avant-après sur les changements UI. L'agent charge la page sur le commit précédent, screenshote, change de branche, screenshote, demande à Claude de comparer. Diff visuel pas cher pour la QA, sans Percy ni Chromatic dans la boucle.
Chasse aux erreurs console
L'agent navigue dans l'app, appelle browser_get_logs, trouve les warnings d'hydratation React, les warnings useEffect, les 404 réseau, les erreurs CORS, les notices de deprecation. Les rapporte comme une liste de risques dans le payload de handoff d'équipe, l'agent Dev suivant les corrige.
Tests de validation de formulaire
L'agent remplit le formulaire avec des données valides, des champs vides, des cas limites (chaînes XSS, inputs très longs, non-ASCII). Vérifie les messages de validation, les requêtes réseau, les redirections. Vraie QA de formulaire, pas des tests unitaires.
Audit d'accessibilité
L'agent parcourt la page, interroge l'arbre d'accessibilité via browser_get_state et browser_evaluate, vérifie les alt textes, les attributs ARIA, la gestion du focus, la navigation clavier. Rapporte les problèmes avec captures.
Design QA contre Figma
Combine avec la feature Figma vers agents IA. L'agent charge la frame Figma, screenshote, charge la page localhost, screenshote, compare les espacements, polices, couleurs, alignements. Liste les écarts.
Vérif de tunnel preview live
Combine avec le tunnel localhost AgentsRoom. L'agent navigue vers l'URL HTTPS de preview publique (pas localhost), vérifie que le site est joignable depuis l'extérieur, screenshote, et confirme qu'un stakeholder peut vraiment ouvrir le lien.
Reproduire un bug client depuis un ticket de backlog public
Un ticket de backlog public arrive avec une URL et des étapes pour reproduire. L'agent QA ouvre l'URL, suit les étapes, capture l'erreur console, attache la capture, fait le handoff au Dev avec une repro propre. Plus de boucles 'cannot reproduce'.
Comment un agent obtient un navigateur
Ouvre l'onglet Browser dans ta room
Dans ta room projet, le panel de droite expose trois onglets : Files, Changes, Browser. Clique sur Browser. Le panel s'élargit, la sidebar se replie, et une vraie vue Chromium apparaît. Tape une URL ou choisis dans l'historique du projet.
Coche 'Browser access' sur l'agent
Ouvre la modale Edit Agent, déplie Capabilities, coche Browser access. AgentsRoom merge l'entrée agentsroom-browser dans le .mcp.json de ton projet et l'agent verra les outils browser au prochain démarrage.
<project>/.mcp.jsonL'agent boote avec le browser MCP
Au spawn de l'agent, Claude (ou Codex, Gemini, etc.) initialise le serveur MCP agentsroom-browser, liste ses outils (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), et à partir de maintenant peut piloter le navigateur.
L'agent utilise le navigateur
L'agent navigue, clique, tape, screenshote, lit la console. Chaque action passe par un bridge WebSocket loopback (127.0.0.1, port attribué par l'OS, token hex de 32 octets, régénéré à chaque boot de l'app desktop). Après chaque action qui change la page, une capture est retournée inline pour que l'agent vérifie visuellement son coup.
Cible automatique localhost ou ton tunnel
Si un tunnel localhost tourne, la première navigation atterrit sur l'URL du tunnel. Sinon, le premier serveur de dev détecté. Sinon, https://localhost:3000. Combiné aux Dev Terminals, l'agent démarre littéralement le serveur de dev, puis l'ouvre dans le navigateur, puis le teste.
Vérifie, screenshote, fait le handoff
Quand il est câblé dans Agent Teams, le node QA exécute ses scénarios, capture les screenshots, pose flags.qaPassed dans le payload de handoff. L'agent suivant hérite du verdict. Pass va au PM, fail repart au Dev avec les pistes de test.
Sous le capot
Pour les curieux. La stack d'automatisation navigateur est petite par choix.
Chaque projet a une WebContentsView Chromium (l'API Electron moderne, pas la BrowserView dépréciée), superposée sur la fenêtre principale aux bounds streamées depuis le renderer React. La session partition par projet garde les cookies, le localStorage et l'authentification isolés entre projets. Les bounds offscreen par défaut laissent les agents appeler les outils browser même avant que l'humain n'ouvre l'onglet Browser, avec un timeout de 5 secondes sur les screenshots pour éviter les freezes.
Un serveur WebSocket léger (browser-bridge.ts) tourne sur un port loopback choisi par l'OS, bind à 127.0.0.1 uniquement. L'authentification utilise un token hex de 32 octets régénéré à chaque boot desktop. Le fichier de bridge ~/.agentsroom/browser-bridge.json contient le port, le token et le PID courants, réécrit atomiquement à chaque boot, pour que le sous-process MCP récupère toujours des credentials frais avec retry automatique.
Le serveur MCP lui-même est browser-mcp-server.cjs, un script Node sans dépendance qui implémente le protocole MCP 2024-11-05 sur stdio (initialize, tools/list, tools/call). Il parle JSON-RPC au bridge WebSocket via un client WebSocket fait main (pas de ws, pas de @modelcontextprotocol/sdk). Petit, rapide, facile à auditer. Bundlé comme fichier extraResources dans l'app desktop, donc chaque install est livrée avec lui prêt à tourner.
Le support natif du navigateur (une feature browser first-class au-delà du MCP) est sur la roadmap AgentsRoom. Au-delà, le plan long terme inclut des MCP supplémentaires pour que les agents pilotent aussi des cibles non-web : un MCP React Native pour les apps mobiles et un MCP Electron pour les apps desktop. Même idée, même UX : l'agent n'écrit pas juste du code, il exerce vraiment l'app qui tourne.
FAQ
En quoi c'est différent du Playwright MCP ou des outils navigateur basés sur Puppeteer ?
Les MCP basés sur Playwright et Puppeteer spawn un nouveau navigateur headless à chaque session. C'est bien pour les tâches sans état, mais ça perd les cookies, le localStorage et l'auth entre les appels, et l'humain ne peut pas voir ce que fait l'agent. AgentsRoom Browser est le même navigateur que l'humain utilise dans l'app, avec session persistante par projet, visible par l'utilisateur en temps réel. L'agent pilote une fenêtre que tu peux voir et reprendre à tout moment. C'est une automatisation navigateur plus honnête, plus debuggable.
Ça marche avec tous les providers IA, ou seulement Claude Code ?
Ça marche avec tous les providers supportés par AgentsRoom : Claude Code, Codex CLI, OpenCode, Gemini CLI et Aider. Les outils browser sont exposés via le standard Model Context Protocol, que tous ces CLIs lisent depuis .mcp.json. L'agent ne sait jamais qu'il est dans AgentsRoom, il voit juste un set d'outils MCP et les utilise comme n'importe quel autre outil.
L'agent peut piloter un site distant, ou seulement localhost ?
Les deux. Tape n'importe quelle URL et go. Les formes localhost (et host:port) sont smart-detectées, préfixées avec http://, et ouvertes directement. Les sites publics marchent comme dans n'importe quel navigateur normal, avec cookies et état de connexion préservés par projet. Combiné au tunnel localhost AgentsRoom, l'agent peut aussi piloter ton serveur de dev local via une URL HTTPS publique, ce qui est utile pour la QA cross-réseau et mobile.
Le browser MCP est-il sécurisé ? Qu'est-ce qui empêche les abus ?
Le bridge bind sur 127.0.0.1 uniquement, jamais sur 0.0.0.0. Le port est attribué par l'OS (pas de port fixe propice au scanning de collision). Un token hex de 32 octets est requis sur chaque connexion, régénéré à chaque boot desktop. Le sous-process MCP reçoit les credentials uniquement via variables d'env, jamais dans un fichier commité. L'accès navigateur est opt-in par agent dans la modale Edit Agent. Si tu le retires, l'entrée .mcp.json est retirée et l'agent ne peut plus utiliser les outils.
L'agent voit-il la console du navigateur (errors, warnings, network) ?
Oui, via browser_get_logs. Le buffer contient les messages console.log, console.warn et console.error du main world de la page. Beaucoup de vrais bugs (erreurs d'hydratation React, warnings useEffect, échecs CORS) ne remontent que dans la console, jamais dans les tests unitaires, donc ça se révèle être un des outils les plus à fort signal pour l'agent QA.
Qu'est-ce qui se passe avec les screenshots retournés à l'agent ? Ils coûtent beaucoup de tokens ?
Après chaque action qui change la page, une capture PNG en base64 est appendée à la réponse de l'outil, plafonnée à 1.6 MB. Au-delà, un marqueur texte est envoyé à la place. Les screenshots sont critiques pour la fiabilité (un agent qui voit l'écran fait bien moins d'erreurs), donc le trade-off vaut le coup. Si tu veux désactiver les screenshots pour des raisons de budget, les appels browser_evaluate simples retournent du texte uniquement.
L'agent peut remplir un formulaire de connexion ? Persister sa session ?
Oui. Les cookies et le localStorage sont persistés par projet sous la session partition persist:agentsroom-browser-<projectId>. L'agent peut se connecter une fois avec browser_type et browser_click, et rester connecté sur le reste du run. Quand tu changes de projet, la session change, donc les credentials ne fuient jamais entre projets.
L'agent va casser si le serveur de dev ne tourne pas ?
Il navigue vers l'URL et voit une page d'erreur Chromium. Il peut lire cette erreur via browser_get_state et browser_get_logs et réagir en conséquence : te demander de démarrer le serveur, ou appeler une commande Dev Terminals pour le démarrer. Avec Agent Teams et Dev Terminals, tu peux câbler un workflow qui démarre le serveur, attend, puis ouvre le navigateur, le tout sans intervention humaine.
Les apps mobiles et desktop sont aussi supportées ?
Le web est livré aujourd'hui, à travers le Chromium intégré et le AgentsRoom Browser MCP. La roadmap inclut un AgentsRoom Browser natif comme feature browser first-class. Au-delà, des serveurs MCP supplémentaires sont prévus : un MCP React Native pour que les agents pilotent les bundles iOS et Android Expo, et un MCP Electron pour que les agents pilotent les apps desktop qui ne sont pas web. La même logique d'agent, appliquée à des cibles non-web.
L'humain peut mettre l'agent en pause et reprendre le navigateur ?
Oui. Le navigateur est la même vue Chromium que l'humain utilise. À tout moment, clique dans le panel Browser et tu prends le contrôle. Une fois que tu arrêtes d'interagir, l'agent peut reprendre ses appels d'outils. Il n'y a pas de concept de 'navigateur verrouillé par l'agent', c'est une surface partagée, exactement comme une session de pair programming.
Donne à tes agents de vrais yeux navigateur
Coche Browser access sur n'importe quel agent dans AgentsRoom. Le Browser MCP boote automatiquement. Ton agent QA teste enfin ce qu'il livre.
App companion : suivez vos agents en déplacement
Compatible avec Claude, Codex, OpenCode, Gemini CLI et Aider
Remontez bugs et demandes directement dans votre backlog public.