browser-control: ein Rust-CLI, das Chrome über CDP als Shell-Pipe bereitstellt

Welche Lücke das Projekt adressiert

Viele Agenten können bereits Shell-Kommandos ausführen, aber nicht ohne Weiteres einen Browser bedienen. Die üblichen Wege dorthin verlangen etwas Zusätzliches: ein SDK in einer bestimmten Sprache, einen MCP-Server, einen dauerhaft laufenden Dienst, den jemand überwachen muss. browser-control setzt an dieser Stelle an und macht jede Fähigkeit zu einem Unterkommando, das kompakten Text oder JSON ausgibt. Das README formuliert die Zielgruppe direkt: der Coding-Agent bleibt der Agent, das Werkzeug liefert ihm Hände und Augen. Die Adressaten sind damit weniger QA-Teams als Betreiber von Agenten, die bereits über eine Shell mit ihrer Umgebung sprechen. Der Ansatz hat eine klare Grenze: er verschiebt die Orchestrierung in den Agenten. Wer eine deklarative Testbeschreibung mit Assertions erwartet, findet sie hier nicht.

Refs statt handgeschriebener Selektoren

Der interessanteste Teil ist der Snapshot. Nach browser-control snapshot gibt das Kommando nummerierte Handles zurück, etwa @e1 für ein input#search oder @e2 für einen Link mit dem Text Get started. Aktionen nehmen diese Handles direkt entgegen, also click @e3. Das ist eine bewusste Entscheidung gegen den üblichen Weg, bei dem ein Modell CSS-Selektoren aus dem DOM erraten muss. Das README nennt die Alternative ausdrücklich: CSS-Selektoren und x,y-Koordinaten funktionieren weiterhin, wenn man sie braucht. Die drei Zielstile sind nicht gleichwertig. Ein Ref ist nur so lange gültig, wie die Seite nicht neu gerendert wird; das ist eine Einschränkung, die man beim Bauen von Abläufen einplanen muss. Koordinaten bleiben der Ausweg für Canvas und Karten, wo es keinen stabilen Knoten gibt. Für eval gilt eine kleine Besonderheit: ein return auf oberster Ebene wird in eine IIFE verpackt, sodass eval 'const x = 1; return x' so funktioniert, wie es dasteht.

Wie der Datenfluss zwischen CLI, Daemon und Browser läuft

Das CLI spricht über das Chrome DevTools Protocol mit einem echten Browser. Die Verbindung lässt sich auf zwei Weisen herstellen. Entweder startet browser-control launch selbst eine Chrome-Instanz, oder man zeigt auf einen bereits laufenden Endpunkt. Dafür sind die Umgebungsvariablen BROWSER_CONTROL_CDP_URL und BROWSER_CONTROL_CDP_WS vorgesehen, mit den Kurzaliasen BU_CDP_URL und BU_CDP_WS. Im Hintergrund hält ein verborgener Daemon In-Memory-Ringe für Events, Netzwerkanfragen und Konsolenausgaben. Diese Ringe sind die Quelle der Unterkommandos events, network und console. Das erklärt, warum die Ringe begrenzt sind: es ist ein Puffer, kein Archiv. Wer den Verlauf vollständig braucht, muss ihn selbst mitschneiden. Zusätzlich legt jede fehlgeschlagene Aktion eine kompakte Spur unter .browser-control/traces/ ab, damit ein Agent sich selbst diagnostizieren kann. Das ist der Teil, der den Agenten-Bezug ernst nimmt, denn ein Fehler liefert damit Kontext statt nur eines Exit-Codes.

Installation und erste Schritte

Der Crate-Name weicht vom Kommandonamen ab: cargo install browser-control-cli installiert das Binary browser-control, weil der kürzere Name auf crates.io bereits vergeben war. Wer keine Rust-Toolchain möchte, lädt ein vorgebautes Archiv aus dem neuesten GitHub-Release, entpackt es und legt das Binary mit install -m 0755 nach /usr/local/bin/. Aus dem Quelltext heraus sind es drei Schritte: klonen, rustup toolchain install für die in rust-toolchain.toml festgelegte Version, dann cargo build --locked --release. Danach folgt browser-control --version als Gegenprobe. Der typische Ablauf beginnt mit browser-control init für den Workspace, dann browser-control launch https://example.com, gefolgt von browser-control doctor, das Endpunkt, Browser, gestartete PID, Daemon und Workspace meldet. Erst danach lohnt sich snapshot, click oder eval. Für reproduzierbare Läufe empfiehlt das README ausdrücklich --locked, sowohl für cargo build als auch für cargo test, und nennt scripts/verify.sh als Ein-Kommando-Prüfung.

