OpenClaw 2026.9.4: Rollback mit klarer Grenze

Ein Rollback ist noch keine Zeitmaschine. OpenClaw 2026.9.4 kann laut den Release Notes vom 11. September 2026 nach bestimmten fehlgeschlagenen Updates das vorige Paket, die vorherige Konfiguration und den Dienst wiederherstellen. Sobald eine Datenbankmigration den Zustand verändert hat, endet diese Absicherung jedoch.

Diese Grenze gehört vor jedes Update-Fenster. Selbst eine technisch geglückte Rückkehr bleibt laut den Release Notes als fehlgeschlagenes Update mit Rollback-Ergebnis protokolliert. Der neue Mechanismus reduziert den manuellen Aufwand bei kompatiblen Fehlern, ersetzt aber keinen vollständigen Wiederherstellungspunkt. Wer beides verwechselt, merkt den Unterschied ausgerechnet dann, wenn die ältere Version den neuen Datenbestand nicht mehr lesen kann.

Was OpenClaw automatisch zurückholt

Nach Angaben der Release Notes behält der Updater während der Aktivierung das vorige Paket. Scheitert ein schema-neutrales Update und bestehen die Kompatibilitätsprüfungen, stellt OpenClaw das zurückgehaltene Paket, den Command-Shim, den Dienst und die Konfiguration vor der Aktivierung wieder her. Anschließend prüft der Updater den vorherigen Gateway erneut.

Das ist ein klar begrenzter Recovery-Pfad für den Installationszustand. Die OpenClaw-Dokumentation empfiehlt deshalb den verwalteten Update-Befehl: Er validiert das Ziel, führt erforderliche Doctor-Migrationen aus und prüft den aktivierten Gateway. Ein bloßer globaler Austausch über npm i -g behält das vorige Paket für diesen Ablauf nicht zurück.

Wo der Automatismus stoppt

Geänderte Datenbankschemata, eine inkompatible neue Datenbank oder Konfigurationsänderungen während des Vorgangs blockieren laut den Release Notes den automatischen Rollback. Der Mechanismus kann Code und die erfasste Konfiguration zurückbringen; einen vollständigen State-Checkpoint stellt er nicht her. Paketwechsel drehen Datenbankmigrationen daher nicht zurück.

An dieser Grenze entsteht das Betriebsrisiko. Hat sich der Zustand über das von der älteren Version unterstützte Format hinaus entwickelt, nennt die OpenClaw-Dokumentation als unterstützten Recovery-Weg ein verifiziertes Backup von vor dem Update zusammen mit dem dazu passenden Release. Die Release Notes schreiben ein solches Backup für Upgrades mit Migrationen ausdrücklich vor.

Der automatische Rückweg ist damit stark, solange dieselben Daten von beiden Versionen sicher gelesen werden können. Ob diese Voraussetzung gilt, darf kein Bauchgefühl entscheiden. Schon eine zwischenzeitliche Änderung an der Konfiguration reicht aus, um den vorgesehenen Automatismus zu sperren.

Der sichere Ablauf vor dem Versionswechsel

Die OpenClaw-Dokumentation gibt für einen verwalteten Wechsel auf eine bekannte funktionierende Version zunächst einen Probelauf vor:

openclaw update --tag <known-good-version> --dry-run
openclaw update --tag <known-good-version>

Der Dry Run prüft den geplanten Zielwechsel, bevor der zweite Aufruf ihn ausführt. Das hilft bei der Paket- und Kompatibilitätsseite. Es beantwortet allein jedoch nicht, ob ein vorhandenes Backup vollständig ist und sich tatsächlich zurückspielen lässt.

Für das Plattformteam folgt daraus eine einfache Mindestregel: Vor jedem Update mit möglicher Migration braucht es ein verifiziertes Vor-Update-Backup samt passender OpenClaw-Version. Der automatische Rollback ist danach eine zusätzliche Schutzschicht für schema-neutrale Fehler — und kein Ersatz für getestete Wiederherstellung.