Das Browser-Relay von OpenClaw

Ihr Agent kann eine Seite abrufen, aber abrufen ist nicht dasselbe wie benutzen. Der Tab, auf den es ankommt, ist bereits angemeldet, er liegt auf einem Laptop in einem anderen Raum, und das Gateway läuft auf einem Server ganz woanders. Die Antwort von OpenClaw besteht darin, Browser-Aktionen an die Maschine weiterzuleiten, auf der der Browser tatsächlich läuft, und sie dann dort zu halten.

Vier Orte, an denen der Browser laufen kann

• Lokale Steuerung, der Standard. Das Gateway startet den Loopback-Steuerdienst und kann einen lokalen Browser starten. Aktionen ohne Ziel wie open, navigate oder openclaw browser start können ihn starten; eine Aktion, die einen Tab per targetId, Tab-ID oder Label benennt, startet nie einen gestoppten Browser, denn ein frischer Browser kann diesen Tab nicht enthalten.
• Fernsteuerung über einen Node-Host. Sie betreiben einen Node-Host auf der Maschine, die den Browser hat, und das Gateway leitet Browser-Aktionen per Proxy an ihn weiter. Der Node stellt seinen eigenen lokalen Browser-Steuerserver über einen Proxy-Befehl bereit, sodass das Gateway das Browser-Binary überhaupt nicht braucht.
• Remote-CDP. Setzen Sie den Schlüssel cdpUrl unter Ihrem Profil in browser.profiles oder das ältere browser.cdpUrl für ein einzelnes Profil, um sich mit einem entfernten Chromium-basierten Browser zu verbinden. In diesem Fall startet OpenClaw keinen eigenen lokalen Browser.
• Reine Attach-Dienste auf Loopback. Für einen extern verwalteten CDP-Dienst, der auf 127.0.0.1 veröffentlicht ist (typischerweise Browserless in Docker), setzen Sie zusätzlich attachOnly: true. Loopback-CDP ohne attachOnly wird als lokales, von OpenClaw verwaltetes Profil behandelt, und OpenClaw meldet dann womöglich, dass der Port belegt ist, aber nicht OpenClaw gehört.

Sobald eine Aktion den Node erreicht, bleiben ihr nachfolgender Snapshot oder ihre Einstellungen auf diesem Node, statt den Browser zu wechseln.

Das Routing wird einmal entschieden, nicht pro Aktion

Das automatische Routing bevorzugt den Host, einschließlich eines gestoppten verwalteten Browsers, dessen Executable lediglich installiert ist. Ein explizites Ziel node, ein Node-Selektor oder gateway.nodes.browser.node überschreibt diese Präferenz, während target=host immer auf dem Host bleibt. Der jeweils gewählte Eigentümer behält dann alles: existing-session-, extension-, attach-only- und Remote-CDP-Verbindungen gehören ihm, selbst wenn kein Executable für einen verwalteten Browser vorhanden ist, und Startfehler, ungültige Executable-Einstellungen, Berechtigungsfehler und Fehler bei Seitenaktionen bleiben bei diesem Eigentümer, statt auf einer anderen Maschine wiederholt zu werden. Ein automatischer Fallback von einem gewählten Node auf den Host ist nur erlaubt, bevor dieser Node eine Anfrage bearbeitet hat; das ist der Satz oben in der Praxis. Genau das macht eine mehrstufige Browser-Aufgabe kohärent: Der Snapshot, mit dem Sie arbeiten, und die Element-Refs, die er zurückgegeben hat, beschreiben einen Browser, nicht zwei.

Grenzen, die das Relay einhält

• Profile stammen aus der eigenen browser.profiles-Konfiguration des Nodes, genau so, als säßen Sie an dieser Maschine. Das Gateway projiziert seine eigene Profilliste nicht auf den Node.
• Dauerhafte Profiländerungen werden über den Proxy-Befehl abgelehnt, egal wie er konfiguriert ist: create-profile, delete-profile und reset-profile sind unabhängig von allowProfiles blockiert. Nehmen Sie diese Änderungen direkt auf dem Node vor.
• nodeHost.browserProxy.allowProfiles ist optional. Leer gelassen, bleibt jedes konfigurierte Profil über den Proxy erreichbar, was das bisherige Standardverhalten ist. Setzen Sie es, behandelt OpenClaw es als Least-Privilege-Grenze, die einschränkt, welche Profilnamen der Proxy ansteuert. Um den ganzen Weg abzuschalten, verwenden Sie nodeHost.browserProxy.enabled=false auf dem Node oder gateway.nodes.browser.mode=off auf dem Gateway; dieser Schlüssel akzeptiert auch auto und manual.

