BrowserOS: zwei Chromium-Browser, ein Agenten-Protokoll und der AGPL-Preis

Welches Problem der zweite Browser löst

Die meisten Agenten scheitern nicht am Modell, sondern am Login. Playwright und ähnliche Treiber starten laut README eine frische Chrome-Subprozess-Instanz ohne Sitzung. Für CI-Läufe ist das richtig, für "lies mein Postfach" nutzlos. Cloud-Browser wie browser-use oder browserbase laufen in einem Rechenzentrum, weshalb Dienste wie Twitter und LinkedIn Verbindungen von Rechenzentrums-IPs blockieren. BrowserOS neo setzt dagegen auf einen zweiten Browser neben Chrome, der die Logins per Ein-Klick-Import übernimmt und sie über Sitzungen hinweg hält. Die Zielgruppe ist eng umrissen: Leute, die Claude Code, Codex, Cursor oder einen anderen MCP-Agenten schon benutzen und ihm jetzt eine angemeldete Browsersitzung geben wollen, ohne ihre Zugangsdaten an einen fremden Dienst zu übergeben.

MCP als eigentliche Schnittstelle, nicht das Modell

Der Agent steckt nicht in BrowserOS neo, sondern kommt von außen. Das README beschreibt den Ablauf so: neo installieren, Logins aus Chrome importieren, das Tool erkennt vorhandene Harnesses wie Claude Code, Codex, Cursor, VS Code, OpenClaw oder Hermes und verbindet sie per Klick. Danach gibt man dem Agenten eine Aufgabe, etwa "Book me the cheapest flight to London", und sieht sie live im neuen Tab oder später als Aufzeichnung. Technisch ist das ein MCP-Server, den der Browser bereitstellt. Die Release-Liste trennt das sauber: agent-server/v0.0.162 und ext-agent/v0.0.154.0 werden unabhängig versioniert, die Extension und der Server können also getrennt aktualisiert werden. Wer schon einen MCP-fähigen Agenten betreibt, tauscht nur den Tool-Endpunkt aus. Wer keinen hat, muss erst einen einrichten, denn neo bringt kein eigenes Modell mit.

Was tatsächlich auf der Platte landet

Sitzungen, Screenshots und Verlauf liegen laut README unter ~/.browserclaw/ und verlassen die Maschine nicht. Jede Sitzung wird als scrubbares Video plus Aktions-Timeline gespeichert, man kann also zurückspulen und sehen, welchen Klick der Agent auf welcher Seite ausgeführt hat. Das ist der stärkste Teil des Designs, weil es die Fehlersuche bei nichtdeterministischen Abläufen überhaupt erst praktikabel macht. Es ist aber auch der Punkt, an dem man genauer hinsehen sollte: Ein Video jeder Sitzung bedeutet, dass Seiteninhalte und Formulareingaben im Klartext auf der Platte liegen. Das README nennt keinen Aufbewahrungszeitraum und keine Verschlüsselung dieser Dateien. Wer neo auf einem geteilten Rechner oder einem Laptop mit Full-Disk-Backup betreibt, sollte vorher klären, was ~/.browserclaw/ an einen Backup-Dienst weitergibt.

Parallelität und Token-Verbrauch

Mehrere Agenten laufen gleichzeitig, jeder in einem eigenen Tab, während man selbst weiter surft. Das ist eine bewusste Abkehr vom Ein-Sitzung-Modell der Chrome-Erweiterungen. Zum Token-Verbrauch sagt das README, neo brauche für dieselbe Aufgabe deutlich weniger Tokens als andere Lösungen wie Claudes Chrome-Erweiterung oder der Codex-Browser. Eine Zahl, eine Messmethode oder eine Aufgabenbeschreibung liefert das Material nicht. Diese Aussage ist also eine Herstellerangabe ohne Beleg und sollte bei der Auswahl nicht als Entscheidungsgrundlage dienen. Wer den Verbrauch wissen will, muss ihn mit seinem eigenen Agenten und seiner eigenen Aufgabe messen.

Der Hauptbrowser und die 20+ Tools

