OpenClaw 2026.6.9: Die Control UI wird zur Operator-Oberfläche

Laut den Release Notes vom 21. Juni bekommt die Control UI mit OpenClaw 2026.6.9 eine Session-Workspace-Rail und eine Anzeige für den Plugin-Zustand im Status. Dazu kommt eine kompaktere Cron-Liste. Die Browseroberfläche rückt damit näher an eine Operator-Konsole.

Der praktische Test ist einfach. Eine Session reagiert plötzlich merkwürdig. Liegt es am Arbeitskontext, an einem Plugin oder an einer zeitgesteuerten Aufgabe? Wer das erst mit mehreren Terminal-Abfragen auseinandernehmen muss, hat ein mächtiges System, aber noch keinen kurzen Diagnoseweg.

Wer die lokale Basis noch nicht kennt, findet den Einstieg im Installationsguide zu Gateway und Dashboard.

Die UI hängt direkt am Gateway

Die Control UI ist laut OpenClaw-Dokumentation eine kleine Single-Page-App auf Basis von Vite und Lit, die das Gateway selbst ausliefert. Standardmäßig erreicht man sie unter Port 18789, und sie spricht über denselben Port per WebSocket mit dem Gateway. Sie ist also keine lose Zusatzansicht, sondern der Browserzugang zur laufenden Instanz.

Daraus folgen zwei Dinge für den Betrieb. Wer die Oberfläche aus der Ferne öffnet, arbeitet an der produktiven Instanz und sollte den Zugang entsprechend absichern. Außerdem lässt sich die Oberfläche laut Dokumentation über gateway.controlUi.enabled ohne Neustart abschalten: Die Dashboard-Seiten verschwinden dann, während Bots und bestehende Gateway-Verbindungen weiterlaufen.

Was sich am Diagnoseweg ändert

Die Neuerungen bringen drei Fragen näher zusammen. In welchem Kontext läuft die Session? Ist ein Cron-Job beteiligt? Hat ein Plugin ein Problem?

Der Plugin-Zustand wird dabei wichtiger. Laut denselben Release Notes lädt das Gateway extern installierte Channel-Plugins beim Start, und offizielle Provider-Pakete erscheinen als eigenständige npm-Releases. Je modularer eine Installation ist, desto weniger sagt die Information „Plugin installiert“ aus. Betreiber müssen sehen, ob eine Erweiterung sauber läuft oder ob der Fehler schon vor der Session liegt.

Wo die Oberfläche bei Störungen hilft

Die Control-UI-Dokumentation beschreibt einige Signale, die bei einer Störung Zeit sparen.

Subagenten-Zeilen zeigen ihren Status sichtbar an. Fehlgeschlagene Aufgaben tragen ein Warn-Badge, abgelaufene ein Uhr-Badge, und ein Tooltip erklärt den genauen Zustand. Ungelesene Fehler von Kind-Sessions bleiben laut Dokumentation beim übergeordneten Eintrag sichtbar, auch wenn dieser schon abgeschlossen ist oder weiterarbeitet. Die Warnung nennt die betroffene Kind-Session. Ein Operator sieht also schon am übergeordneten Lauf, dass weiter unten etwas schiefgegangen ist, und kann die Kind-Session direkt öffnen.

Auch Last wird sichtbar. Ist die Request-Queue des Gateways voll, meldet die Oberfläche „The server is busy. Please try again in a moment.“ Laut Dokumentation hilft dann kurz warten und die Aktion wiederholen, bevor man einen Plugin-Fehler vermutet.

So entsteht eine sinnvolle Reihenfolge:

1. Plugin-Status prüfen.
2. Die betroffene Session öffnen.
3. Fehlgeschlagene Kind-Aufgaben verfolgen.

Erst danach lohnt der Griff zu den Logs im Terminal.

Die Oberfläche ersetzt das Terminal nicht

Browser-Automation bleibt eine eigene Betriebsfläche mit eigenen Freigaben. Der Beitrag zum OpenClaw Browser Relay beschreibt das Zusammenspiel von Gateway, Browser und Freigaben. Eine übersichtliche Control UI vereinfacht diese Architektur nicht, macht ihre Zustände aber leichter ablesbar.

Release Notes und Dokumentation belegen Ansichten und Bedienwege, aber keinen vollständigen Recovery-Prozess. Ob ein Plugin nach einem Neustart wirklich wieder sauber läuft, muss man weiterhin an einem reproduzierbaren Fall prüfen.

Der Maßstab für die Control UI ist deshalb schlicht: Kommt ein Betreiber vom Symptom schneller zur Ursache? Zeigt sie Plugin-Zustand, Session-Kontext und fehlgeschlagene Teilaufgaben ohne Umweg, wird der laufende Betrieb handhabbarer. Stehen diese Informationen nur nebeneinander, bleibt sie eine wachsende Werkzeugwand.