Deine Agenten steuern einen echten Browser.
Keinen Fake.
AgentsRoom bettet einen echten Chromium-Browser in jedes Projekt ein und liefert einen AgentsRoom Browser MCP Server, der deine KI-Agenten ihn steuern laesst. Dein QA-Agent oeffnet deine localhost-Site, klickt die Buttons, fuellt die Formulare, macht Screenshots, liest die Console und verifiziert, dass das Feature wirklich funktioniert, bevor er done sagt. End-to-End Browser-Automation fuer Claude Code, Codex, OpenCode, Gemini CLI und Aider, mit null Playwright-Konfiguration.
Kombiniere es mit Agent Teams: ein Dev-Agent liefert das Feature, ein QA-Agent laedt die localhost-Site im eingebetteten Browser, fuehrt das Verifizierungs-Szenario aus, screenshotet das Ergebnis und signiert ab. Native Browser-Automation ist ebenfalls auf der Roadmap, mit zukuenftigen MCP-Servern fuer React Native und Electron Apps, damit Agenten auch Mobile- und Desktop-Apps testen koennen.
AgentsRoom Browser MCP Demo: End-to-End Web-App-Testing, gesteuert von einem Claude Code QA-Agenten durch den eingebetteten Chromium-Browser.
Browser Automation in AgentsRoom sind zwei Dinge in einem. Erstens, ein echter Chromium-Browser, eingebettet in jeder Projekt-Room, mit URL-Leiste, Back/Forward, Reload, Verlauf, Screenshot in die Zwischenablage, in Standard-Browser oeffnen, persistente Cookies und localStorage pro Projekt. Zweitens, ein AgentsRoom Browser MCP Server (agentsroom-browser), der diesen Browser deinen KI-Agenten ueber das Model Context Protocol exponiert. Der Agent erhaelt eine saubere, scriptbare Schnittstelle: navigate, click, type, screenshot, evaluate JavaScript, wait for an element, get the page state, get the console logs, go back, go forward, reload.
Warum ist das wichtig? Weil das gesamte Versprechen der KI-Coding-Agenten zerfaellt, wenn der Agent 'Feature geliefert' sagt, aber nie die Seite oeffnet, um nachzusehen. Die meisten Agenten heute verlassen sich darauf, Unit-Tests laufen zu lassen, und dann hoffen sie. Mit einem echten Browser MCP laedt der Agent den localhost-Server, durchlaeuft den User-Flow, sieht, was der menschliche Nutzer sehen wuerde, und erst dann signiert er ab. Die QA Engineer Agentenrolle hat endlich die Tools, die sie braucht, um echte QA zu machen, nicht nur statische Analyse.
Das technische Setup ist fuer dich unsichtbar. Wenn du 'Browser access' an einem Agenten ankreuzt, merged AgentsRoom den agentsroom-browser-Eintrag in die .mcp.json deines Projekts und der Agent bootet mit verfuegbaren Browser-Tools. Eine WebSocket-Bridge auf einem Loopback-Port (127.0.0.1, OS-zugewiesen, bei jedem Boot regeneriert, mit einem 32-Byte-Hex-Token authentifiziert) verbindet den MCP-Subprozess mit der Chromium WebContentsView in der Electron-App. Jeder Klick, jede Eingabe, jeder Screenshot ist ein JSON-RPC-Call. Der Agent sieht einen echten Browser, keinen Stub.
AgentsRoom Browser-Panel: URL-Leiste, Verlauf, Screenshot und vollstaendige MCP-Steueroberflaeche fuer KI-Agenten zum Navigieren, Klicken, Tippen und Verifizieren.
Ein echter Browser, kein Playwright-Stub
Die meisten KI-Agenten-Demos, die ueber Browser-Automation reden, nutzen eine bei jedem Tool-Call gespawnte headless Playwright-Instanz. Das funktioniert fuer Benchmarks, ist aber im realen Leben muehsam: du siehst nicht, was der Agent macht, jede Navigation respawnt Chromium, Cookies gehen verloren, localStorage ist leer, dein Dev-Server denkt, jeder Besuch sei eine brandneue Session. AgentsRoom nimmt einen anderen Blickwinkel. Der Browser ist bereits in deiner Projekt-Room offen (du nutzt ihn selbst, wie einen normalen Browser), und der Agent steuert diesen Browser. Sessions, Cookies, localStorage, Login-Status, alles erhalten.
Jeder Klick und jede Eingabe vom Agenten loest einen echten nativen Dispatch durch Electrons WebContentsView aus, mit echten Key-Events, Mouse-Events und DOM-Mutationen. Screenshots sind echte PNGs, erfasst von der tatsaechlich gerenderten Seite (kein DOM-zu-Image-Hack). Console-Logs werden gepuffert und sind abfragbar, einschliesslich Warnings und Errors. Der Agent sieht dasselbe, was du sehen wuerdest, wenn die DevTools geoeffnet waeren: echte Performance, echtes Netzwerkverhalten, echtes CORS, echte Auth.
Cross-Room-Isolation wird durchgesetzt. AgentsRoom erstellt eine Chromium WebContentsView pro Projekt, mit eigener Session-Partition (persist:agentsroom-browser-<projectId>). Die Cookies von Projekt A laufen niemals in Projekt B ueber. Wenn du das Projekt wechselst, wird der vorherige Browser ausgeblendet und der neue kommt mit eigenem State online. Der Agent landet immer im richtigen Projekt, mit den richtigen Credentials.
Die MCP-Schicht ist absichtlich klein und abhaengigkeitsfrei. Der browser-mcp-server.cjs Subprozess spricht das MCP 2024-11-05 Protokoll ueber stdio (initialize, tools/list, tools/call) und uebersetzt es in JSON-RPC-Calls ueber die Loopback-WebSocket-Bridge. Im Vergleich zu einem schweren SDK-basierten Server bleibt das schnell (erster Tool-Call unter 100ms) und einfach zu debuggen. Nach jeder Aktion, die die Seite veraendert (click, type, navigate, reload, back, forward), enthaelt die Antwort einen Base64-PNG-Screenshot, gedeckelt bei 1.6 MB, damit der Agent immer das Ergebnis dessen sieht, was er gerade getan hat. Das stellte sich als der einzelne groesste Reliability-Win heraus: Agenten, die den Bildschirm sehen, machen weit oefter das Richtige als Agenten, die hoffen.
Das Browser MCP Toolkit, das deine Agenten erhalten
Jeder KI-Agent mit Browser-Zugriff bootet mit diesen Tools verfuegbar. Sie werden ueber Standard-MCP exponiert, sodass jede kompatible CLI sie sieht: Claude Code, Codex CLI, OpenCode, Gemini CLI, Aider.
browser_navigate
Oeffnet eine URL im eingebetteten Browser. Smart-URL-Handling: localhost:3000 wird zu http://localhost:3000, statt einen 'cannot open application'-Dialog auszuloesen. Gibt die finale URL und einen Screenshot der Seite nach dem Laden zurueck.
browser_click
Klickt auf ein Element per Selektor oder per sichtbarem Text. Echtes natives Click-Event, kein JavaScript-Dispatch. Gibt den Post-Click-Screenshot zurueck, damit der Agent das Ergebnis seiner Aktion sieht.
browser_type
Tippt Text in ein Input oder eine Textarea. Unterstuetzt Tastenkombinationen und Submit. Echte Key-Events, die onChange-Handler der Seite feuern. Gibt den Screenshot nach dem Tippen zurueck.
browser_screenshot
Erfasst den aktuellen Viewport als PNG. Nuetzlich fuer Visual-Regression-Checks, Design-QA, Before-and-After-Vergleiche oder zum Teilen des Zustands eines Bugs mit dem Rest des Teams.
browser_evaluate
Fuehrt einen JavaScript-Ausdruck im Main-World der Seite aus. Erhaelt das serialisierte Ergebnis zurueck. Wird von Agenten genutzt, um den Page-State zu lesen, das DOM abzufragen, einen Redux-Store zu inspizieren oder eine Aktion auszuloesen, die keinen sichtbaren Button hat.
browser_wait_for
Wartet darauf, dass ein Element erscheint, dass sich die URL aendert, dass eine Netzwerkanfrage abgeschlossen wird, oder dass beliebiges JavaScript true zurueckgibt. Vermeidet die klassische 'Agent klickt zu schnell'-Race.
browser_get_state
Liest die aktuelle URL, den Titel, den Viewport, die Scroll-Position und einen strukturierten Snapshot der zugaenglichen Elemente der Seite. Der primaere Input des Agenten, wenn er seine naechste Aktion planen muss.
browser_get_logs
Holt den Console-Buffer (log, warn, error). Der Agent kann dieselben React-Warnings, Hydration-Errors, Netzwerkfehler und Runtime-Exceptions sehen, die du in den DevTools sehen wuerdest. Bug-Reports werden zu 'hier ist der Fehler aus der Console'.
browser_go_back / forward / reload
Standard-Browser-Navigation, scriptbar. Wird von Agenten genutzt, um zurueckzugehen, wenn ein Flow schiefgeht, oder um eine Seite nach einem Hot-Reload von Vite, Next.js oder Expo Metro neu zu testen.
Was Agenten tatsaechlich mit dem Browser machen
Echte Workflows, die du heute bauen kannst, mit der QA Engineer Rolle und Agent Teams.
End-to-End Smoke-Test bei jedem Handoff
Verdrahte ein Dev zu QA Team. Der QA-Agent navigiert zu deinem localhost Dev-Server, klickt durch die kritischen Pfade (Signup, Checkout, Dashboard), screenshotet das Ergebnis und signiert nur ab, wenn nichts wirft. Faengt Regressionen, bevor je ein Mensch die Seite oeffnet.
Visual Regression QA
Before-and-After-Screenshots bei UI-Aenderungen. Der Agent laedt die Seite auf dem vorherigen Commit, screenshotet, wechselt Branch, screenshotet, bittet Claude zu vergleichen. Billiges Visual-Diff-QA ohne Percy oder Chromatic in der Schleife.
Console-Error-Jagd
Der Agent navigiert die App, ruft browser_get_logs auf, findet React-Hydration-Warnings, useEffect-Warnings, Netzwerk-404s, CORS-Errors, Deprecation-Notices. Meldet sie als Liste von Risiken im Team-Handoff-Payload, der naechste Dev-Agent fixt sie.
Form-Validation-Testing
Der Agent fuellt das Formular mit gueltigen Daten, mit leeren Feldern, mit Edge-Cases (XSS-Strings, sehr lange Inputs, Non-ASCII). Verifiziert die Validierungsmeldungen, die Netzwerkanfragen, die Redirects. Echte Form-QA, keine Unit-Tests.
Accessibility-Audit
Der Agent durchschreitet die Seite, fragt den Accessibility-Tree via browser_get_state und browser_evaluate ab, prueft Alt-Texte, ARIA-Attribute, Focus-Management, Tastaturnavigation. Meldet Probleme mit Screenshots.
Design-QA gegen Figma
Kombiniere mit dem Figma-zu-KI-Agenten-Feature. Der Agent laedt den Figma-Frame, screenshotet, laedt die localhost-Seite, screenshotet, vergleicht Abstaende, Schriften, Farben, Ausrichtungen. Reicht eine Liste von Abweichungen ein.
Live-Preview-Tunnel-Verifizierung
Kombiniere mit dem AgentsRoom localhost Tunnel. Der Agent navigiert zur oeffentlichen HTTPS-Preview-URL (nicht localhost), verifiziert, dass die Site von aussen erreichbar ist, screenshotet und bestaetigt, dass ein Stakeholder den Link tatsaechlich oeffnen kann.
Reproduzieren eines Kundenbugs aus einem Public-Backlog-Ticket
Public-Backlog-Ticket kommt mit URL und Reproschritten rein. Der QA-Agent oeffnet die URL, folgt den Schritten, erfasst den Console-Error, haengt den Screenshot an, uebergibt an Dev mit einer sauberen Repro. Keine 'cannot reproduce'-Loops mehr.
Wie ein Agent einen Browser bekommt
Oeffne den Browser-Tab in deiner Room
In deiner Projekt-Room exponiert das rechte Panel drei Tabs: Files, Changes, Browser. Klicke Browser. Das Panel verbreitert sich, die Sidebar klappt ein, und eine echte Chromium-View erscheint. Tippe eine URL oder waehle aus dem Projekt-Verlauf.
Kreuze 'Browser access' am Agenten an
Oeffne die Edit-Agent-Modal, expandiere Capabilities, kreuze Browser access an. AgentsRoom merged den agentsroom-browser-Eintrag in die .mcp.json deines Projekts und der Agent sieht die Browser-Tools beim naechsten Start.
<project>/.mcp.jsonDer Agent bootet mit dem Browser MCP
Beim Agent-Spawn initialisiert Claude (oder Codex, Gemini, etc.) den agentsroom-browser MCP-Server, listet seine 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), und kann ab jetzt den Browser steuern.
Der Agent nutzt den Browser
Der Agent navigiert, klickt, tippt, screenshotet, liest Console. Jede Aktion geht durch eine Loopback-WebSocket-Bridge (127.0.0.1, OS-zugewiesener Port, 32-Byte-Hex-Token, bei jedem Boot der Desktop-App regeneriert). Nach jeder seitenveraendernden Aktion wird inline ein Screenshot zurueckgegeben, damit der Agent seinen Schritt visuell verifiziert.
Auto-Targeting localhost oder dein Tunnel
Wenn ein localhost-Tunnel laeuft, landet die erste Navigation auf der Tunnel-URL. Sonst auf dem ersten erkannten Dev-Server. Sonst https://localhost:3000. Kombiniert mit Dev Terminals startet der Agent buchstaeblich den Dev-Server, oeffnet ihn dann im Browser und testet ihn dann.
Verifizieren, screenshoten, uebergeben
Wenn in Agent Teams verdrahtet, fuehrt der QA-Node seine Szenarien aus, erfasst Screenshots, setzt flags.qaPassed im Handoff-Payload. Der naechste Agent erbt das Verdikt. Pass geht zum PM, Fail zurueck zum Dev mit den Test-Hinweisen.
Unter der Haube
Fuer die Neugierigen. Der Browser-Automation-Stack ist absichtlich klein.
Jedes Projekt hat eine Chromium WebContentsView (die moderne Electron-API, nicht die deprecated BrowserView), ueberlagert auf dem Hauptfenster mit Bounds, gestreamt vom React-Renderer. Pro-Projekt-Session-Partition haelt Cookies, localStorage und Authentifizierung zwischen Projekten isoliert. Default Off-Screen-Bounds lassen Agenten Browser-Tools aufrufen, sogar bevor der Mensch den Browser-Tab oeffnet, mit einem 5-Sekunden-Timeout auf Screenshots, um Haengen zu vermeiden.
Ein leichter WebSocket-Server (browser-bridge.ts) laeuft auf einem vom OS gewaehlten Loopback-Port, nur an 127.0.0.1 gebunden. Authentifizierung nutzt einen 32-Byte-Hex-Token, der bei jedem Desktop-Boot regeneriert wird. Die Bridge-Datei ~/.agentsroom/browser-bridge.json haelt den aktuellen Port, Token und PID, atomar bei jedem Boot neu geschrieben, sodass der MCP-Subprozess immer frische Credentials mit automatischem Retry abholt.
Der MCP-Server selbst ist browser-mcp-server.cjs, ein abhaengigkeitsfreies Node-Skript, das das MCP 2024-11-05 Protokoll ueber stdio implementiert (initialize, tools/list, tools/call). Es spricht JSON-RPC mit der WebSocket-Bridge ueber einen handgerollten WebSocket-Client (kein ws, kein @modelcontextprotocol/sdk). Klein, schnell, einfach zu auditieren. Als extraResources-Datei in der Desktop-App gebundelt, sodass jede Installation damit ready-to-go ausgeliefert wird.
Native Browser-Unterstuetzung (ein erstklassiges Browser-Feature ueber den MCP hinaus) ist auf der AgentsRoom Roadmap. Darueber hinaus enthaelt der Langzeitplan zusaetzliche MCPs, damit Agenten auch Non-Web-Targets steuern koennen: ein React Native MCP fuer Mobile-Apps und ein Electron MCP fuer Desktop-Apps. Gleiche Idee, gleiche UX: der Agent schreibt nicht nur Code, er uebt die laufende App tatsaechlich aus.
FAQ
Wie unterscheidet sich das von Playwright MCP oder Puppeteer-basierten Browser-Tools?
Playwright- und Puppeteer-basierte MCPs spawnen bei jeder Session einen frischen headless Browser. Das ist okay fuer zustandslose Aufgaben, aber es verliert Cookies, localStorage und Auth zwischen Calls, und der Mensch kann nicht sehen, was der Agent macht. AgentsRoom Browser ist derselbe Browser, den der Mensch in der App nutzt, mit persistenter Pro-Projekt-Session, fuer den Nutzer in Echtzeit sichtbar. Der Agent steuert ein Fenster, das du sehen und jederzeit uebernehmen kannst. Es ist eine ehrlichere, debuggbarere Browser-Automation.
Funktioniert das mit allen KI-Providern oder nur mit Claude Code?
Es funktioniert mit jedem von AgentsRoom unterstuetzten Provider: Claude Code, Codex CLI, OpenCode, Gemini CLI und Aider. Browser-Tools werden ueber das Standard Model Context Protocol exponiert, das alle diese CLIs aus .mcp.json lesen. Der Agent weiss niemals, dass er in AgentsRoom ist, er sieht einfach ein Set MCP-Tools und nutzt sie wie er jedes andere Tool nutzen wuerde.
Kann der Agent eine Remote-Site steuern oder nur localhost?
Beides. Tippe irgendeine URL und go. Localhost (und host:port-Formen) werden smart erkannt, mit http:// vorangestellt und direkt geoeffnet. Public-Sites funktionieren wie in jedem normalen Browser, mit Cookies und Login-Status pro Projekt erhalten. Kombiniert mit dem AgentsRoom localhost Tunnel kann der Agent auch deinen lokalen Dev-Server ueber eine oeffentliche HTTPS-URL steuern, was nuetzlich fuer Cross-Network- und Mobile-QA ist.
Ist der Browser MCP sicher? Was verhindert Missbrauch?
Die Bridge bindet nur an 127.0.0.1, niemals an 0.0.0.0. Der Port ist OS-zugewiesen (kein fixer Port, der zum Kollisions-Scanning einlaedt). Ein 32-Byte-Hex-Token ist bei jeder Verbindung erforderlich, bei jedem Desktop-Boot regeneriert. Der MCP-Subprozess erhaelt die Credentials nur ueber Env-Variablen, niemals in einer committeten Datei. Browser-Zugriff ist pro Agent in der Edit-Agent-Modal opt-in. Wenn du es entfernst, wird der .mcp.json-Eintrag entfernt und der Agent kann die Tools nicht mehr nutzen.
Sieht der Agent die Browser-Console (Errors, Warnings, Network)?
Ja, via browser_get_logs. Der Buffer haelt console.log, console.warn und console.error Messages aus dem Main-World der Seite. Viele echte Bugs (React-Hydration-Errors, useEffect-Warnings, CORS-Failures) tauchen nur in der Console auf, nie in Unit-Tests, sodass sich das als eines der signalstaerksten Tools fuer den QA-Agenten herausstellt.
Was passiert mit den Screenshots, die an den Agenten zurueckgegeben werden? Kosten sie viele Tokens?
Nach jeder seitenveraendernden Aktion wird ein Base64-PNG-Screenshot an die Tool-Response angehaengt, gedeckelt bei 1.6 MB. Darueber wird stattdessen ein Text-Marker gesendet. Screenshots sind kritisch fuer Reliability (ein Agent, der den Bildschirm sieht, macht weit weniger Fehler), sodass der Trade-off es wert ist. Wenn du Screenshots aus Budget-Gruenden deaktivieren willst, geben einfache browser_evaluate-Calls nur Text zurueck.
Kann der Agent ein Login-Formular ausfuellen? Seine Session persistieren?
Ja. Cookies und localStorage werden pro Projekt unter der Session-Partition persist:agentsroom-browser-<projectId> persistiert. Der Agent kann sich einmal mit browser_type und browser_click einloggen und fuer den Rest des Runs eingeloggt bleiben. Wenn du das Projekt wechselst, aendert sich die Session, sodass Credentials niemals zwischen Projekten ueberlaufen.
Bricht der Agent, wenn der Dev-Server nicht laeuft?
Er wird zur URL navigieren und eine Chromium-Fehlerseite sehen. Er kann diesen Fehler via browser_get_state und browser_get_logs lesen und entsprechend reagieren: dich bitten, den Server zu starten, oder einen Dev-Terminals-Befehl aufrufen, um ihn zu starten. Mit Agent Teams und Dev Terminals kannst du einen Workflow verdrahten, der den Server startet, wartet, dann den Browser oeffnet, alles ohne menschliches Eingreifen.
Werden Mobile- und Desktop-Apps auch unterstuetzt?
Web ist heute ausgeliefert, durch das eingebettete Chromium und den AgentsRoom Browser MCP. Die Roadmap enthaelt einen nativen AgentsRoom Browser als erstklassiges Browser-Feature. Darueber hinaus sind zusaetzliche MCP-Server geplant: ein React Native MCP, damit Agenten iOS- und Android-Expo-Bundles steuern, und ein Electron MCP, damit Agenten Desktop-Apps steuern, die nicht Web sind. Dieselbe Agent-Logik, angewandt auf Non-Web-Targets.
Kann der Mensch den Agenten pausieren und den Browser uebernehmen?
Ja. Der Browser ist dieselbe Chromium-View, die der Mensch nutzt. Klicke jederzeit ins Browser-Panel und du hast die Kontrolle. Sobald du aufhoerst zu interagieren, kann der Agent seine Tool-Calls fortsetzen. Es gibt kein Konzept von 'Agent-gesperrtem Browser', es ist eine geteilte Oberflaeche, genau wie eine Pair-Programming-Session.
Gib deinen Agenten echte Browser-Augen
Kreuze Browser access an irgendeinem Agenten in AgentsRoom an. Der Browser MCP bootet automatisch. Dein QA-Agent testet endlich, was er liefert.
Companion-App: Agenten auch unterwegs im Blick behalten
Funktioniert mit Claude, Codex, OpenCode, Gemini CLI und Aider
Bugs und Wünsche direkt in dein öffentliches Backlog schicken.