Der Agent sieht für alle vier Anordnungen ein einziges Tool: ein browser-Tool, das doctor, status, start, stop, tabs, open, focus, close, snapshot, screenshot, navigate, act, requests, errors, text und emulate abdeckt, mit einem profile-Argument für den Browser und einem target-Argument mit sandbox, host oder node für die Maschine. Dasselbe Verb kann je nach Modus Unterschiedliches bedeuten. Stop beendet bei einem lokalen verwalteten Profil den Prozess, den OpenClaw gestartet hat, während es bei attach-only- und Remote-CDP-Profilen die aktive Steuer-Sitzung schließt und die Playwright- und CDP-Emulations-Overrides für Viewport, Farbschema, Locale, Zeitzone und Offline-Modus freigibt, obwohl OpenClaw dort nie einen Browser-Prozess gestartet hat. Die headless-Einstellung folgt derselben Regel, da sie nur lokale verwaltete Profile betrifft, die OpenClaw startet. Die vollständige Aktionsliste und ihre Argumente finden Sie unter den Aktionen des browser-Tools, und was ein Node-Host eigentlich ist, wie er gekoppelt wird und was er sonst noch tragen kann, unter Browser-Nodes.

Gehostete Browser und die drei URL-Formen

OpenClaw akzeptiert drei Formen von CDP-URLs und wählt für jede automatisch die Verbindungsstrategie. Eine http://- oder https://-Basis bedeutet Discovery: OpenClaw ruft /json/version auf, liest die WebSocket-Debugger-URL aus und verbindet sich, ohne WebSocket-Fallback. Ein direkter ws://- oder wss://-Endpunkt mit einem Pfad /devtools/browser, page, worker, shared_worker oder service_worker überspringt /json/version vollständig. Eine nackte WebSocket-Root ohne /devtools-Pfad, wie sie Browserless und Browserbase liefern, versucht zuerst HTTP-Discovery und greift auf einen direkten Handshake an der Root zurück, wenn die Discovery nichts Brauchbares liefert. Diese URLs tragen die Autorisierung meist als Query-Token oder HTTP-Basic-Zugangsdaten, und OpenClaw behält diese Authentifizierung sowohl beim Aufruf von /json/*-Endpunkten als auch beim Öffnen des CDP-WebSockets bei; behandeln Sie daher die ganze URL als Geheimnis und bewahren Sie sie in einer Umgebungsvariable oder einem Secrets-Manager statt in einer Konfigurationsdatei auf. Die Diagnose verwendet dieselbe Logik mit Discovery zuerst und WebSocket-Fallback wie ein Attach zur Laufzeit, sodass eine nackte Root, die sich verbindet, von der Browser-Steuer-API nicht als unerreichbar gemeldet wird. Der einzige Modus mit angemeldetem Browser, der überhaupt keine cdpUrl hat, ist das Relay der Chrome-Erweiterung, das seinen eigenen Loopback-Endpunkt besitzt und echte Tabs steuert, ohne dass jemand am Computer sitzt.

Bei Diali

Diali hostet OpenClaw als verwalteten Dienst. Jeder Kunde erhält seinen eigenen Assistenten auf seiner eigenen Runtime statt eines Platzes in einem geteilten Pool. Die Runtime-Konfiguration wird aus Ihrem Dashboard erzeugt und bei jedem Release neu geschrieben, sodass der browser-Block, den Sie in der Oberfläche festlegen, derjenige ist, mit dem der Agent startet. Alles, was der Agent behält, liegt auf einem persistenten Volume, mit täglichen Snapshots und Wiederherstellung mit einem Klick über das Add-on Backups (in Max enthalten). Gehostetes OpenClaw bei Diali beschreibt die gehostete Runtime, und die Preisseite von Diali listet die Tarife auf.

• Ein Node-Host leitet Browser-Aktionen an die Maschine weiter, zu der der Browser gehört.
• Sobald eine Aktion auf einem Node landet, bleibt der Rest der Aufgabe dort.
• attachOnly verhindert, dass ein Loopback-CDP-Dienst für ein verwaltetes Profil gehalten wird.