Steuerungs-UI

• Chatten Sie mit dem Modell über Gateway WS (chat.history, chat.send, chat.abort, chat.inject).
• Aktualisierungen des Chatverlaufs fordern ein begrenztes aktuelles Fenster mit Textobergrenzen pro Nachricht an, damit große Sitzungen den Browser nicht zwingen, eine vollständige Transkript-Nutzlast zu rendern, bevor der Chat nutzbar wird.
• Sprechen Sie über Browser-Echtzeitsitzungen. OpenAI verwendet direktes WebRTC, Google Live verwendet ein eingeschränktes Einmal-Browser-Token über WebSocket, und reine Backend-Echtzeit-Sprach-Plugins verwenden den Gateway-Relay-Transport. Client-eigene Provider-Sitzungen starten mit talk.client.create; Gateway-Relay-Sitzungen starten mit talk.session.create. Das Relay hält Provider-Anmeldeinformationen auf dem Gateway, während der Browser Mikrofon-PCM über talk.session.appendAudio streamt, openclaw_agent_consult-Provider-Toolaufrufe über talk.client.toolCall für Gateway-Richtlinien und das größere konfigurierte OpenClaw-Modell weiterleitet und Sprachsteuerung für aktive Läufe über talk.client.steer oder talk.session.steer routet.
• Toolaufrufe + Live-Tool-Ausgabekarten im Chat streamen (Agentenereignisse).
• Aktivitäts-Tab mit browserlokalen, auf Schwärzung ausgerichteten Zusammenfassungen der Live-Toolaktivität aus vorhandener session.tool- / Tool-Ereigniszustellung.

• Kanäle: integrierter Status plus Status gebündelter/externer Plugin-Kanäle, QR-Anmeldung und Konfiguration pro Kanal (channels.status, web.login.*, config.patch).
• Aktualisierungen von Kanalprüfungen halten den vorherigen Snapshot sichtbar, während langsame Provider-Prüfungen abgeschlossen werden, und Teilsnapshots werden gekennzeichnet, wenn eine Prüfung oder ein Audit das UI-Budget überschreitet.
• Instanzen: Anwesenheitsliste + Aktualisierung (system-presence).
• Sitzungen: konfigurierten Agentensitzungen standardmäßig auflisten, häufige Sitzungen anheften, umbenennen, inaktive Sitzungen archivieren oder wiederherstellen, von veralteten Sitzungsschlüsseln nicht konfigurierter Agenten zurückfallen und modell-/thinking-/fast-/verbose-/trace-/reasoning-Überschreibungen pro Sitzung anwenden (sessions.list, sessions.patch). Angeheftete Sitzungen werden oberhalb aktueller nicht angehefteter Sitzungen sortiert; archivierte Sitzungen befinden sich in der Archivansicht der Sitzungsseite und behalten ihre Transkripte.
• Träume: Dreaming-Status, Umschalter zum Aktivieren/Deaktivieren und Dream Diary-Leser (doctor.memory.status, doctor.memory.dreamDiary, config.patch).

• Cron-Jobs: auflisten/hinzufügen/bearbeiten/ausführen/aktivieren/deaktivieren + Ausführungsverlauf (cron.*).
• Skills: Status, aktivieren/deaktivieren, installieren, API-Schlüssel aktualisieren (skills.*).
• Knoten: auflisten + Obergrenzen (node.list), mobile Einrichtungscodes erstellen und Gerätekopplung genehmigen (device.pair.*).
• Exec-Genehmigungen: Allowlists für Gateway oder Knoten bearbeiten + Abfragerichtlinie für exec host=gateway/node (exec.approvals.*).

