Dashboard, Gateway-TUI oder lokaler Chat: OpenClaw-Zugänge einrichten
Control UI per Pairing öffnen, JSON auswerten und die OpenClaw-TUI mit einer Gateway-Session oder der lokalen Runtime starten.
Du möchtest OpenClaw im Browser steuern oder direkt im Terminal mit einer Session arbeiten? Die Control UI ist die Browseroberfläche, die TUI die Terminaloberfläche. Beide können auf ein laufendes Gateway zugreifen; die TUI lässt sich alternativ mit einer lokal eingebetteten Agent-Runtime starten.
Dieses Tutorial führt durch beide Betriebsarten. Du öffnest die Control UI per Pairing, liest Verbindungsdaten als JSON aus, verbindest die TUI mit einer Gateway-Session und wechselst bei Bedarf bewusst in den lokalen Modus.
Vor dem Start
Dieses Tutorial setzt voraus, dass die OpenClaw-CLI aufrufbar ist. Für Control UI und Gateway-TUI brauchst du außerdem ein erreichbares Gateway. Der lokale Modus benötigt stattdessen exklusiven Zugriff auf das konfigurierte State-Verzeichnis.
CLI und Gateway-Hintergrunddienst sind laut OpenClaw getrennte Komponenten. Eine Aufforderung zur Dienstinstallation bedeutet deshalb nicht, dass die CLI fehlt. Wähle danach den passenden Weg:
- Gateway-Modus: für die Control UI, vorhandene Gateway-Sessions und Gateway-Funktionen.
- Lokaler Modus: für die eingebettete Agent-Runtime ohne Gateway.
Die Control UI setzt ein laufendes Gateway voraus. Soll der Dashboard-Befehl einen fehlenden Gateway-Dienst bei Bedarf ohne Rückfrage starten oder installieren, unterstützt die Dashboard-Referenz diesen Aufruf:
openclaw dashboard --yes
Ist der konfigurierte Port belegt, der Gateway-Handshake aber nicht verifizierbar, bietet der Dashboard-Befehl keinen Start eines weiteren Dienstes an. Prüfe den Listener dann mit:
openclaw gateway status --deep
Mehr Kontext liefert OpenClaw-Gateway: Wenn „ready“ noch nicht stabil bedeutet.
Schritt 1: Control UI per Pairing öffnen
Starte das Dashboard:
openclaw dashboard
Der Befehl öffnet nach Angaben von OpenClaw einen kurzlebigen, einmalig verwendbaren Owner-Pairing-Link. Nach der erfolgreichen Übergabe besitzt der signierte Browser eine dauerhafte Administratorberechtigung für dieses Gerät. Spätere Dashboard-Aufrufe sind damit nicht mehr vom gemeinsamen Gateway-Token abhängig.
Im Terminal erscheint nur die bereinigte Basis-URL. Browser und Zwischenablage erhalten die einmalig verwendbare browserUrl, nicht das gemeinsame Token. Deren Bootstrap liegt im URL-Fragment und ist laut Dashboard-Referenz zehn Minuten gültig. Die Control UI entfernt ihn unmittelbar, bindet die Freigabe an die signierte Geräteidentität und speichert nur die daraus entstandene Administratorberechtigung.
Ein anderes Browserprofil kann diese Berechtigung weder übernehmen noch erneut abspielen. Nach einem Profilwechsel startest du daher ein neues Pairing. Soll OpenClaw keinen Browser öffnen, verwende:
openclaw dashboard --no-open
Der Pairing-Link enthält auch das Ziel-Gateway. Ist im Browser bereits ein anderes Gateway ausgewählt, verlangt die Control UI vor dem Pairing eine Bestätigung; ein Abbruch behält die bisherige Auswahl bei.
Bei gemeinsam genutzten Installationen ergänzt OpenClaw-Teamserver: Ein Gateway ist eine gemeinsame Vertrauensgrenze die Anleitung.
Ergebnisprüfung: Öffne das Dashboard erneut im selben Browserprofil. Nach erfolgreichem Pairing sollte keine erneute Übergabe des gemeinsamen Gateway-Tokens erforderlich sein.
Schritt 2: Verbindungsdaten als JSON abrufen
Skripte und Desktop-Integrationen können die aufgelösten Verbindungsdaten maschinenlesbar anfordern:
openclaw dashboard --json
Dieser Aufruf gibt laut Dashboard-Referenz ein einzelnes JSON-Objekt aus. Er öffnet keinen Browser, verwendet nicht die Zwischenablage, stellt keine Rückfrage und startet das Gateway nicht selbst.
Die Antwort enthält unter anderem url, browserUrl, browserBootstrapExpiresAtMs, httpUrl, wsUrl, port und tokenIncluded. Browser-Integrationen sollen browserUrl öffnen. Native RPC-Clients, die das gemeinsame Gateway-Credential benötigen, können weiterhin url verwenden; über SecretRef verwaltete gemeinsame Tokens erscheinen dort nicht.
Behandle browserUrl wie einen kurzlebigen Zugang. Schreibe die Adresse nicht in Logs und gib sie nicht unnötig weiter.
Prüfe in einem Skript zuerst Exit-Code und JSON-Antwort. Ist das Gateway nicht bereit oder kann kein Browser-Handoff erzeugt werden, liefert der Befehl nach Angaben von OpenClaw ein Objekt mit ok:false und endet mit einem von null verschiedenen Exit-Code. Fehlermeldung und Diagnosebefehl erscheinen zusätzlich auf stderr, während stdout ein einzelnes JSON-Objekt bleibt.
Scheitern Browser- oder Zwischenablageübergabe und kann das gemeinsame Token nicht in eine URL aufgenommen werden, sieht die Dashboard-Dokumentation einen klaren Ersatzweg vor: Rufe browserUrl über --json ab und öffne sie innerhalb von zehn Minuten.
Ergebnisprüfung: stdout lässt sich als einzelnes JSON-Objekt parsen und das für deine Integration benötigte URL-Feld ist gesetzt. Bei ok:false wertest du die Meldung und den Diagnosehinweis auf stderr aus.
Schritt 3: TUI mit einer Gateway-Session verbinden
Für das konfigurierte oder standardmäßige Gateway startest du die Terminaloberfläche ohne weiteres Ziel:
openclaw tui
Damit verbindet OpenClaw die TUI mit dem Gateway. Läuft ohne explizites Ziel kein lokales Gateway, stoppt der Befehl laut TUI-Referenz vor dem Verbindungsversuch und verweist auf openclaw chat als lokalen Weg.
Eine bestimmte Session wählst du über ihren Schlüssel:
openclaw tui --session main
openclaw tui --session bugfix
Als Ziel akzeptiert die TUI außerdem eine Control-UI-Session-URL, eine kompakte Angabe im Format host/agent/ref, eine kurze Referenz oder einen vollständigen agent:...-Session-Key:
openclaw tui movies-a1166b81
openclaw tui <Control-UI-Session-URL>
Eine URL oder ein Host legt das Gateway verbindlich fest. Eine kurze Referenz wird dagegen über das konfigurierte oder standardmäßige Gateway aufgelöst. Ist sie mehrdeutig, verbindet sich die CLI nach Angaben von OpenClaw mit keiner Session, sondern zeigt Kandidatennamen und längere ID-Präfixe an.
Halte Session-URLs frei von Zugangsdaten. Die TUI weist Userinfo sowie sensible Query- oder Fragmentparameter wie token und password zurück.
Für eine fehlende oder mehrdeutige Session listest du beim konfigurierten beziehungsweise lokalen Gateway die verfügbaren Sessions auf:
openclaw sessions list
Bei einem per URL oder Host gewählten Gateway nimmst du stattdessen einen längeren oder vollständigen Schlüssel aus dessen Control UI.
Ergebnisprüfung: Die TUI öffnet die beabsichtigte Session. Erscheint eine Kandidatenliste, wiederhole den Aufruf mit einem längeren Präfix oder dem vollständigen Session-Key.
Schritt 4: TUI ohne Gateway lokal starten
Für Aufgaben ohne Gateway startest du die eingebettete Agent-Runtime so:
openclaw tui --local
Diese beiden Befehle sind laut TUI-Referenz Aliase für denselben lokalen Modus:
openclaw chat
openclaw terminal
Die meisten lokalen Tools funktionieren weiterhin, Gateway-spezifische Funktionen stehen jedoch nicht zur Verfügung. Plugin-Freigaben bleiben aktiv: Freigabepflichtige Tools fragen im Terminal nach und werden nicht automatisch zugelassen.
Der lokale Modus benötigt exklusiven Zugriff auf das konfigurierte State-Verzeichnis. Besitzt ein Gateway oder eine andere eingebettete schreibende Runtime diesen State, verweigert die lokale TUI nach Angaben von OpenClaw den Start.
Verbinde dich in diesem Fall zunächst ohne --local mit dem aktiven Gateway. Nur wenn du den Gateway-Betrieb bewusst beenden und den State an die lokale Runtime übergeben möchtest, stoppst du den Dienst vorher:
openclaw gateway stop
Store-gebundene Secrets-Anfragen lassen sich lokal nicht erfüllen. Die TUI-Dokumentation verweist dafür auf openclaw secrets store oder die Control UI mit laufendem Gateway.
Der lokale Modus kann außerdem bei der Prüfung und Reparatur der Konfiguration helfen. Schlägt die Validierung bereits vor dem Start fehl, umgeht openclaw chat diese Sperre nicht:
openclaw config validate
Für diesen Fall nennt OpenClaw zwei Reparaturwege:
openclaw configure
openclaw doctor --fix
Prüfe die Konfiguration anschließend erneut. Erst danach startest du openclaw chat.
Ergebnisprüfung: Die eingebettete TUI startet ohne Gateway-Verbindung. Meldet OpenClaw einen belegten State, wechselst du zum aktiven Gateway oder beendest dessen Zugriff bewusst, bevor du den lokalen Start wiederholst.
Lokaler Chat braucht exklusiven State-Zugriff
Nutze openclaw dashboard für das Browser-Pairing und openclaw dashboard --json für maschinenlesbare Verbindungsdaten. Die Gateway-TUI führt zu vorhandenen Sessions; eine bestimmte Session wählst du über ein Ziel oder --session aus.
openclaw tui --local, openclaw chat und openclaw terminal verwenden dagegen die eingebettete Runtime. Dieser Weg setzt exklusiven Zugriff auf den State voraus und bietet keine Gateway-Funktionen wie Store-gebundene Secrets-Anfragen.
Transparenz
agentenlog.de nutzt KI-Assistenz für Recherche, Struktur und Entwurf. Inhaltliche Auswahl, Einordnung und Veröffentlichung liegen redaktionell bei agentenlog.de; Quellen und Fakten werden vor Veröffentlichung automatisiert geprüft.
Serie: Automation & Betrieb
Das könnte dich auch interessieren
Hooks in OpenClaw: Den Agenten auf /new, /reset und andere Ereignisse reagieren lassen
So aktivierst du in OpenClaw einen mitgelieferten Hook, prüfst, ob er wirklich läuft, und hältst Handler kurz und kontrollierbar.
OpenClaw Access Groups: Absenderlisten für mehrere Kanäle zentral pflegen
So bündelst du Absender-IDs für Telegram, Discord und weitere OpenClaw-Kanäle, prüfst die Konfiguration und vermeidest unbemerkte Zugriffsfehler.
OpenClaw mit Ollama: lokale Modelle einrichten, Limits prüfen, Stalls vermeiden
Wie du Ollama lokal in OpenClaw einrichtest, Modellrouten prüfst und langsame oder instabile Läufe systematisch eingrenzt.