Steuerungsoberfläche

• Chatten Sie über Gateway-WS mit dem Modell (chat.history, chat.send, chat.abort, chat.inject).
• Bei der Aktualisierung des Chatverlaufs wird ein begrenztes aktuelles Fenster mit Textobergrenzen pro Nachricht angefordert, damit große Sitzungen den Browser nicht zwingen, vor der Nutzbarkeit des Chats die vollständigen Transkriptdaten zu rendern.
• Wenn Sie den Mauszeiger über einen öffentlichen GitHub-Issue- oder Pull-Request-Link bewegen oder ihn per Tastatur fokussieren, werden dessen Status, Titel, Autor, letzte Aktivität, Kommentare und Änderungsstatistiken angezeigt. Das verbundene Gateway ruft öffentliche Metadaten ab und speichert sie zwischen, ohne das Linkziel zu ändern – auch wenn die Benutzeroberfläche ein entferntes Gateway verwendet. Das Gateway verwendet GH_TOKEN oder GITHUB_TOKEN, sofern verfügbar, nachdem bestätigt wurde, dass das Repository öffentlich ist; andernfalls verwendet es die anonyme GitHub-API mit einem längeren Cache-Zeitraum.
• Sprechen Sie über Echtzeitsitzungen im Browser. OpenAI verwendet direktes WebRTC, Google Live verwendet ein eingeschränktes Browser-Token zur einmaligen Verwendung über WebSocket und ausschließlich backendseitige Echtzeit-Sprach-Plugins verwenden den Gateway-Relay-Transport. Vom Client verwaltete Provider-Sitzungen beginnen mit talk.client.create; Gateway-Relay-Sitzungen beginnen mit talk.session.create. Das Relay hält die Provider-Anmeldedaten auf dem Gateway, während der Browser Mikrofon-PCM über talk.session.appendAudio streamt, leitet Provider-Tool-Aufrufe von openclaw_agent_consult über talk.client.toolCall an die Gateway-Richtlinie und das größere konfigurierte OpenClaw-Modell weiter und führt die Sprachsteuerung aktiver Ausführungen über talk.client.steer oder talk.session.steer.
• Streamen Sie Tool-Aufrufe und Karten mit Live-Tool-Ausgaben im Chat (Agent-Ereignisse). Tool-Aktivitäten werden als typabhängige Zeilen dargestellt: Shell-Befehle zeigen den syntaxhervorgehobenen Befehl mit einer Ausgabe im Terminalstil; unterstützte Bearbeitungs- und Schreibaufrufe zeigen begrenzte Inline-Diffs, soweit verfügbar Zeilennummern sowie Statistiken im Format +added -removed; aufeinanderfolgende Aufrufe werden zu einer Zusammenfassung wie „13 Befehle ausgeführt, 6 Dateien gelesen, 9 Dateien bearbeitet“ zusammengefasst. Während eine Ausführung aktiv ist, benennt der neueste laufende Aufruf die Gruppenüberschrift. Klappen Sie eine Zeile aus, um die übrigen Argumente und die Rohausgabe zu prüfen.
• Optionale KI-Zwecktitel für komplexe Tool-Aufrufe (lange Shell-Befehle, Plugin-Tools mit vielen Argumenten), aktiviert mit gateway.controlUi.toolTitles: true (standardmäßig deaktiviert). Die Titel stammen über die Standardweiterleitung für Hilfsmodelle aus der gebündelten Methode chat.toolTitles – entweder aus einem expliziten utilityModel (vom Betreiber ausgewählter Provider, wie bei anderen Hilfsaufgaben) oder aus dem deklarierten Standard-Kleinmodell des Sitzungs-Providers – und werden Gateway-seitig pro Agent zwischengespeichert. Wenn die optionale Funktion deaktiviert ist oder kein kostengünstiges Modell verwendet werden kann, behalten die Zeilen ihre deterministischen Beschriftungen und es erfolgt kein Modellaufruf.
• Starten oder verwerfen Sie flüchtige, vom Modell vorgeschlagene Folgeaufgaben; angenommene Vorschläge öffnen eine neue Sitzung in einem verwalteten Arbeitsbaum mit dem vorgeschlagenen Prompt.
• Aktivitätsregisterkarte mit zuerst redigierten, browserlokalen Zusammenfassungen der Live-Tool-Aktivität aus der vorhandenen Bereitstellung von session.tool-/Tool-Ereignissen.