Was das CLI nicht leistet

Es gibt keine Testabstraktion. Keine Assertions, keine Wiederholungslogik auf Suite-Ebene, keine Berichte. Das ist kein Versäumnis, sondern die Konsequenz daraus, dass jede Fähigkeit ein Unterkommando ist. Wer Flakiness über viele Läufe hinweg auswerten will, muss diese Logik selbst schreiben. Der Daemon ist ein weiterer Punkt, an dem man genau hinsehen sollte. Er hält Zustand im Speicher, und das README beschreibt die Ringe als begrenzt; wie groß sie sind, geht aus dem Material nicht hervor. Ebenso bleibt offen, wie sich der Daemon bei mehreren gleichzeitigen Agentenprozessen verhält. Ein weiteres Risiko liegt in der Versionslage: die letzten Releases sind v0.1.1 vom 21. Juni 2026 und v0.1.0 vom 20. Juni 2026. Eine 0.1er-Reihe bedeutet, dass sich Kommando-Oberflächen ändern können. Wer das CLI in eine feste Agenten-Pipeline einbaut, sollte die Version pinnen, statt ungeprüft zu aktualisieren.

Abgrenzung zu Playwright und Puppeteer

Playwright und Puppeteer sind Bibliotheken. Man schreibt Code in JavaScript, TypeScript, Python oder Java, importiert das Paket und ruft innerhalb eines Test- oder Skriptprozesses Funktionen auf. Der Browser läuft dabei im selben Prozessmodell wie das Skript. browser-control dreht das um: der Browser ist ein externer Dienst, das CLI ist ein Client, und der Aufrufer ist eine Shell. Der praktische Unterschied zeigt sich beim Fehlerfall. In einer Bibliothek fängt man eine Exception und entscheidet im Code, was passiert. Beim CLI entscheidet der Agent anhand des Exit-Codes und der abgelegten Trace-Datei. Ein zweiter Unterschied ist die Selektionsstrategie. Playwright und Puppeteer arbeiten mit Locators auf Basis von CSS, Text oder Rollen. browser-control setzt mit @e1-Refs auf eine vom Snapshot erzeugte Nummerierung, die dem Modell das Raten ersparen soll. Das ist bequemer für Agenten und weniger ausdrucksstark für Menschen, die einen Selektor einmal sauber formulieren wollen.

Cloud-Endpunkte und Lizenz

Das README nennt Browser Use, Steel, Hyperbrowser und Browserbase als Anbieter, deren entfernte Sitzungen sich mit denselben Kommandos ansteuern lassen, sofern sie CDP sprechen. Der Mechanismus ist derselbe wie lokal: man setzt BROWSER_CONTROL_CDP_WS auf die WebSocket-URL der Sitzung und überspringt launch. Damit verschiebt sich die Fehlerquelle nach außen. Latenz, Verbindungsabbrüche und Sitzungsgrenzen liegen beim Anbieter, nicht beim CLI. Für die Reproduzierbarkeit ist das ein spürbarer Unterschied zum lokalen Chrome, weil die Umgebung dann nicht mehr vollständig unter eigener Kontrolle steht. Zur Lizenz: das Projekt steht unter MIT. Das erlaubt kommerzielle Nutzung und Modifikation, verlangt aber, dass der Urheberrechtshinweis und der Lizenztext beibehalten werden. Das ist eine Einordnung, keine Rechtsberatung; wer das Binary weiterverteilt, sollte den Lizenztext mitliefern. Ein Hinweis auf Support-Zusagen oder einen Wartungsplan findet sich im Material nicht.

Redaktionelles Fazit

Wer einen Coding-Agenten hat, der ohnehin Shell-Kommandos ausführt, und Chrome lokal oder über einen CDP-Anbieter ansprechen will, bekommt hier einen kleinen, prüfbaren Baustein: cargo install browser-control-cli, dann browser-control init und browser-control doctor, um Endpunkt, Browser, PID, Daemon und Workspace zu sehen. Wer eine Test-Suite mit Assertions, Retry-Logik und HTML-Reports braucht, ist hier falsch und sollte bei Playwright oder Puppeteer bleiben. Vor dem Produktiveinsatz zuerst klären, ob der Daemon und die In-Memory-Ringe events, network und console unter der Last des eigenen Ablaufs noch brauchbare Daten liefern, und ob die Trace-Ablage unter .browser-control/traces/ in die eigene Aufbewahrungsregel passt.

Offizielle Quellen

1. Issues
2. keon/browser-control on GitHub
3. License: MIT
4. README
5. Releases