BrowserOS selbst ist ein anderer Artikel als neo. Es ist ein Chromium-Fork mit einem Agenten in jedem neuen Tab, der Seiten zusammenfasst, Klickpfade abarbeitet, Daten extrahiert oder geplante Aufgaben ausführt. Dafür nennt das README über 20 eingebaute Tools und mehr als 40 App-Integrationen. Man kann eigene API-Schlüssel mitbringen oder alles lokal über Ollama laufen lassen. Der Vertriebsweg unterscheidet sich grundlegend von neo: Hier wird der Browser selbst ersetzt, nicht ergänzt. Ein Chromium-Fork bedeutet, dass Sicherheitsupdates dem Upstream hinterherlaufen, solange die Maintainer nicht nachziehen. Wie groß dieser Abstand ist, lässt sich aus dem Material nicht ablesen, und die beiden letzten Releases betreffen ausschließlich agent-server und ext-agent, nicht den Fork selbst.

Installation und die Grenzen des Materials

Die Installation ist bewusst flach gehalten. Für macOS gibt es ein DMG, für Windows einen Installer, beide direkt vom Anbieter-CDN. Danach importiert neo in einem Schritt Logins, Lesezeichen und Erweiterungen aus Chrome. Der Agent verbindet sich über den MCP-Endpunkt, den neo bereitstellt. Konkrete Konfigurationsschlüssel, Ports oder Umgebungsvariablen nennt das vorliegende README nicht, es verweist für Details auf docs.browseros.com/neo. Wer neo in eine bestehende Agentenkonfiguration einhängen will, muss diese Dokumentation lesen, bevor er Aufwand einplant. Für den Fork BrowserOS gilt dasselbe: Das README ist an dieser Stelle eine Produktseite, keine Installationsanleitung. Auffällig ist auch, dass das README neo ausdrücklich als Ergänzung zu Chrome positioniert, nicht als Ersatz. Wer einen einzigen Browser will, ist hier falsch.

Wann ein headless-Treiber die bessere Wahl bleibt

Die ehrliche Alternative für viele Aufgaben ist Playwright. Der Unterschied liegt nicht in der Fähigkeit, Seiten zu bedienen, sondern im Zustand: Playwright startet eine saubere Instanz ohne Logins, BrowserOS neo erbt deine Sitzung. Für reproduzierbare Tests, Scraping ohne Anmeldung oder nächtliche Läufe auf einem Build-Server ist der saubere Zustand ein Vorteil, nicht ein Mangel. Umgekehrt ist neos geerbte Sitzung genau dann ein Risiko, wenn der Agent auf einem Konto arbeitet, das du nicht für Experimente freigeben willst. Ein zweiter Vergleichspunkt sind die Cloud-Browser: Sie lösen das Login-Problem über gehostete Profile, zahlen dafür aber mit der Rechenzentrums-IP und der Frage, wem das Profil gehört. neo wählt den umgekehrten Kompromiss. Es bleibt auf 127.0.0.1 und nimmt in Kauf, dass der Rechner laufen muss.

Lizenz und Wartungskosten

Beide Browser stehen unter AGPL-3.0. Diese Lizenz greift nicht nur bei Weitergabe von Binaries, sondern auch, wenn Nutzer über ein Netzwerk mit einer modifizierten Version interagieren. Wer neo oder den Fork in einen internen Dienst einbettet, den andere über das Netz erreichen, sollte die Lizenzfrage vor dem Rollout klären und nicht danach. Das ist keine Rechtsberatung, sondern nur der Hinweis, dass AGPL hier weiter reicht als MIT oder Apache-2.0. Zur Wartung: Die Release-Kadenz von agent-server und ext-agent ist dicht, v0.0.161 und v0.0.162 liegen am selben Tag. Solche Sprünge in der Null-Komma-Null-Reihe deuten auf schnelle Iteration hin, was bedeutet, dass man die Versionen von Extension und Server gemeinsam pflegen muss. Ob ältere Agenten-Clients nach einem Server-Update weiter funktionieren, sagt das Material nicht. Genau das ist die Frage, die man vor einem produktiven Einsatz zuerst beantworten sollte.

Redaktionelles Fazit

Nimm BrowserOS neo, wenn deine Agenten bereits über MCP laufen und du ihnen echte, importierte Logins geben willst, ohne sie in eine Cloud zu schicken. Nimm es nicht, wenn du eine headless-CI-Pipeline brauchst oder wenn du den Browser-Code in ein proprietäres Produkt einbetten willst, denn AGPL-3.0 verlangt bei Weitergabe oder Netzwerkbetrieb die Offenlegung des Quellcodes. Prüfe vor dem ersten Einsatz, ob die Dateien unter ~/.browserclaw/ auf deiner Maschine bleiben und welche Rechte das MCP-Tool deinem Agenten tatsächlich einräumt.

Offizielle Quellen

1. browseros-ai/BrowserOS on GitHub
2. License: AGPL-3.0
3. Project website
4. README
5. Releases