• Kanäle: Status integrierter sowie gebündelter/externer Plugin-Kanäle, QR-Anmeldung und kanalspezifische Konfiguration (channels.status, web.login.*, config.patch).
• Bei Aktualisierungen durch Kanalprüfungen bleibt der vorherige Snapshot sichtbar, während langsame Provider-Prüfungen abgeschlossen werden; partielle Snapshots werden gekennzeichnet, wenn eine Prüfung oder ein Audit das Zeitbudget der Benutzeroberfläche überschreitet.
• Sitzungen: Standardmäßig werden die Sitzungen konfigurierter Agenten aufgelistet. Häufig verwendete Sitzungen können angeheftet, umbenannt, archiviert oder nach Inaktivität wiederhergestellt werden. Veraltete Sitzungsschlüssel nicht konfigurierter Agenten werden durch einen Fallback behandelt. Außerdem lassen sich sitzungsspezifische Überschreibungen für Modell, Denken, Schnellmodus, Ausführlichkeit, Ablaufverfolgung und Schlussfolgern anwenden (sessions.list, sessions.patch). Angeheftete Sitzungen werden über kürzlich verwendeten, nicht angehefteten Sitzungen sortiert; archivierte Sitzungen befinden sich in der Archivansicht der Sitzungsseite und behalten ihre Transkripte. Zeilen zeigen einen Punkt für ungelesene Sitzungen mit Aktivitäten seit dem letzten Lesen und bieten Aktionen zum Markieren als ungelesen/gelesen (sessions.patch { unread }) sowie eine Fork-Aktion, die das Transkript in eine neue Sitzung verzweigt (sessions.create { parentSessionKey, fork: true }). Übersichtskacheln über der Tabelle fassen die geladene Aufstellung zusammen (Anzahl der Sitzungen, aktive Ausführungen, ungelesene Sitzungen, Token insgesamt). Jede Zeile enthält ein Symbol für die Art mit einem Punkt für eine aktive Ausführung; der Status wird als einfacher Punkt mit Beschriftung dargestellt; und die Spalte „Token“ zeigt eine Auslastungsanzeige für das Kontextfenster, wenn die Sitzung Token- und Kontextgrößen meldet. Aktionen zur Zeilenverwaltung befinden sich in einem Menü pro Zeile (Dreipunkt-Schaltfläche oder Rechtsklick), das dem Sitzungsmenü der Seitenleiste entspricht. Der Zeilen-Drawer zeigt neben den anderen Sitzungsdetails die Agent-Laufzeitumgebung und die Ausführungsdauer.
• Sitzungsgruppierung: Mit einem Steuerelement „Gruppieren nach“ wird die Sitzungstabelle nach benutzerdefinierten Gruppen, Kanal, Art, Agent oder Datum in Abschnitte gegliedert. Benutzerdefinierte Gruppen bleiben über sessions.patch (category) sitzungsbezogen erhalten, sodass auch Sitzungen kategorisiert werden können, die über Nachrichtenkanäle (Discord, Telegram, WhatsApp, ...) gestartet wurden. Weisen Sie Gruppen zu, indem Sie Zeilen auf einen Abschnitt ziehen oder die Gruppenauswahl der jeweiligen Zeile verwenden, und erstellen Sie Gruppen mit der Aktion „Neue Gruppe“.
• Speicher (eine auf den ausgewählten Agenten beschränkte Registerkarte auf der Agentenseite): Dreaming-Status, Umschalter zum Aktivieren/Deaktivieren und Leser für das Traumtagebuch (doctor.memory.status, doctor.memory.dreamDiary, config.patch).

• Automatisierungen (Cron-Jobs): Statistikkarten (Anzahl der Automatisierungen, Anzahl der fehlgeschlagenen Automatisierungen, Scheduler-Status, nächster Aktivierungszeitpunkt) über einem Tab-Umschalter zwischen Automatisierungen und Ausführungsverlauf; der Tab „Automatisierungen“ listet Jobs in einer filterbaren Tabelle auf (Alle/Aktiv/Pausiert, Suche, Zeitplan- und Filter für die letzte Ausführung, Aktionsmenü pro Zeile) und zeigt darunter Vorschläge für den Einstieg, während der Tab „Ausführungsverlauf“ die letzten Ausführungen aller Automatisierungen anzeigt (cron.*).
• Aufgaben: Live-Übersicht aktiver und kürzlich ausgeführter Hintergrundaufgaben mit verknüpften Sitzungen und Abbruchmöglichkeit (tasks.*).
• Plugins: Installierten Bestand und kuratierten Store durchsuchen, ClawHub durchsuchen, Plugin-Code installieren und entfernen sowie installierte Plugins aktivieren oder deaktivieren (plugins.*); MCP-Serverzeilen bearbeiten mcp.servers über die Konfigurationsmethoden.
• Skills: Status, Aktivieren/Deaktivieren, Installation, Aktualisierungen von API-Schlüsseln (skills.*).
• Geräte: Eine Bestandsübersicht führt Datensätze gekoppelter Geräte, den Node-Katalog und die Live-Anwesenheit zusammen (device.pair.list, node.list, system-presence). Der Gateway-Host ist an erster Stelle angeheftet; gekoppelte Clients zeigen Verbindungsstatus, Rollen, Token, Fähigkeiten und Befehle. Doppelte Kopplungen werden zu einer aufklappbaren Gruppe zusammengefasst, und N veraltete Einträge bereinigen entfernt gesammelt vom Administrator bestätigte Offline-Duplikate, die automatisch genehmigt wurden (stilles lokales Verfahren, vertrauenswürdiger CIDR-Bereich oder SSH-verifiziert) oder vor der Erfassung des Genehmigungsursprungs angelegt wurden. Einträge können entfernt (node.pair.remove, device.pair.remove), Gerätekopplungen und erneute Node-Genehmigungen direkt bearbeitet (device.pair.*, node.pair.approve/reject) und Codes zur mobilen Einrichtung über dieselbe Karte erstellt werden.
• Ausführungsgenehmigungen: Gateway- oder Node-Zulassungslisten und die Abfragerichtlinie für exec host=gateway/node bearbeiten (exec.approvals.*).

