OpenClaw 2026.7.1-2 korrigiert Codex-, Memory- und Plugin-Fehler

OpenClaw hat am 4. August 2026 zwei Korrektur-Releases veröffentlicht: 2026.7.1-1 behebt vorzeitig endende Codex-Turns, Startkonflikte im Memory Core und Upgrade-Probleme. 2026.7.1-2 korrigiert zusätzlich den Update-Pfad verwalteter npm-Plugins.

Für den Betrieb sind das keine kosmetischen Änderungen. Betroffen sind drei Übergänge, an denen Automationen gern halb fertig liegen bleiben: die Fortsetzung nach einer Fortschrittsmeldung, der Neustart mit vorhandenem Memory-Zustand und die Aktualisierung offiziell verwalteter Plugins.

Codex-Turns dürfen nicht an der Fortschrittsmeldung enden

Das Korrektur-Release 2026.7.1-1 hält App-Server-Turns weiter am Laufen, nachdem eine Codex-Fortschrittsmeldung ausgeliefert wurde. Zuvor konnte diese Zustellung den Turn beenden, bevor GPT oder Codex die eigentliche Abschlussantwort erreicht hatte.

Das Fehlerbild ist unangenehm plausibel: Die Oberfläche zeigt Aktivität, doch eine Dateiänderung, ein Test oder die Ergebnisantwort fehlt. Wer nur auf die sichtbare Statusmeldung schaut, kann einen unvollständigen Lauf für erfolgreich halten.

Der passende Funktionstest ist simpel: Eine längere Codex-Aufgabe muss mindestens eine Zwischenmeldung senden, danach weiterarbeiten und genau einmal mit dem endgültigen Ergebnis enden. Erst dieser Ablauf belegt, dass Fortschritt und Abschluss wieder getrennte Ereignisse sind.

Der Memory Core trennt reparierbare Daten von Strukturschäden

OpenClaw behebt Konflikte zwischen einem abgeleiteten Legacy-Index und einem Cache-Sidecar beim Start des Memory Core. Solche Begleitdaten sollen das Gateway nicht länger in einer fatalen Neustartschleife festhalten. Mögliche Strukturschäden am Vector Store bleiben dagegen ein eigener Fehlerfall.

Diese Trennung ist vernünftig: Indizes und Cache-Daten lassen sich rekonstruieren, beim eigentlichen Vektorspeicher wäre automatisches Aufräumen riskant. OpenClaw behandelt wiederherstellbaren Zustand damit anders als ein mögliches Datenproblem.

Geprüfte Rückstände früherer Migrationen sollen außerdem ansonsten gesunde Upgrades nicht mehr blockieren. Beim Neustart direkt nach dem Update zählt deshalb die konkrete Diagnose: Startet das Gateway nach der Bereinigung, oder meldet es weiterhin einen Strukturfehler, der untersucht werden muss? Für die systematische Einordnung solcher Befunde hilft der Praxisleitfaden zur Diagnose und ihren Grenzen.

WSL akzeptiert schreibgeschützte Pfade nur mit privaten Rechten

Unter WSL toleriert OpenClaw einen EROFS-Fehler bei geschützten chmod-Operationen nur, wenn der bestehende State-Pfad bereits private Zugriffsrechte besitzt. Kann ein schreibgeschütztes Dateisystem die Rechte nicht ändern, prüft OpenClaw also den vorhandenen Schutz.

Die Bedingung „bereits privat“ bildet die Sicherheitsgrenze. Bei zu offenen Rechten bleibt der Start blockiert. Eine WSL-Installation auf einem schreibgeschützten Mount darf nur weiterlaufen, wenn das State-Verzeichnis schon ausreichend abgeschirmt ist.

Verwaltete Plugins brauchen einen separaten Update-Test

2026.7.1-1 bereinigt veraltete npm-Lock-Metadaten, die Aktualisierungen offiziell verwalteter Plugins verhindern konnten. 2026.7.1-2 behandelt zusätzlich eine Metadatenvariante neuerer npm-Clients, bei der der betreffende Wert als Array mit einem Eintrag vorliegt.

Beide Fehler treffen denselben betrieblichen Moment: OpenClaw verwaltet das Plugin bereits, scheitert beim Update aber an einer Formatvariante des Paketwerkzeugs. Dass dafür am selben Tag ein zweites Release folgte, macht den Plugin-Pfad zum wichtigsten Kandidaten für einen gezielten Nachtest. Ich würde diesen Nachtest nicht als optionale Plugin-Pflege behandeln, sondern als Teil des Upgrades.

Eine erfolgreiche Aktualisierung des Kernsystems reicht daher nicht. Mindestens ein tatsächlich verwaltetes offizielles Plugin sollte den vollständigen Update-Pfad durchlaufen. Nur so lässt sich erkennen, ob Kernsystem und Erweiterung gemeinsam aktualisierbar sind. Warum dieser Pfad eine eigene Prüfung verdient, zeigt auch der frühere Fall einer Plugin-Migration mit Gateway-Startschleife.

Die Mindestregel für dieses Upgrade lautet: das zweite Korrektur-Release einspielen und anschließend drei Pfade prüfen — einen Codex-Turn bis zur Abschlussantwort, den Gateway-Start mit vorhandenem Memory-Zustand und das Update eines verwalteten npm-Plugins. Wer nur die Versionsausgabe kontrolliert, übersieht genau die Übergänge, die diese Releases reparieren sollen.