OpenClaw 2026.7.1: Plugin-Migration kann den Gateway blockieren

Ein gemeldeter Upgrade-Fehler rund um das Brave-Plugin kann OpenClaw in eine Gateway-Startschleife schicken. Brisant ist der Fall nicht wegen eines exotischen Setups, sondern weil selbst der naheliegende Standardweg in der dokumentierten Umgebung nicht half. Wer nach einem Plugin-Upgrade nur stumpf denselben Reparaturschritt wiederholt und neu startet, kann genau wieder in derselben Sackgasse landen.

Auslöser ist laut einem am 16. Juli 2026 eröffneten GitHub-Issue eine macOS-Installation, in der alte Plugin-Metadaten mit dem neuen gemeinsamen SQLite-Index kollidierten. Das ist kein Beleg für eine breite Regression. Als Fehlermuster ist der Fall aber trotzdem nützlich, gerade wenn nach einem Plugin-Upgrade plötzlich nur noch ein nicht bereites Gateway übrig bleibt.

Wo der Konflikt entsteht

Nach Angaben im GitHub-Issue lag das Brave-Plugin gleichzeitig in zwei Zuständen vor: einmal in der alten Datei ~/.openclaw/plugins/installs.json, einmal im neuen Index ~/.openclaw/state/openclaw.sqlite. Die Einträge unterschieden sich bei Version, Pfad und Integritätsangaben. Für die Migration ist das heikel, weil sie den neueren Datenbankeintrag nicht blind überschreiben soll, die Altlast den Start aber trotzdem blockieren kann.

Im gemeldeten Fall blieb genau diese Altdatei aktiv, obwohl der neue Index bereits verwendet wurde. Die Folge war kein sauberer Start mit Warnung, sondern ein Gateway, das nicht bereit wurde. Im Terminal tauchte eine abgebrochene Verbindung mit Code 1006 auf. Für Betreiber ist genau das der unangenehme Teil: Ein oberflächlicher Blick kann noch nach laufendem Dienst aussehen, obwohl der eigentliche Start schon festhängt.

Laut Fehlerbericht trat das auf einer Homebrew-Installation auf Apple Silicon auf. Genannt werden dort auch OpenClaw 2026.7.1 und Node 26.4.0. Ich würde daraus keine allgemeine Regel für jede Installation ableiten, als enger Diagnose-Rahmen taugen die Angaben aber.

Woran du den Fall erkennst

Ein einzelner Fehlertext reicht für diese Diagnose nicht. Das Issue beschreibt widersprüchliche Plugin-Metadaten zwischen altem Store und SQLite-Index; parallel zeigt die TUI eine abnormal geschlossene Gateway-Verbindung. Erst diese Kombination weist auf eine hängengebliebene Migration statt auf einen kaputten LaunchAgent, einen Portkonflikt oder eine allgemeine Konfigurationsstörung.

Prüfe vor einem manuellen Eingriff genau in dieser Reihenfolge: Taucht dieselbe Erweiterung in beiden Speichern auf? Unterscheiden sich Version oder Pfad? Kommt der Fehler direkt nach einem Plugin-Upgrade? Bleibt die Lage nach dem üblichen Reparaturversuch unverändert? Treffen mehrere Punkte zu, passt der Konflikt aus dem Issue. Andernfalls führt diese Reparatur sehr wahrscheinlich in die falsche Richtung.

Das markiert auch die Grenze des Berichts. Bisher geht es um eine gemeldete Umgebung, nicht um eine bestätigte breite Regression. Wer keine alte installs.json mehr hat oder dort keinen widersprüchlichen Eintrag findet, sollte die beschriebene Dateibewegung nicht auf Verdacht nachbauen. Sonst tauscht man einen Startfehler schnell gegen einen zweiten, selbst erzeugten Zustand.

Der dokumentierte Recovery-Pfad

Im gemeldeten Fall wurde der Gateway zunächst gestoppt und auf macOS der zugehörige LaunchAgent entladen. Danach sicherte der Betreiber die alte installs.json und verschob sie auf einen Namen mit der Endung .migrated. Erst dann lief die Migration beim nächsten Start sauber durch; laut Issue meldete der dort ausgeführte Statusbefehl den Dienst wieder als laufend und den Probe-Check als erfolgreich.

Wichtig ist hier nicht das Umbenennen an sich, sondern die Reihenfolge. Erst sichern, dann aus dem aktiven Pfad nehmen. Löschen wäre die schlechtere Wahl, weil damit die wichtigste Spur für Rückweg und Analyse verschwindet. Das Verschieben hält den alten Zustand fest, ohne dass OpenClaw die Datei weiter als aktiven Migrations-Store behandelt.

Der Betriebsnutzen liegt im Prüfpfad nach dem Upgrade. Ein laufender Prozess bedeutet noch keinen bereiten Gateway. Prüfe zusätzlich die Readiness und ob Alt- und Neuspeicher dieselbe Erweiterung unterschiedlich kennen. Diese Differenz trennt hier ein gewöhnliches Startproblem von einer blockierten Migration. Bei automatisierten Upgrades gehört der Check vor den nächsten geplanten Agentenlauf; sonst fällt der Stillstand womöglich erst durch eine ausgebliebene Nachricht auf.

Was heute hängen bleiben sollte

Der Bericht beschreibt einen Einzelfall und nennt noch keinen veröffentlichten Fix. Als Arbeitsregel taugt er trotzdem: Wenn OpenClaw direkt nach einem Plugin-Upgrade in einen Gateway-Fehler läuft, prüfe zuerst auf widersprüchliche Einträge zwischen installs.json und SQLite-Index. Wenn der übliche Reparaturweg nichts ändert, ist das kein Grund für Entwarnung, sondern ein Hinweis auf eine festhängende Migration. Sichere den Ausgangszustand, ändere nichts auf Verdacht und nimm die alte Datei nur dann aus dem aktiven Pfad, wenn Fehlermeldung, Dateibestand und Konfliktbild wirklich zusammenpassen.