• ~/.openclaw/openclaw.json anzeigen/bearbeiten (config.get, config.set).
• Profil: Eine Einstellungsseite, die die Identität des Standard-Agenten mit Nutzungsstatistiken über den gesamten Zeitraum anzeigt – Token über die gesamte Laufzeit, Spitzentag, längste Sitzung, Aktivitätsserien, eine Token-Heatmap für ein Jahr, meistgenutzte Tools und Kanal-Highlights (usage.cost, sessions.usage).
• MCP verfügt über eine eigene Einstellungsseite mit schreibgeschützten Serverzeilen (Transport, Aktivierung, OAuth-/Filter-/Parallelitätszusammenfassungen), gängigen Operatorbefehlen und dem auf mcp begrenzten Konfigurationseditor; Server werden auf der Seite „Plugins“ hinzugefügt, aktiviert/deaktiviert und entfernt.
• Modell-Provider: Eine Einstellungsseite, die jeden konfigurierten Modell-Provider mit seinem Markensymbol, Authentifizierungsstatus (models.authStatus), der Modellverfügbarkeit (models.list), Live-Daten zu Tarif/Kontingent/Abrechnung, sofern der Provider diese meldet (usage.status), und den lokalen Sitzungsausgaben der letzten 30 Tage (sessions.usage) auflistet. Die Aktion „Aktualisieren“ liest den Anmeldedatenstatus und die Provider-Nutzung erneut ein.
• Verbindung: Eine Einstellungsseite (unter Verbindungen), die die eigene Gateway-Verbindung des Dashboards verwaltet – WebSocket-URL, Gateway-Token, Passwort und Standardsitzungsschlüssel – sowie den neuesten Handshake-Snapshot (Status, Betriebszeit, Tick-Intervall, letzte Kanalaktualisierung). Die Offline-Anmeldesperre behandelt den Fall einer getrennten Verbindung; diese Seite bearbeitet die Verbindung im verbundenen Zustand.
• Mit Validierung anwenden und neu starten (config.apply), anschließend die zuletzt aktive Sitzung aktivieren.
• Schreibvorgänge enthalten eine Schutzprüfung des Basis-Hashs, um das Überschreiben gleichzeitiger Änderungen zu verhindern.
• Schreibvorgänge (config.set/config.apply/config.patch) prüfen vorab die aktive SecretRef-Auflösung für Referenzen in den übermittelten Konfigurationsdaten; nicht aufgelöste aktive, übermittelte Referenzen werden vor dem Schreiben abgelehnt.
• Beim Speichern von Formularen werden veraltete geschwärzte Platzhalter verworfen, die nicht aus der gespeicherten Konfiguration wiederhergestellt werden können, während geschwärzte Werte erhalten bleiben, die weiterhin gespeicherten Geheimnissen zugeordnet sind.
• Schema und Formulardarstellung stammen aus config.schema / config.schema.lookup, einschließlich der Felder title/description, übereinstimmender UI-Hinweise, unmittelbarer Zusammenfassungen untergeordneter Elemente, Dokumentationsmetadaten für verschachtelte Objekt-/Platzhalter-/Array-/Kompositionsknoten sowie Plugin- und Kanalschemas, sofern verfügbar. Der Raw-JSON-Editor ist nur verfügbar, wenn der Snapshot einen sicheren Raw-Roundtrip unterstützt; andernfalls erzwingt die Control UI den Formularmodus.
• „Auf gespeicherten Stand zurücksetzen“ im Raw-JSON-Editor bewahrt die ursprünglich im Rohformat erstellte Struktur (Formatierung, Kommentare, $include-Layout), anstatt einen vereinfachten Snapshot neu darzustellen, sodass externe Änderungen eine Zurücksetzung überstehen, wenn der Snapshot sicher einen Roundtrip durchlaufen kann.
• Strukturierte SecretRef-Objektwerte werden in Texteingabefeldern des Formulars schreibgeschützt dargestellt, um eine versehentliche Beschädigung durch Umwandlung eines Objekts in eine Zeichenfolge zu verhindern.

• Die aus Sitzungen abgeleitete Analyse von Token und geschätzten Kosten bleibt von der Provider-Abrechnung getrennt.
• Provider-Karten rufen usage.status auf und zeigen Live-Tarifnamen, Kontingentzeiträume, Guthaben, Ausgaben und Budgets an, die von konfigurierten Provider-Plugins gemeldet werden.
• Ein Fehler bei der Provider-Nutzung blockiert das Sitzungs-/Kostendashboard nicht; nicht verfügbare Provider-Karten zeigen ihren eigenen Fehlerstatus an.

• Debugging: Snapshots zu Status/Systemzustand/Modellen, Ereignisprotokoll und manuelle RPC-Aufrufe (status, health, models.list).
• Das Ereignisprotokoll enthält Aktualisierungs-/RPC-Zeitmessungen der Control UI, Zeitmessungen für langsame Chat-/Konfigurationsdarstellungen und Einträge zur Browser-Reaktionsfähigkeit bei langen Animationsframes oder lang laufenden Aufgaben, wenn der Browser diese PerformanceObserver-Eintragstypen bereitstellt.
• Protokolle: Live-Anzeige der letzten Einträge in Gateway-Dateiprotokollen mit Filter/Export (logs.tail).
• Aktualisierung: Eine Paket-/Git-Aktualisierung samt Neustart (update.run) mit Neustartbericht ausführen und anschließend nach dem erneuten Verbinden update.status abfragen, um die laufende Gateway-Version zu überprüfen.

• Durch Auswählen einer Zeile wird eine ganzseitige Detailansicht mit einem Aktiv/Pausiert-Schalter und „Jetzt ausführen“ in der Kopfzeile geöffnet („Bei Fälligkeit ausführen“, „Klonen“ und „Entfernen“ befinden sich im zugehörigen Menü); der Tab „Einstellungen“ bearbeitet die Automatisierung direkt (Prompt, Details, Häufigkeit, erweiterte Überschreibungen), und der Tab „Ausführungsverlauf“ zeigt die Ausführungen dieser Automatisierung.
• Die Automatisierungsvorlagen unter der Tabelle füllen das Erstellungsformular mit einem bearbeitbaren Prompt und Zeitplan vorab aus.
• Bei isolierten Aufgaben wird die Zustellung standardmäßig als Zusammenfassung angekündigt; wählen Sie „Keine“ für ausschließlich interne Ausführungen.
• Felder für Kanal/Ziel werden angezeigt, wenn „Ankündigen“ ausgewählt ist.
• Der Webhook-Modus verwendet delivery.mode = "webhook", wobei delivery.to auf eine gültige HTTP(S)-Webhook-URL gesetzt ist.
• Für Aufgaben der Hauptsitzung sind die Zustellmodi Webhook und „Keine“ verfügbar.
• Zu den erweiterten Bearbeitungsoptionen gehören das Löschen nach der Ausführung, das Löschen der Agentenüberschreibung, Optionen für exakte/gestaffelte Cron-Ausführung, Überschreibungen für Agentenmodell/Denken und Umschalter für die Best-Effort-Zustellung.
• Die Formularvalidierung erfolgt direkt mit Fehlern auf Feldebene; ungültige Werte deaktivieren die Speichern-Schaltfläche, bis sie korrigiert wurden.
• Legen Sie cron.webhookToken fest, um ein dediziertes Bearer-Token zu senden; wird es weggelassen, wird der Webhook ohne Authentifizierungsheader gesendet.
• cron.webhook ist ein veralteter Legacy-Fallback: Führen Sie openclaw doctor --fix aus, um gespeicherte Jobs, die noch notify: true verwenden, auf eine explizite Webhook- oder Abschlusszustellung pro Job zu migrieren.