• ~/.openclaw/openclaw.json anzeigen/bearbeiten (config.get, config.set).
• MCP hat eine eigene Einstellungsseite für konfigurierte Server, Aktivierung, OAuth-/Filter-/Parallel-Zusammenfassungen, gängige Operator-Befehle und den bereichsbezogenen mcp-Konfigurationseditor.
• Anwenden + Neustart mit Validierung (config.apply) und die zuletzt aktive Sitzung aufwecken.
• Schreibvorgänge enthalten einen Base-Hash-Schutz, um das Überschreiben gleichzeitiger Bearbeitungen zu verhindern.
• Schreibvorgänge (config.set/config.apply/config.patch) prüfen die aktive SecretRef-Auflösung für Refs in der übermittelten Konfigurationsnutzlast vorab; nicht aufgelöste aktive übermittelte Refs werden vor dem Schreiben abgelehnt.
• Form-Speicherungen verwerfen veraltete redigierte Platzhalter, die aus der gespeicherten Konfiguration nicht wiederhergestellt werden können, während redigierte Werte erhalten bleiben, die weiterhin gespeicherten Secrets zugeordnet sind.
• Schema- + Formular-Rendering (config.schema / config.schema.lookup, einschließlich Feld-title / description, übereinstimmender UI-Hinweise, unmittelbarer untergeordneter Zusammenfassungen, Docs-Metadaten auf verschachtelten Objekt-/Wildcard-/Array-/Kompositionsknoten, plus Plugin- + Channel-Schemas, sofern verfügbar); der Raw-JSON-Editor ist nur verfügbar, wenn der Snapshot einen sicheren Raw-Roundtrip hat.
• Wenn ein Snapshot Raw-Text nicht sicher per Roundtrip verarbeiten kann, erzwingt die Control UI den Formularmodus und deaktiviert den Raw-Modus für diesen Snapshot.
• Der Raw-JSON-Editor „Auf Gespeichertes zurücksetzen“ bewahrt die raw verfasste Form (Formatierung, Kommentare, $include-Layout), statt einen abgeflachten Snapshot neu zu rendern, sodass externe Änderungen einen Reset überstehen, wenn der Snapshot sicher per Roundtrip verarbeitet werden kann.
• Strukturierte SecretRef-Objektwerte werden in Formular-Texteingaben schreibgeschützt gerendert, um versehentliche Objekt-zu-String-Beschädigungen zu verhindern.

• Debug: Status-/Integritäts-/Modell-Snapshots + Ereignisprotokoll + manuelle RPC-Aufrufe (status, health, models.list).
• Das Ereignisprotokoll enthält Control-UI-Aktualisierungs-/RPC-Timings, langsame Chat-/Konfigurations-Render-Timings und Einträge zur Browser-Reaktionsfähigkeit für lange Animationsframes oder Long Tasks, wenn der Browser diese PerformanceObserver-Eintragstypen bereitstellt.
• Logs: Live-Tail der Gateway-Datei-Logs mit Filter/Export (logs.tail).
• Update: Paket-/Git-Update + Neustart (update.run) mit Neustartbericht ausführen, dann nach der Wiederverbindung update.status abfragen, um die laufende Gateway-Version zu überprüfen.

• Für isolierte Jobs ist die Zustellung standardmäßig auf Ankündigungszusammenfassung eingestellt. Sie können auf „Keine“ umstellen, wenn Sie rein interne Läufe wünschen.
• Channel-/Ziel-Felder werden angezeigt, wenn „Ankündigen“ ausgewählt ist.
• Der Webhook-Modus verwendet delivery.mode = "webhook" mit delivery.to, das auf eine gültige HTTP(S)-Webhook-URL gesetzt ist.
• Für Hauptsitzungs-Jobs sind die Zustellmodi Webhook und „Keine“ verfügbar.
• Erweiterte Bearbeitungssteuerelemente umfassen Nach-Ausführung-löschen, Agent-Override löschen, exakte/gestaffelte Cron-Optionen, Agent-Modell-/Thinking-Overrides und Best-Effort-Zustellungsumschalter.
• Die Formularvalidierung erfolgt inline mit Fehlern auf Feldebene; ungültige Werte deaktivieren die Speichern-Schaltfläche, bis sie korrigiert sind.
• Setzen Sie cron.webhookToken, um ein dediziertes Bearer-Token zu senden; wenn es ausgelassen wird, wird der Webhook ohne Auth-Header gesendet.
• Veralteter Fallback: Führen Sie openclaw doctor --fix aus, um gespeicherte Legacy-Jobs mit notify: true von cron.webhook zu expliziter Webhook- oder Abschlusszustellung pro Job zu migrieren.

