Zum Inhalt springen
tutorials · 6 min Lesezeit

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.

Risografie: Zwei Navy-Zugänge, ein Browserfenster und ein Terminal, münden mit grünen Bändern in ein aufgeschnittenes Gehäuse mit smaragdgrünem Innenraum; rechts steht ein kleines lavendelfarbenes Gerät ohne Verbindung daneben.
Dashboard, Gateway-TUI oder lokaler Chat: Control UI per Pairing öffnen, JSON auswerten und die TUI mit einer Gateway-Session oder der lokalen Runtime starten.
tutorials agenten

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.