Browserbase mit OpenClaw: isolierte Cloud-Browser für Agentenläufe

Ein OpenClaw-Agent öffnet morgens dieselbe Verwaltungsseite wie am Vortag. Die Sitzung ist abgelaufen, ein Formular sieht plötzlich anders aus, und im Browser des Operators liegen noch private Tabs. Spätestens dann ist ein eigener Browserzustand keine Komfortfrage mehr, sondern Teil des Betriebsmodells.

Browserbase betreibt Browser-Sitzungen in der Cloud, getrennt vom persönlichen Arbeitsbrowser. Wer die Anbindung an OpenClaw plant, sollte zuerst den Integrationsweg prüfen: Das eigene Plugin @browserbasehq/openclaw-browserbase hat Browserbase laut GitHub am 28. Mai 2026 archiviert, das Repository ist seitdem schreibgeschützt. Die Browserbase-Dokumentation nennt für OpenClaw inzwischen zuerst das eingebaute Browser-Plugin von OpenClaw und als Alternative die Browserbase-CLI. Anleitungen, die noch openclaw plugins install @browserbasehq/openclaw-browserbase empfehlen, führen also auf einen eingefrorenen Pfad.

Getrennte Sitzungen verhindern Kollisionen

Bei wiederkehrender Web-Automation teilt sich ein Agent schnell mehr mit dem Operator als vorgesehen: Cookies, offene Tabs und eingeloggte Konten. Ein automatisierter Klick landet dann im falschen Zustand, oder ein manueller Login verändert unbemerkt den nächsten Lauf.

Ein separater Cloud-Browser trennt diese Welten. Browserbase hält die Browser-Sitzung, OpenClaw steuert den Agentenlauf. Ein Blogbeitrag von Julian Goldie stellt genau diese Trennung vom persönlichen Browserprofil als Sicherheitsgewinn heraus, der Text bleibt dabei allerdings eher Werbung als Erfahrungsbericht.

Isolation ist erst der Anfang.

Ein produktiver Lauf muss auch nach einem Abbruch nachvollziehbar bleiben. Das Plattformteam sollte vorab beantworten können, ob die Sitzung erhalten bleibt, ob sichtbar ist, auf welcher Seite der Ablauf stoppte, und ob ein neuer Versuch leer beginnt, fortsetzt oder einen schwer erkennbaren Mischzustand übernimmt. An diesen Übergängen entscheidet sich, ob ein Fehler kontrollierbar bleibt.

Testfall: Abbruch mitten im Lauf

Als Mindestprüfung eignet sich ein wiederkehrender Rechercheablauf: Seite öffnen, anmelden, einem Link folgen, ein Ergebnis erfassen. Der Agent darf dabei ausschließlich seine eigene Sitzung verändern.

Dann wird der Lauf mitten in der Navigation abgebrochen. Beim Neustart muss eindeutig erkennbar sein, ob OpenClaw fortsetzt oder sauber von vorn beginnt. Ein stiller Mischzustand schließt den produktiven Einsatz aus.

Zwei weitere Fehlerbilder gehören in denselben Test: eine abgelaufene Anmeldung und eine unerwartet veränderte Seite. In beiden Fällen sollte der Agent sichtbar stoppen und einen prüfbaren Fehler liefern, statt mit altem Zustand weiterzuarbeiten, und das Betriebsteam braucht für die Diagnose mindestens Zeitstempel, Sitzungsbezug und den letzten erfolgreich abgeschlossenen Schritt. Lastverhalten und Wiederherstellung lassen sich danach unter den Bedingungen der eigenen Umgebung prüfen.

Zugangsdaten bleiben das heikle Stück

Browser-Isolation schützt den persönlichen Arbeitsbrowser. Sie beseitigt weder Login-Hürden noch CAPTCHAs, macht keine fragile Website stabiler und hebt keine rechtlichen Grenzen automatisierter Nutzung auf.

Wie schnell Schlüssel verstreut werden, zeigt das archivierte Plugin. Laut README fragte openclaw browserbase setup API-Key und Projekt-ID ab, und openclaw browserbase env gab beides wahlweise als Shell-Export, dotenv oder JSON aus. Das ist bequem. Es führt aber leicht dazu, dass ein Browserbase-Key in einer .env-Datei auf einem Entwicklerrechner liegen bleibt, lange nachdem der Testlauf vergessen ist.

Für produktive Läufe sind deshalb getrennte Konten mit möglichst kleinen Berechtigungen die Untergrenze. Tokens und Sitzungen sollten widerrufbar sein, damit sich ein fehlerhafter oder kompromittierter Lauf beenden lässt, ohne den normalen Zugang des Operators zu gefährden.

Auch Leerlauf braucht eine Regel. Wie lange eine inaktive Sitzung bestehen darf, hängt vom Prozess und seinem Risiko ab. Fortsetzen oder neu beginnen muss eine bewusste, dokumentierte Entscheidung sein.

Und der Agent braucht eine harte Abbruchkante. Fordert eine Seite unerwartet eine Zahlung, eine Veröffentlichung oder die Änderung von Kundendaten, klickt der Ablauf nicht weiter, sondern wartet auf eine menschliche Freigabe.

Wo Browserbase zu OpenClaw passt

Browserbase macht den Browser zu einer separat betriebenen Ressource. Das passt zu OpenClaw-Läufen, die regelmäßig dieselben Weboberflächen besuchen und ihren Zustand vom Alltag des Operators fernhalten sollen. Neue Setups sollten dafür den Weg nehmen, den die Browserbase-Dokumentation heute zuerst nennt, also das eingebaute Browser-Plugin von OpenClaw, statt auf das archivierte Paket aufzubauen.

Sinnvoll wird die Integration erst, wenn das Plattformteam drei Dinge beherrscht: Sitzungsstatus erkennen, Berechtigungen begrenzen und Wiederanläufe reproduzierbar testen. Fehlt einer dieser Punkte, verlagert der Cloud-Browser das Zustandsproblem nur auf eine andere Plattform.

Daraus folgt eine einfache Mindestregel: Kein produktiver Einsatz, bevor ein absichtlich abgebrochener Lauf kontrolliert endet und der nächste Versuch mit einem eindeutig bekannten Zustand startet.