• chat.send ist nicht blockierend: Es bestätigt sofort mit { runId, status: "started" }, und die Antwort streamt über chat-Ereignisse. Vertrauenswürdige Control-UI-Clients können außerdem optionale ACK-Timing-Metadaten für lokale Diagnosen erhalten.
• Chat-Uploads akzeptieren Bilder sowie Nicht-Video-Dateien. 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.
• chat.history-Antworten sind zur UI-Sicherheit größenbegrenzt. Wenn Transkripteinträge zu groß sind, kann Gateway lange Textfelder kürzen, umfangreiche Metadatenblöcke weglassen 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 der Seitenleser den vollständigen anzeigennormalisierten Transkripteintrag bei Bedarf über chat.message.get anhand von sessionKey, aktivem agentId falls erforderlich und Transkript-messageId abrufen. Wenn Gateway weiterhin nicht mehr zurückgeben kann, zeigt der Leser einen expliziten Nicht-verfügbar-Zustand, statt stillschweigend die gekürzte Vorschau zu wiederholen.
• Vom Assistenten generierte Bilder werden als verwaltete Medienreferenzen persistiert und über authentifizierte Gateway-Medien-URLs zurückgeliefert, sodass Neuladevorgänge nicht davon abhängen, dass rohe base64-Bildnutzlasten in der Chat-Verlaufsantwort erhalten bleiben.
• Beim Rendern von chat.history entfernt die Control UI reine Anzeige-Inline-Direktiv-Tags aus sichtbarem Assistententext (zum Beispiel [[reply_to_*]] und [[audio_as_voice]]), Klartext-Tool-Call-XML-Nutzlasten (einschließlich <tool_call>...</tool_call>, <function_call>...</function_call>, <tool_calls>...</tool_calls>, <function_calls>...</function_calls> und gekürzter Tool-Call-Blöcke) sowie durchgesickerte ASCII-/Vollbreiten-Modellsteuerungstokens und lässt Assistenteneinträge aus, deren gesamter sichtbarer Text nur aus dem exakten stillen Token NO_REPLY / no_reply oder dem Heartbeat-Bestätigungstoken HEARTBEAT_OK besteht.
• Während eines aktiven Sendevorgangs und der abschließenden Verlaufsaktualisierung hält die Chat-Ansicht lokale optimistische Benutzer-/Assistentennachrichten sichtbar, wenn chat.history kurzzeitig einen älteren Snapshot zurückgibt; das kanonische Transkript ersetzt diese lokalen Nachrichten, sobald der Gateway-Verlauf aufgeholt hat.
• Live-chat-Ereignisse sind Zustellungsstatus, während chat.history aus dem dauerhaften Sitzungstranskript neu aufgebaut wird. Nach finalen Tool-Ereignissen lädt die Control UI den Verlauf neu und führt nur einen kleinen optimistischen Ausläufer zusammen; die Transkriptgrenze ist in WebChat dokumentiert.
• chat.inject hängt eine Assistentennotiz an das Sitzungstranskript an und sendet ein chat-Ereignis für reine UI-Updates (kein Agent-Lauf, keine Channel-Zustellung).
• Die Seitenleiste listet aktuelle Sitzungen mit einer Aktion „Neue Sitzung“, einem Link „Alle Sitzungen“ und einer Sitzungssuchschaltfläche auf, die den vollständigen Sitzungsauswähler öffnet (begrenzt auf den ausgewählten Agent, mit Suche und Paginierung). Beim Wechseln von Agenten werden nur Sitzungen angezeigt, die diesem Agent zugeordnet sind; wenn noch keine Dashboard-Sitzungen gespeichert sind, wird auf die Hauptsitzung dieses Agenten zurückgegriffen.
• Jede Zeile im Sitzungsauswähler kann die Sitzung umbenennen, anheften oder archivieren. Ein aktiver Lauf und die Hauptsitzung eines Agenten können nicht archiviert werden. Wird die aktuell ausgewählte Sitzung archiviert, wechselt Chat zurück zur Hauptsitzung dieses Agenten.
• Bei Desktop-Breiten bleiben Chat-Steuerelemente in einer kompakten Zeile und werden beim Herunterscrollen im Transkript eingeklappt; beim Hochscrollen, beim Zurückkehren nach oben oder beim Erreichen des unteren Endes werden die Steuerelemente wiederhergestellt.
• Aufeinanderfolgende doppelte reine Textnachrichten werden als eine Sprechblase mit einem Zähl-Badge gerendert. Nachrichten mit Bildern, Anhängen, Tool-Ausgabe oder Canvas-Vorschauen bleiben nicht eingeklappt.
• Die Modell- und Thinking-Auswähler im Chat-Header patchen die aktive Sitzung sofort über sessions.patch; sie sind persistente Sitzungs-Overrides, keine nur für einen Turn geltenden Sendeoptionen.
• Wenn Sie eine Nachricht senden, während eine Änderung am Modellauswähler für dieselbe Sitzung noch gespeichert wird, wartet der Composer auf diesen Sitzungs-Patch, bevor chat.send aufgerufen wird, damit der Sendevorgang das ausgewählte Modell verwendet.
• Wenn Sie in der Control UI /new eingeben, wird dieselbe frische Dashboard-Sitzung wie bei „Neuer Chat“ erstellt und dorthin gewechselt, außer wenn session.dmScope: "main" konfiguriert ist und der aktuelle Parent die Hauptsitzung des Agenten ist; in diesem Fall wird die Hauptsitzung an Ort und Stelle zurückgesetzt. Die Eingabe von /reset behält den expliziten In-Place-Reset des Gateways für die aktuelle Sitzung bei.
• Der Chat-Modellauswähler fordert die konfigurierte Modellansicht des Gateways an. Wenn agents.defaults.models vorhanden ist, steuert diese Allowlist den Auswähler, einschließlich provider/*-Einträgen, die provider-bezogene Kataloge dynamisch halten. Andernfalls zeigt der Auswähler explizite models.providers.*.models-Einträge sowie Provider mit verwendbarer Auth an. Der vollständige Katalog bleibt über den Debug-RPC models.list mit view: "all" verfügbar.
• Wenn frische Gateway-Sitzungsnutzungsberichte aktuelle Kontexttokens enthalten, zeigt die Chat-Composer-Symbolleiste einen kleinen Kontextnutzungsring mit dem verwendeten Prozentsatz; die vollständigen Token-Details befinden sich im Tooltip. Der Ring wechselt bei hohem Kontextdruck zu Warn-Styling und zeigt bei empfohlenen Compaction-Stufen eine kompakte Schaltfläche, die den normalen Sitzung-Compaction-Pfad ausführt. Veraltete Token-Snapshots werden ausgeblendet, bis Gateway erneut frische Nutzung meldet.

Der Sprechmodus verwendet einen registrierten Echtzeit-Sprach-Provider. Konfigurieren Sie OpenAI mit talk.realtime.provider: "openai" plus einem openai-API-Key-Auth-Profil, talk.realtime.providers.openai.apiKey oder OPENAI_API_KEY; OpenAI-OAuth-Profile konfigurieren keine Echtzeit-Sprache. Konfigurieren Sie Google mit talk.realtime.provider: "google" plus talk.realtime.providers.google.apiKey. Der Browser erhält niemals einen Standard-Provider-API-Key. OpenAI erhält ein flüchtiges Realtime-Client-Secret für WebRTC. Google Live erhält ein einmal verwendbares eingeschränktes Live-API-Auth-Token für eine Browser-WebSocket-Sitzung, wobei Anweisungen und Tool-Deklarationen vom Gateway im Token festgeschrieben werden. Provider, die nur eine Backend-Echtzeit-Bridge bereitstellen, laufen über den Gateway-Relay-Transport, sodass Zugangsdaten und Vendor-Sockets serverseitig bleiben, während Browser-Audio über authentifizierte Gateway-RPCs übertragen wird. Der Realtime-Sitzungsprompt wird vom Gateway zusammengestellt; talk.client.create akzeptiert keine vom Aufrufer bereitgestellten Instruction-Overrides.

Der Chat-Composer enthält neben der Schaltfläche zum Starten/Stoppen von Talk eine Schaltfläche für Talk-Optionen. Die Optionen gelten für die nächste Talk-Sitzung und können Provider, Transport, Modell, Stimme, Reasoning-Aufwand, VAD-Schwellenwert, Stilledauer und Präfix-Padding überschreiben. Wenn eine Option leer ist, verwendet der Gateway konfigurierte Standardwerte, sofern verfügbar, oder den Provider-Standard. Die Auswahl von Gateway-Relay erzwingt den Backend-Relay-Pfad; die Auswahl von WebRTC hält die Sitzung im Besitz des Clients und schlägt fehl, statt stillschweigend auf Relay zurückzufallen, wenn der Provider keine Browser-Sitzung erstellen kann.

Im Chat-Composer ist das Talk-Steuerelement die Wellen-Schaltfläche neben der Mikrofon-Diktat-Schaltfläche. Wenn Talk startet, zeigt die Statuszeile des Composers Connecting Talk..., anschließend Talk live, während Audio verbunden ist, oder Asking OpenClaw..., während ein Echtzeit-Tool-Aufruf über talk.client.toolCall das konfigurierte größere Modell abfragt.

Maintainer-Live-Smoke: OPENAI_API_KEY=... GEMINI_API_KEY=... node --import tsx scripts/dev/realtime-talk-live-smoke.ts verifiziert die OpenAI-Backend-WebSocket-Bridge, den OpenAI-Browser-WebRTC-SDP-Austausch, die Google-Live-Browser-WebSocket-Einrichtung mit eingeschränkten Tokens und den Gateway-Relay-Browser-Adapter mit gefälschten Mikrofonmedien. Der Befehl gibt nur den Provider-Status aus und protokolliert keine Geheimnisse.

• Klicken Sie auf Stoppen (ruft chat.abort auf).
• Während ein Run aktiv ist, werden normale Anschlussnachrichten in die Warteschlange gestellt. Klicken Sie bei einer Nachricht in der Warteschlange auf Steuern, um diese Anschlussnachricht in den laufenden Turn einzuspeisen.
• Geben Sie /stop ein (oder eigenständige Abbruchformulierungen wie stop, stop action, stop run, stop openclaw, please stop), um out-of-band abzubrechen.
• chat.abort unterstützt { sessionKey } (kein runId), um alle aktiven Runs für diese Sitzung abzubrechen.

• Wenn ein Run abgebrochen wird, kann Teiltext des Assistenten weiterhin in der UI angezeigt werden.
• Der Gateway persistiert abgebrochenen Teiltext des Assistenten im Transkriptverlauf, wenn gepufferte Ausgabe vorhanden ist.
• Persistierte Einträge enthalten Abbruchmetadaten, damit Transkriptkonsumenten Abbruch-Teilinhalte von normaler Abschlussausgabe unterscheiden können.

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

allowInsecureAuth ist nur ein lokaler Kompatibilitäts-Toggle:

• Er erlaubt localhost-Control-UI-Sitzungen, in nicht sicheren HTTP-Kontexten ohne Geräteidentität fortzufahren.
• Er umgeht keine Pairing-Prüfungen.
• Er lockert keine Anforderungen an die Geräteidentität für entfernte (nicht-localhost) Verbindungen.

• Erfolgreiche Trusted-Proxy-Authentifizierung kann Operator-Control-UI-Sitzungen ohne Geräteidentität zulassen.
• Dies erstreckt sich nicht auf Control-UI-Sitzungen mit Node-Rolle.
• Same-Host-local loopback-Reverse-Proxys erfüllen Trusted-Proxy-Authentifizierung weiterhin nicht; siehe Trusted-Proxy-Authentifizierung.

• gatewayUrl wird nach dem Laden in localStorage gespeichert und aus der URL entfernt.
• Wenn Sie einen vollständigen ws://- oder wss://-Endpunkt über gatewayUrl übergeben, URL-codieren Sie den Wert von gatewayUrl, damit der Browser den Query-String korrekt parst.
• token sollte nach Möglichkeit über das URL-Fragment (#token=...) übergeben werden. Fragmente werden nicht an den Server gesendet, wodurch Lecks in Anfrageprotokollen und im Referer vermieden werden. Legacy-Query-Parameter ?token= werden aus Kompatibilitätsgründen weiterhin einmal importiert, aber nur als Fallback, und direkt nach dem Bootstrap entfernt.
• password wird nur im Arbeitsspeicher gehalten.
• Wenn gatewayUrl gesetzt ist, fällt die UI nicht auf Konfigurations- oder Umgebungs-Zugangsdaten zurück. Geben Sie token (oder password) explizit an. Fehlende explizite Zugangsdaten sind ein Fehler.
• Verwenden Sie wss://, wenn sich das Gateway hinter TLS befindet (Tailscale Serve, HTTPS-Proxy usw.).
• gatewayUrl wird nur in einem Top-Level-Fenster akzeptiert (nicht eingebettet), um Clickjacking zu verhindern.
• Öffentliche Control-UI-Bereitstellungen ohne Loopback müssen gateway.controlUi.allowedOrigins explizit setzen (vollständige Ursprünge). Private Same-Origin-LAN-/Tailnet-Ladevorgänge von Loopback-, RFC1918-/Link-Local-, .local-, .ts.net- oder Tailscale-CGNAT-Hosts werden akzeptiert, ohne den Host-Header-Fallback zu aktivieren.
• Der Gateway-Start kann lokale Ursprünge wie http://localhost:<port> und http://127.0.0.1:<port> aus dem effektiven Runtime-Bind und Port übernehmen, aber entfernte Browser-Ursprünge benötigen weiterhin explizite Einträge.
• Verwenden Sie gateway.controlUi.allowedOrigins: ["*"] nicht, außer für streng kontrollierte lokale Tests. Es bedeutet, jeden Browser-Ursprung zu erlauben, nicht „den Host abgleichen, den ich gerade verwende“.
• gateway.controlUi.dangerouslyAllowHostHeaderOriginFallback=true aktiviert den Host-Header-Ursprungs-Fallbackmodus, ist aber ein gefährlicher Sicherheitsmodus.