• chat.send ist nicht blockierend: Es bestätigt sofort mit { runId, status: "started" }, und die Antwort wird über chat-Ereignisse gestreamt. Vertrauenswürdige Control-UI-Clients können außerdem optionale ACK-Zeitmetadaten für die lokale Diagnose erhalten.
• Chat-Uploads akzeptieren Bilder sowie Dateien, die keine Videos sind. Bilder behalten den nativen Bildpfad; andere Dateien werden als verwaltete Medien gespeichert und im Verlauf als Anhangslinks angezeigt.
• Erneutes Senden mit demselben idempotencyKey gibt während der Ausführung { status: "in_flight" } und nach Abschluss { status: "ok" } zurück.
• Antworten von chat.history sind zur Sicherheit der Benutzeroberfläche größenbeschränkt. Wenn Transkripteinträge zu groß sind, kann der Gateway lange Textfelder kürzen, umfangreiche Metadatenblöcke auslassen und übergroße Nachrichten durch einen Platzhalter ([chat.history omitted: message too large]) ersetzen.
• Wenn eine sichtbare Assistentennachricht in chat.history gekürzt wurde, kann die Seitenansicht den vollständigen, für die Anzeige normalisierten Transkripteintrag bei Bedarf über chat.message.get anhand von sessionKey, falls erforderlich der aktiven agentId, und der Transkript-messageId abrufen. Wenn der Gateway weiterhin keine weiteren Inhalte zurückgeben kann, zeigt die Ansicht ausdrücklich an, dass diese nicht verfügbar sind, statt stillschweigend erneut die gekürzte Vorschau anzuzeigen.
• Vom Assistenten erzeugte Bilder werden als Referenzen auf verwaltete Medien dauerhaft gespeichert und über authentifizierte Gateway-Medien-URLs bereitgestellt, sodass ein erneutes Laden nicht davon abhängt, dass rohe Base64-Bildnutzdaten in der Antwort des Chatverlaufs verbleiben.
• Beim Rendern von chat.history entfernt die Control UI ausschließlich für die Anzeige bestimmte Inline-Direktiven-Tags aus dem sichtbaren Assistententext (zum Beispiel [[reply_to_*]] und [[audio_as_voice]]), Nur-Text-XML-Nutzdaten von Tool-Aufrufen (einschließlich <tool_call>...</tool_call>, <function_call>...</function_call>, <tool_calls>...</tool_calls>, <function_calls>...</function_calls> und gekürzter Tool-Aufrufblöcke) sowie durchgesickerte ASCII-/vollbreite Modellsteuerungstoken. Sie lässt Assistenteneinträge aus, deren gesamter sichtbarer Text ausschließlich aus dem exakten Stille-Token NO_REPLY / no_reply oder dem Heartbeat-Bestätigungstoken HEARTBEAT_OK besteht.
• Während eines aktiven Sendevorgangs und der abschließenden Aktualisierung des Verlaufs hält die Chatansicht lokale optimistische Benutzer-/Assistentennachrichten sichtbar, falls chat.history kurzzeitig einen älteren Schnappschuss zurückgibt; das kanonische Transkript ersetzt diese lokalen Nachrichten, sobald der Gateway-Verlauf aufgeholt hat.
• Live-chat-Ereignisse stellen den Zustellstatus dar, während chat.history aus dem dauerhaften Sitzungstranskript neu aufgebaut wird. Nach abschließenden Tool-Ereignissen lädt die Control UI den Verlauf neu und führt nur einen kleinen optimistischen Nachlauf zusammen; die Transkriptgrenze ist unter WebChat dokumentiert.
• chat.inject hängt eine Assistentennotiz an das Sitzungstranskript an und sendet ein chat-Ereignis für reine UI-Aktualisierungen (kein Agentenlauf, keine Kanalzustellung).
• Die Seitenleiste führt jede geladene aktive Sitzung nach Agentenabschnitt und den Bereichen „Angeheftet“, „Kanal“, „Arbeit“, „Benutzerdefiniert“ und „Chats“ auf und bietet eine einzige Aktion „Neue Sitzung“, die den Entwurfsdialog öffnet. Das Öffnen einer sichtbaren Zeile verschiebt nur die Hervorhebung. Benutzerdefinierte Gruppen können eingeklappt und per Drag-and-drop neu angeordnet werden, und Sitzungen können auf eine Gruppe oder „Chats“ gezogen werden; Gruppennamen und Reihenfolge werden über den Gateway synchronisiert, während der eingeklappte Zustand im Browser verbleibt. Eine neue Dashboard-Sitzung erhält asynchron einen prägnanten generierten Titel aus ihrer ersten Nachricht, die kein Befehl ist; explizite Namen werden niemals ersetzt. Legen Sie agents.defaults.utilityModel (oder agents.list[].utilityModel) fest, um diesen separaten Modellaufruf an ein kostengünstigeres Modell weiterzuleiten. Wenn Sie einen anderen Agentenabschnitt erweitern, können Sie die Sitzungen dieses Agenten durchsuchen, ohne den geöffneten Chat zu verlassen.
• Die Sitzungssuche befindet sich in der Befehlspalette (⌘K oder das Suchfeld oben in der Seitenleiste): Bei Eingabe einer Suchanfrage wird eine begrenzte Anzahl übereinstimmender Seiten über Agenten hinweg durchsucht, interne untergeordnete/Cron-Zeilen werden herausgefiltert und sichtbare Treffer neben Navigationsbefehlen aufgelistet. Die Seite „Sitzungen“ enthält weiterhin die vollständige durchsuchbare Liste mit Filtern.
• Jede Zeile der Seitenleiste bietet weiterhin direkten Zugriff auf das Anheften sowie ein vollständiges Kontextmenü für den Ungelesen-Status, Umbenennen, Forken, Gruppieren, Archivieren und Löschen. Mehrfach ausgewählte Zeilen (Cmd-/Ctrl-Klick, Umschalt-Klick für Bereiche) erhalten ein Stapelmenü für den Ungelesen-Status, die Gruppierung, Archivierung und Löschung; die Stapelarchivierung/-löschung bleibt deaktiviert, sofern nicht jede ausgewählte Sitzung archiviert werden kann. Ein aktiver Lauf und die Hauptsitzung eines Agenten können nicht archiviert werden. Wenn die aktuell ausgewählte Sitzung archiviert oder gelöscht wird, wechselt „Chat“ zurück zur Hauptsitzung dieses Agenten.
• In der macOS-App verwendet das OpenClaw-Zeichen den ansonsten leeren nativen Titelleistenbereich neben den Fenstersteuerelementen, statt eine Zeile in der Seitenleiste zu belegen.
• Bei Desktopbreiten bleiben die Chatsteuerelemente in einer einzigen kompakten Zeile und werden beim Abwärtsscrollen im Transkript eingeklappt; Aufwärtsscrollen, die Rückkehr zum Anfang oder das Erreichen des Endes stellt die Steuerelemente wieder her.
• Aufeinanderfolgende identische reine Textnachrichten werden als eine Sprechblase mit einem Zähler-Badge dargestellt. Nachrichten mit Bildern, Anhängen, Tool-Ausgaben oder Canvas-Vorschauen werden nicht zusammengefasst.
• Wenn sich der Checkout einer Sitzung auf einem Nicht-Standard-Branch eines GitHub-Repositorys befindet, heftet die Chatansicht Pull-Request-Chips oberhalb des Eingabebereichs an: PR-Nummer, Repository, Branch, Diff-Anzahlen, eine CI-Kapsel sowie Entwurfs-/Zusammengeführt-/Geschlossen-Status, jeweils mit einem Link zum PR. Die Zeile zeigt höchstens zwei Chips – Live-PRs (offen/Entwurf) zuerst – und eine Schaltfläche „Mehr anzeigen“ blendet den eingeklappten Verlauf zusammengeführter/geschlossener PRs ein. Die CI-Kapsel öffnet ein kleines CI-Überwachungs-Popover mit der Anzahl erfolgreicher/fehlgeschlagener/laufender/übersprungener Prüfungen und einem Link zur Prüfungsseite des PRs. Die Erkennung erfolgt serverseitig über controlUi.sessionPullRequests, das die GH_TOKEN/GITHUB_TOKEN des Gateways wiederverwendet, sofern sie festgelegt sind. Wenn das Ratenlimit der GitHub-API erreicht ist, behalten die Chips den zuletzt bekannten Status bei und zeigen eine Warnung an, dass der Status möglicherweise veraltet ist; durch Verwerfen eines Chips wird er für diese Sitzung im aktuellen Browserprofil ausgeblendet. Bevor ein PR vorhanden ist, zeigt die Zeile den Branch selbst an – Repository, Branchname und die +/−-Größe des Diffs gegenüber der Merge-Basis des Standard-Branchs (committete und nicht committete Arbeit) – sowie eine Schaltfläche „PR erstellen“, die GitHubs Seite für neue Pull Requests öffnet. Die Zeile erscheint, sobald der gepushte Branch vergleichbare Commits enthält, und blendet sich aus, solange ein offener PR oder PR-Entwurf vorhanden ist. Die Branchzeile stammt ausschließlich aus dem lokalen Git und bleibt daher auch bei einer Ratenbegrenzung durch GitHub verfügbar; sie zeigt dieselbe Warnung vor einem möglicherweise veralteten Status, da „kein PR gefunden“ erst nach Zurücksetzen des Limits als verlässlich gelten kann.
• Das Sitzungs-Diff-Panel zeigt, was der Checkout einer Sitzung tatsächlich geändert hat: Die Branch-Schaltfläche (im Kopfbereich der Arbeitsbereichsleiste, im Kopfbereich des geteilten Fensters oder als schwebende Schaltfläche im Chat mit einem Fenster) öffnet das Detailpanel mit einem Diff pro Datei für Branch-, nicht committete und nicht nachverfolgte Änderungen gegenüber der Merge-Basis des Standard-Branchs des Checkouts – Statuspunkt, Umbenennungspfeil, +/−-Anzahlen pro Datei, einklappbare Dateien und Markierungen für „N unveränderte Zeilen“ zwischen Hunk-Abschnitten. Diffs werden serverseitig über die Gateway-Methode sessions.diff (Geltungsbereich operator.read) berechnet; Binärdateien und übergroße Dateien werden auf reine Statistikeinträge reduziert, und die Schaltfläche wird nur angezeigt, wenn der verbundene Gateway sessions.diff ankündigt.
• Die Sitzungs-Arbeitsbereichsleiste in jedem Chatfenster führt Sitzungsdateien, Projektdateien und Artefakte auf. Standardmäßig ist sie am rechten Rand des Fensters angedockt; ziehen Sie ihren Kopfbereich (oder verwenden Sie die Andockschaltfläche), um sie nach unten zu verschieben. Die Auswahl wird im aktuellen Browserprofil gespeichert. Eine eingeklappte Leiste belegt überhaupt keinen Platz: Öffnen Sie sie mit ⇧⌘B, dem Dateischalter im Kopfbereich des geteilten Fensters oder der schwebenden Dateischaltfläche im Chat mit einem Fenster erneut (beide tragen ein Badge mit der Anzahl geänderter Dateien). Das separate Detailpanel für Dateien, Tools und Canvas bleibt davon unberührt.
• Wenn Sie im Chat auf eine Dateireferenz, in einer erweiterten Tool-Karte zum Lesen/Bearbeiten/Schreiben auf einen Dateipfad oder in der Arbeitsbereichsleiste auf eine Dateizeile klicken, wird das Datei-Detailpanel geöffnet: eine Codeansicht auf CodeMirror-Basis mit Syntaxhervorhebung, Zeilennummern, Sprung zu einer Zeile, dateiinterner Suche, Kopieraktionen und einem Menü zum Öffnen in einem externen Editor. Wenn der Gateway gegenüber einer Verbindung mit operator.admin sessions.files.set ankündigt, fügt das Panel einen Bearbeitungsmodus mit Änderungsverfolgung und Speichern per Cmd/Ctrl-S hinzu; nicht gespeicherte Entwürfe überdauern Datei-, Panel- und Sitzungsnavigation im aktuellen Browser-Tab, bis sie ausdrücklich gespeichert oder verworfen werden. Speichervorgänge verwenden Compare-and-Swap mit einem von sessions.files.get zurückgegebenen Inhalts-Hash: Wenn die Datei seit dem Laden auf dem Datenträger geändert wurde (zum Beispiel weil der Agent weitergearbeitet hat), zeigt das Panel einen Konflikthinweis mit den Aktionen „Neu laden“ (neuesten Inhalt übernehmen) und „Überschreiben“ (lokale Bearbeitung beibehalten). Schreibvorgänge durchlaufen dieselben dateisystemsicheren Arbeitsbereichsschutzprüfungen wie Lesevorgänge – Pfadbegrenzung, Ablehnung von symbolischen und festen Links sowie ein UTF-8-Limit von 256 KB – und überschreiben ausschließlich vorhandene Dateien; der Editor erstellt oder löscht niemals Dateien.
• Die Leiste für Hintergrundaufgaben in jedem Chatfenster führt die Hintergrundaufgaben und Subagenten des aktuellen Agenten auf (tasks.list, nach Agent gefiltert und durch task-Ereignisse aktuell gehalten): Laufende Arbeit zeigt einen live aktualisierten Zeitgeber für die verstrichene Zeit, die Anzahl der Tool-Verwendungen, das aktuell verwendete Tool und ein Steuerelement zum Anhalten; der einklappbare Abschnitt für abgeschlossene Aufgaben ergänzt Laufzeiten; und ein Link „Transkript anzeigen“ öffnet die untergeordnete Sitzung der Aufgabe im Fenster. Öffnen Sie sie mit dem Aktivitätsschalter im Kopfbereich des geteilten Fensters oder der schwebenden Aktivitätsschaltfläche im Chat mit einem Fenster – der Aufgabenschnappschuss wird vorab geladen, sodass beide ein Badge mit der Anzahl laufender Aufgaben anzeigen, ohne dass die Leiste zuerst geöffnet werden muss. Die Seite „Aufgaben“ bleibt das vollständige agentenübergreifende Verzeichnis.
• Die Arbeitsbereichsleiste, die Leiste für Hintergrundaufgaben und das Detailpanel passen sich an die jeweilige Breite jedes Fensters statt an die Fensterbreite an: In einem schmalen Fenster oder einem kompakten Gesamtfenster werden beide Leisten als untere Streifen dargestellt (Steuerelemente zum seitlichen Andocken werden ausgeblendet, bis das Fenster breiter wird; die Arbeitsbereichsleiste hat Vorrang auf dem seitlichen Platz, wenn nur eine Spalte hineinpasst), und das Detailpanel wird unterhalb des Threads mit einem horizontalen Griff zur Größenänderung gestapelt, statt die Zeile mit ihm zu teilen. Ansichtsbereiche in Telefongröße öffnen das Detailpanel weiterhin im Vollbildmodus.
• Die Modell- und Denkmodus-Auswahlfelder im Chatkopf aktualisieren die aktive Sitzung sofort über sessions.patch; sie sind dauerhafte Sitzungsüberschreibungen und keine Sendeoptionen, die nur für einen Durchlauf gelten.
• Geteilte Ansicht: Öffnen Sie sie über die schwebende Schalterzeile oben rechts (neben den Schaltern für Sitzungs-Diff, Hintergrundaufgaben und Sitzungsdateien) und teilen Sie anschließend das aktive Fenster nach rechts oder unten, bis so viele Fenster vorhanden sind, wie hineinpassen. Jedes Fenster besitzt eine eigene Sitzung, ein eigenes Transkript, einen eigenen Eingabebereich und einen eigenen Tool-Stream.
• Ziehen Sie eine Sitzung aus der Seitenleiste in den Chat, um sie in einem Fenster zu öffnen. Eine animierte Ablagevorschau gleitet zwischen Zonen und kennzeichnet das Ergebnis – „Teilen“ über genau der Hälfte, die ein neues Fenster einnehmen wird, „Hier öffnen“ über einem vollständigen Fenster – und das Ablegen funktioniert auch im Modus mit einem Fenster.
• Das aktive geteilte Fenster steuert die Auswahl in der Seitenleiste und die URL. Jedes Fenster besitzt eine eigene Kopfzeile mit dem Sitzungstitel sowie Steuerelementen für die Arbeitsbereichsleiste, das Teilen und Schließen; Trennlinien ändern die Größe von Spalten und gestapelten Fenstern, und der Browser speichert das Layout lokal über Neuladungen hinweg.
• Auf schmalen Bildschirmen behält die geteilte Ansicht das Layout bei, stellt jedoch nur das aktive Fenster dar, einschließlich seiner Kopfzeile mit dem Steuerelement zum Schließen.
• Wenn Sie eine Nachricht senden, während eine Änderung der Modellauswahl für dieselbe Sitzung noch gespeichert wird, wartet der Eingabebereich auf diesen Sitzungspatch, bevor chat.send aufgerufen wird, sodass beim Senden das ausgewählte Modell verwendet wird.
• Die Eingabe von /new erstellt dieselbe neue Dashboard-Sitzung wie „Neuer Chat“ und wechselt zu ihr, außer wenn session.dmScope: "main" konfiguriert ist und die aktuelle übergeordnete Sitzung die Hauptsitzung des Agenten ist; dann wird die Hauptsitzung direkt zurückgesetzt. Die Eingabe von /reset behält das explizite direkte Zurücksetzen des Gateways für die aktuelle Sitzung bei.
• Die Chat-Modellauswahl fordert die konfigurierte Modellansicht des Gateways an. Wenn agents.defaults.models vorhanden ist, steuert diese Zulassungsliste die Auswahl, einschließlich provider/*-Einträgen, durch die Provider-bezogene Kataloge dynamisch bleiben. Andernfalls zeigt die Auswahl explizite models.providers.*.models-Einträge sowie Provider mit verwendbarer Authentifizierung an. Der vollständige Katalog bleibt über den Debug-RPC models.list mit view: "all" verfügbar.
• Wenn aktuelle Nutzungsberichte der Gateway-Sitzung die aktuelle Anzahl der Kontext-Token enthalten, zeigt die Symbolleiste des Chat-Eingabefelds einen kleinen Ring für die Kontextnutzung mit dem verwendeten Prozentsatz an. Öffnen Sie den Ring, um das aktuelle Kontextfenster, die Token-Anzahlen des letzten Durchlaufs und die geschätzten Gesamtkosten, die Provider-/Modellidentität sowie – sofern gemeldet – die Aufschlüsselung der Eingabe-, Ausgabe- und Cache-Kosten der neuesten Provider-Antwort anzuzeigen. Bei hoher Kontextauslastung wechselt der Ring zu einem Warnungsstil und zeigt bei empfohlenen Compaction-Schwellenwerten eine kompakte Schaltfläche an, die den normalen Compaction-Pfad der Sitzung ausführt. Veraltete Token-Momentaufnahmen werden ausgeblendet, bis das Gateway erneut aktuelle Nutzungsdaten meldet.

Der Sprechmodus verwendet einen registrierten Echtzeit-Sprach-Provider. Konfigurieren Sie OpenAI mit talk.realtime.provider: "openai" sowie einem openai-API-Schlüsselprofil, talk.realtime.providers.openai.apiKey oder OPENAI_API_KEY. OpenAI Realtime verwendet die öffentliche Platform API und erfordert einen Platform-API-Schlüssel; eine Codex-OAuth-Anmeldung reicht für diese Schnittstelle nicht aus. Konfigurieren Sie Google mit talk.realtime.provider: "google" sowie talk.realtime.providers.google.apiKey. Der Browser erhält niemals einen regulären Provider-API-Schlüssel: OpenAI erhält ein kurzlebiges Realtime-Client-Secret für WebRTC, und Google Live erhält ein einmalig verwendbares, eingeschränktes Live-API-Authentifizierungstoken für eine Browser-WebSocket-Sitzung, wobei Anweisungen und Tool-Deklarationen durch den Gateway im Token festgeschrieben werden. Provider, die nur eine Backend-Echtzeit-Bridge bereitstellen, werden über den Gateway-Relay-Transport ausgeführt, sodass Zugangsdaten und Provider-Sockets serverseitig verbleiben, während Browser-Audio über authentifizierte Gateway-RPCs übertragen wird. Der Prompt der Realtime-Sitzung wird vom Gateway zusammengestellt; talk.client.create akzeptiert keine vom Aufrufer bereitgestellten Überschreibungen der Anweisungen.

Dauerhafte Standardwerte für Provider, Modell, Stimme, Transport, Reasoning-Aufwand, exakten VAD-Schwellenwert, Stilledauer und Präfix-Padding befinden sich unter Einstellungen → Kommunikation → Sprechen; Änderungen erfordern operator.admin-Zugriff. Die Konfiguration des Gateway-Relays erzwingt den Backend-Relay-Pfad; bei der Konfiguration von WebRTC verbleibt die Sitzung unter Kontrolle des Clients und schlägt fehl, statt stillschweigend auf das Relay zurückzufallen, wenn der Provider keine Browser-Sitzung erstellen kann.

Das Bedienelement für Sprechen ist die Mikrofonschaltfläche in der Composer-Symbolleiste. Ihr Aufklappmenü listet System default und jedes vom Browser bereitgestellte Mikrofon auf, einschließlich USB-, Bluetooth- und virtueller Eingänge. Die ausgewählte Geräte-ID bleibt lokal im Browser und wird niemals an den Gateway gesendet; wenn genau dieses Gerät nicht mehr verfügbar ist, fordert Sprechen Sie auf, einen anderen Eingang auszuwählen, statt stillschweigend über ein anderes Mikrofon aufzunehmen. Während Sprechen aktiv ist, wird die Mikrofonschaltfläche zu einer pillenförmigen Anzeige mit dem aktuellen Eingangspegel; ein Klick darauf beendet die Spracheingabe, und beim Darüberfahren wird das Stopp-Symbol eingeblendet. Screenreader geben Connecting voice input..., Listening... oder Asking OpenClaw... aus, während ein Echtzeit-Tool-Aufruf über talk.client.toolCall das konfigurierte größere Modell abfragt. Das Stoppen einer laufenden Agentenantwort bleibt ein separates quadratisches Bedienelement Stopp neben der pillenförmigen Anzeige.

Live-Smoke-Test für Maintainer: OPENAI_API_KEY=... GEMINI_API_KEY=... node --import tsx scripts/dev/realtime-talk-live-smoke.ts überprüft die OpenAI-Backend-WebSocket-Bridge, den OpenAI-Browser-WebRTC-SDP-Austausch, die Einrichtung des Google-Live-Browser-WebSockets mit eingeschränktem Token und den Gateway-Relay-Browseradapter mit simulierten Mikrofonmedien. Der Befehl gibt nur den Provider-Status aus und protokolliert keine Secrets.

• Klicken Sie auf Stopp (ruft chat.abort auf).
• Während ein Lauf aktiv ist, werden normale Folgeanfragen in die Warteschlange gestellt. Klicken Sie bei einer Nachricht in der Warteschlange auf Steuern, um diese Folgeanfrage in den laufenden Turn einzufügen.
• Geben Sie /stop (oder eigenständige Abbruchformulierungen wie stop, stop action, stop run, stop openclaw, please stop) ein, um außerhalb des regulären Ablaufs abzubrechen.
• chat.abort unterstützt { sessionKey } (ohne runId), um alle aktiven Läufe dieser Sitzung abzubrechen.

• Wenn ein Lauf abgebrochen wird, kann unvollständiger Assistententext weiterhin in der Benutzeroberfläche angezeigt werden.
• Der Gateway speichert bei vorhandener gepufferter Ausgabe abgebrochenen unvollständigen Assistententext dauerhaft im Transkriptverlauf.
• Gespeicherte Einträge enthalten Abbruchmetadaten, damit Transkriptverbraucher unvollständige Abbruchausgaben von regulär abgeschlossenen Ausgaben unterscheiden können.

{  gateway: {    controlUi: { allowInsecureAuth: true },    bind: "tailnet",    auth: { mode: "token", token: "replace-me" },  },}

allowInsecureAuth ist ausschließlich ein lokaler Kompatibilitätsschalter:

• Er ermöglicht Control-UI-Sitzungen auf localhost, in nicht sicheren HTTP-Kontexten ohne Geräteidentität fortzufahren.
• Er umgeht keine Kopplungsprüfungen.
• Er lockert nicht die Anforderungen an die Geräteidentität für entfernte Verbindungen (außerhalb von localhost).

• Eine erfolgreiche Authentifizierung über einen vertrauenswürdigen Proxy kann Control-UI-Sitzungen für Operatoren ohne Geräteidentität zulassen.
• Dies gilt nicht für Control-UI-Sitzungen mit Node-Rolle.
• Loopback-Reverse-Proxys auf demselben Host erfüllen die Authentifizierung über einen vertrauenswürdigen Proxy weiterhin nicht; siehe Authentifizierung über vertrauenswürdige Proxys.

• gatewayUrl wird nach dem Laden in localStorage gespeichert und aus der URL entfernt.
• Wenn Sie über gatewayUrl einen vollständigen ws://- oder wss://-Endpunkt übergeben, URL-codieren Sie den Wert, damit der Browser die Abfragezeichenfolge korrekt verarbeitet.
• token sollte nach Möglichkeit über das URL-Fragment (#token=...) übergeben werden. Fragmente werden nicht an den Server gesendet, wodurch eine Offenlegung in Anfrageprotokollen und über den Referer vermieden wird. Veraltete ?token=-Abfrageparameter werden aus Kompatibilitätsgründen weiterhin einmalig importiert, jedoch nur als Rückfalloption, und unmittelbar nach dem Startvorgang entfernt.
• password wird ausschließlich im Arbeitsspeicher gehalten.
• Wenn gatewayUrl festgelegt ist, greift die UI nicht auf Anmeldedaten aus der Konfiguration oder Umgebung zurück. Geben Sie token (oder password) ausdrücklich an; fehlende ausdrücklich angegebene Anmeldedaten sind ein Fehler.
• Verwenden Sie wss://, wenn sich das Gateway hinter TLS befindet (Tailscale Serve, HTTPS-Proxy usw.).
• gatewayUrl wird ausschließlich in einem Fenster der obersten Ebene akzeptiert (nicht eingebettet), um Clickjacking zu verhindern.
• Öffentliche Control-UI-Bereitstellungen außerhalb von Loopback müssen gateway.controlUi.allowedOrigins ausdrücklich festlegen (vollständige Ursprünge). Private LAN-/Tailnet-Ladevorgänge desselben Ursprungs von Loopback-, RFC1918-/Link-Local-, .local-, .ts.net- oder Tailscale-CGNAT-Hosts werden akzeptiert, ohne den Rückfall auf den Host-Header zu aktivieren.
• Beim Start des Gateways können lokale Ursprünge wie http://localhost:<port> und http://127.0.0.1:<port> anhand der wirksamen Laufzeitbindung und des Ports vorbelegt werden; entfernte Browserursprünge benötigen jedoch weiterhin ausdrückliche Einträge.
• Verwenden Sie gateway.controlUi.allowedOrigins: ["*"] ausschließlich für streng kontrollierte lokale Tests; dies bedeutet, jeden Browserursprung zuzulassen, nicht „den jeweils von mir verwendeten Host abzugleichen“.
• gateway.controlUi.dangerouslyAllowHostHeaderOriginFallback=true aktiviert den Modus für den Rückfall auf den Host-Header-Ursprung, stellt jedoch einen gefährlichen Sicherheitsmodus dar.