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 lässt. Dein QA-Agent öffnet deine localhost-Site, klickt die Buttons, füllt die Formulare, macht Screenshots, liest die Console und verifiziert, dass das Feature wirklich funktioniert, bevor er done sagt. End-to-End Browser-Automation für Claude, Codex, GitHub Copilot CLI, Cursor und 10 weiteren Agent-CLIs, mit null Playwright-Konfiguration.
Kombiniere es mit Agent Teams: ein Dev-Agent liefert das Feature, ein QA-Agent lädt die localhost-Site im eingebetteten Browser, führt das Verifizierungs-Szenario aus, screenshotet das Ergebnis und signiert ab. Native Browser-Automation ist ebenfalls auf der Roadmap, mit zukünftigen MCP-Servern für React Native und Electron Apps, damit Agenten auch Mobile- und Desktop-Apps testen können.
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 öffnen, persistente Cookies und localStorage pro Projekt. Zweitens, ein AgentsRoom Browser MCP Server (agentsroom-browser), der diesen Browser deinen KI-Agenten über das Model Context Protocol exponiert. Der Agent erhält 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 zerfällt, wenn der Agent 'Feature geliefert' sagt, aber nie die Seite öffnet, um nachzusehen. Die meisten Agenten heute verlassen sich darauf, Unit-Tests laufen zu lassen, und dann hoffen sie. Mit einem echten Browser MCP lädt der Agent den localhost-Server, durchläuft den User-Flow, sieht, was der menschliche Nutzer sehen würde, 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 für 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 verfügbaren 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 vollständige MCP-Steueroberfläche für KI-Agenten zum Navigieren, Klicken, Tippen und Verifizieren.
Ein echter Browser, kein Playwright-Stub
Die meisten KI-Agenten-Demos, die über Browser-Automation reden, nutzen eine bei jedem Tool-Call gespawnte headless Playwright-Instanz. Das funktioniert für Benchmarks, ist aber im realen Leben mühsam: 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 löst einen echten nativen Dispatch durch Electrons WebContentsView aus, mit echten Key-Events, Mouse-Events und DOM-Mutationen. Screenshots sind echte PNGs, erfasst von der tatsächlich gerenderten Seite (kein DOM-zu-Image-Hack). Console-Logs werden gepuffert und sind abfragbar, einschließlich Warnings und Errors. Der Agent sieht dasselbe, was du sehen würdest, wenn die DevTools geöffnet wären: 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 über. 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 abhängigkeitsfrei. Der browser-mcp-server.cjs Subprozess spricht das MCP 2024-11-05 Protokoll über stdio (initialize, tools/list, tools/call) und übersetzt es in JSON-RPC-Calls über 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 verändert (click, type, navigate, reload, back, forward), enthält 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 größte Reliability-Win heraus: Agenten, die den Bildschirm sehen, machen weit öfter das Richtige als Agenten, die hoffen.
Das Browser MCP Toolkit, das deine Agenten erhalten
Jeder KI-Agent mit Browser-Zugriff bootet mit diesen Tools verfügbar. Sie werden über Standard-MCP exponiert, sodass jede kompatible CLI sie sieht: Claude, Codex, GitHub Copilot CLI, Cursor und 10 weitere Agent-CLIs.
browser_navigate
Oeffnet eine URL im eingebetteten Browser. Smart-URL-Handling: localhost:3000 wird zu http://localhost:3000, statt einen 'cannot open application'-Dialog auszulösen. Gibt die finale URL und einen Screenshot der Seite nach dem Laden zurück.
browser_click
Klickt auf ein Element per Selektor oder per sichtbarem Text. Echtes natives Click-Event, kein JavaScript-Dispatch. Gibt den Post-Click-Screenshot zurück, damit der Agent das Ergebnis seiner Aktion sieht.
browser_type
Tippt Text in ein Input oder eine Textarea. Unterstützt Tastenkombinationen und Submit. Echte Key-Events, die onChange-Handler der Seite feuern. Gibt den Screenshot nach dem Tippen zurück.
browser_screenshot
Erfasst den aktuellen Viewport als PNG. Nützlich für Visual-Regression-Checks, Design-QA, Before-and-After-Vergleiche oder zum Teilen des Zustands eines Bugs mit dem Rest des Teams.
browser_evaluate
Führt einen JavaScript-Ausdruck im Main-World der Seite aus. Erhält das serialisierte Ergebnis zurück. Wird von Agenten genutzt, um den Page-State zu lesen, das DOM abzufragen, einen Redux-Store zu inspizieren oder eine Aktion auszulösen, die keinen sichtbaren Button hat.
browser_wait_for
Wartet darauf, dass ein Element erscheint, dass sich die URL ändert, dass eine Netzwerkanfrage abgeschlossen wird, oder dass beliebiges JavaScript true zurückgibt. 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 zugänglichen Elemente der Seite. Der primäre Input des Agenten, wenn er seine nächste 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 würdest. 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 zurückzugehen, wenn ein Flow schiefgeht, oder um eine Seite nach einem Hot-Reload von Vite, Next.js oder Expo Metro neu zu testen. Dieser Browser läuft mit deaktiviertem HTTP-Cache, sodass der Agent immer den neuesten Build sieht und nie ein veraltetes Bundle; useCache: true erlaubt den Cache für einen einzelnen Ladevorgang.
Was Agenten tatsächlich 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. Fängt Regressionen, bevor je ein Mensch die Seite öffnet.
Visual Regression QA
Before-and-After-Screenshots bei UI-Änderungen. Der Agent lädt 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 nächste Dev-Agent fixt sie.
Form-Validation-Testing
Der Agent füllt das Formular mit gültigen 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, prüft 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 lädt den Figma-Frame, screenshotet, lädt die localhost-Seite, screenshotet, vergleicht Abstände, Schriften, Farben, Ausrichtungen. Reicht eine Liste von Abweichungen ein.
Live-Preview-Tunnel-Verifizierung
Kombiniere mit dem AgentsRoom localhost Tunnel. Der Agent navigiert zur öffentlichen HTTPS-Preview-URL (nicht localhost), verifiziert, dass die Site von außen erreichbar ist, screenshotet und bestätigt, dass ein Stakeholder den Link tatsächlich öffnen kann.
Reproduzieren eines Kundenbugs aus einem Public-Backlog-Ticket
Public-Backlog-Ticket kommt mit URL und Reproschritten rein. Der QA-Agent öffnet die URL, folgt den Schritten, erfasst den Console-Error, hängt den Screenshot an, übergibt an Dev mit einer sauberen Repro. Keine 'cannot reproduce'-Loops mehr.
Zeig auf ein Element und schick es direkt an den Agenten
Den Browser zu steuern ist nur die halbe Miete. Manchmal bist du es, der das Problem entdeckt: ein schief ausgerichteter Button, ein Label mit falschem Text, eine Karte, die auf dem Handy bricht. Statt es in Worten zu beschreiben, zeigst du darauf. Der integrierte Browser hat einen Zeigemodus: Klick auf ein beliebiges Element der Seite und AgentsRoom erfasst seinen exakten CSS-Selektor aus dem Live-DOM.
Füge eine kurze Notiz hinzu wie „diesen Abstand enger machen“ oder „falsche Farbe hier“, und das markierte Element samt deiner Anmerkung geht als präzise, eindeutige Änderungsanfrage an den aktiven Agenten. Schluss mit „die dritte Karte von links“: Der Agent bekommt den Selektor, den umgebenden Kontext und deine Absicht in einem Schritt.
Zeigemodus im AgentsRoom-Browser: Klick auf ein Element, füge eine Notiz hinzu, und der exakte Selektor samt deiner Anmerkung gehen als markierte Änderung an den Agenten.
Zeigemodus aktivieren
Öffne den integrierten Browser auf deiner App und klick den Zeige-Button. Jedes Element hebt sich beim Überfahren hervor.
Element anklicken
Klick auf den Button, Textblock oder die Karte, die du ändern willst. AgentsRoom fixiert das Element und liest seinen exakten CSS-Selektor aus dem Live-DOM.
Notiz hinzufügen und senden
Tippe, was sich ändern soll, und bestätige. Der Selektor, der umgebende Kontext und deine Notiz gehen als markierte Änderung an den aktiven Agenten.
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 wähle 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 nächsten Start.
<project>/.mcp.jsonDer Agent bootet mit dem Browser MCP
Beim Agent-Spawn initialisiert Claude (oder Codex, Antigravity, 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 seitenverändernden Aktion wird inline ein Screenshot zurückgegeben, damit der Agent seinen Schritt visuell verifiziert.
Auto-Targeting localhost oder dein Tunnel
Wenn ein localhost-Tunnel läuft, 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 buchstäblich den Dev-Server, öffnet ihn dann im Browser und testet ihn dann.
Verifizieren, screenshoten, übergeben
Wenn in Agent Teams verdrahtet, führt der QA-Node seine Szenarien aus, erfasst Screenshots, setzt flags.qaPassed im Handoff-Payload. Der nächste Agent erbt das Verdikt. Pass geht zum PM, Fail zurück zum Dev mit den Test-Hinweisen.
Unter der Haube
Für die Neugierigen. Der Browser-Automation-Stack ist absichtlich klein.
Jedes Projekt hat eine Chromium WebContentsView (die moderne Electron-API, nicht die deprecated BrowserView), überlagert auf dem Hauptfenster mit Bounds, gestreamt vom React-Renderer. Pro-Projekt-Session-Partition hält Cookies, localStorage und Authentifizierung zwischen Projekten isoliert. Default Off-Screen-Bounds lassen Agenten Browser-Tools aufrufen, sogar bevor der Mensch den Browser-Tab öffnet, mit einem 5-Sekunden-Timeout auf Screenshots, um Hängen zu vermeiden.
Ein leichter WebSocket-Server (browser-bridge.ts) läuft auf einem vom OS gewählten 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 hält 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 abhängigkeitsfreies Node-Skript, das das MCP 2024-11-05 Protokoll über stdio implementiert (initialize, tools/list, tools/call). Es spricht JSON-RPC mit der WebSocket-Bridge über 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-Unterstützung (ein erstklassiges Browser-Feature über den MCP hinaus) ist auf der AgentsRoom Roadmap. Darüber hinaus enthält der Langzeitplan zusätzliche MCPs, damit Agenten auch Non-Web-Targets steuern können: ein React Native MCP für Mobile-Apps und ein Electron MCP für Desktop-Apps. Gleiche Idee, gleiche UX: der Agent schreibt nicht nur Code, er übt die laufende App tatsächlich 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 für 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, für den Nutzer in Echtzeit sichtbar. Der Agent steuert ein Fenster, das du sehen und jederzeit übernehmen kannst. Es ist eine ehrlichere, debuggbarere Browser-Automation.
Funktioniert das mit allen KI-Providern oder nur mit Claude Code?
Es funktioniert mit allen 14 Agent-CLIs, die AgentsRoom unterstützt: Claude Code, Codex CLI, GitHub Copilot CLI, Cursor und 10 weitere. Browser-Tools werden über das Standard Model Context Protocol exponiert, das alle diese CLIs aus .mcp.json lesen. Der Agent weiß niemals, dass er in AgentsRoom ist, er sieht einfach ein Set MCP-Tools und nutzt sie wie er jedes andere Tool nutzen würde.
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 geöffnet. 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 über eine öffentliche HTTPS-URL steuern, was nützlich für 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 einlädt). Ein 32-Byte-Hex-Token ist bei jeder Verbindung erforderlich, bei jedem Desktop-Boot regeneriert. Der MCP-Subprozess erhält die Credentials nur über 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 hält 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 signalstärksten Tools für den QA-Agenten herausstellt.
Was passiert mit den Screenshots, die an den Agenten zurückgegeben werden? Kosten sie viele Tokens?
Nach jeder seitenverändernden Aktion wird ein Base64-PNG-Screenshot an die Tool-Response angehängt, gedeckelt bei 1.6 MB. Darüber wird stattdessen ein Text-Marker gesendet. Screenshots sind kritisch für Reliability (ein Agent, der den Bildschirm sieht, macht weit weniger Fehler), sodass der Trade-off es wert ist. Wenn du Screenshots aus Budget-Gründen deaktivieren willst, geben einfache browser_evaluate-Calls nur Text zurück.
Kann der Agent ein Login-Formular ausfüllen? 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 für den Rest des Runs eingeloggt bleiben. Wenn du das Projekt wechselst, ändert sich die Session, sodass Credentials niemals zwischen Projekten überlaufen.
Bricht der Agent, wenn der Dev-Server nicht läuft?
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 öffnet, alles ohne menschliches Eingreifen.
Werden Mobile- und Desktop-Apps auch unterstützt?
Web ist heute ausgeliefert, durch das eingebettete Chromium und den AgentsRoom Browser MCP. Die Roadmap enthält einen nativen AgentsRoom Browser als erstklassiges Browser-Feature. Darüber hinaus sind zusätzliche 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 übernehmen?
Ja. Der Browser ist dieselbe Chromium-View, die der Mensch nutzt. Klicke jederzeit ins Browser-Panel und du hast die Kontrolle. Sobald du aufhörst zu interagieren, kann der Agent seine Tool-Calls fortsetzen. Es gibt kein Konzept von 'Agent-gesperrtem Browser', es ist eine geteilte Oberfläche, genau wie eine Pair-Programming-Session.
Über : Agent-Delegation
Lass einen günstigeren QA-Agenten den Browser fahren, nicht deinen Dev-Agenten
Das Browser MCP glänzt am hellsten, wenn der Dev-Agent es nicht direkt fährt. Agent-Delegation routet den Browser-Test über einen einzigen run_qa_test MCP-Aufruf an einen separaten, günstigeren QA-Agenten. Dein Opus oder Codex bleibt auf den Code fokussiert, der QA-Agent macht die Klicks auf einem kleineren Modell, das Verdict kommt als eine Zeile zurück. Gleiches Browser MCP, leichtere Rechnung, sauberer Context.
Zur Agent-Delegation SeiteGib 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
Nutzen Sie Claude, Codex, Antigravity CLI oder einen anderen KI-Anbieter.
Bugs und Wünsche direkt in dein öffentliches Backlog schicken.
Ein Blick auf AgentsRoom in Aktion.