OpenClaw vergisst nach Neustart oder Update alles? Das ist meist kein Modellproblem, sondern State-Persistence
Die Beschwerde ist gerade überall: „mein OpenClaw hat alles vergessen“
Genau dieser Satz taucht im Moment ständig auf, in X-Posts, Foren und Operator-Chats: Gestern lief OpenClaw noch sauber, dann kam ein Neustart, ein Docker-Rebuild oder ein Update, und plötzlich wirkt der Agent wie ausgewechselt.
Die Symptome klingen immer ähnlich:
Der erste Reflex ist dann oft: Das Modell ist schuld. Claude sei schlechter geworden, das lokale Modell sei dümmer, der Prompt sei kaputt.
Ganz ehrlich, das ist meistens die falsche erste Diagnose.
In echten OpenClaw-Setups ist „Vergessen“ nach einem Neustart meist ein Persistence-Problem, ein Datei-Ladeproblem, ein Missverständnis über Session-Grenzen oder klassische State Drift zwischen Host und Container. Das Modell ist oft nur der Überbringer der schlechten Nachricht.
Wenn du das als diffuses KI-Gedächtnisproblem behandelst, änderst du wochenlang Prompts und Provider, während der eigentliche Fehler unberührt bleibt.
---
Was OpenClaw wirklich speichert und was nicht
Viele Betreiber gehen stillschweigend davon aus, dass OpenClaw eine magische, universelle Erinnerung hat. Hat es nicht. Es gibt mehrere State-Ebenen, und jede davon überlebt anders.
In der Praxis helfen vier Kategorien:
1. Session-History
Das ist das kurzfristige Arbeitsgedächtnis einer laufenden Unterhaltung. Innerhalb eines aktiven Threads kann das stark wirken. Nach Restart, Kontextwechsel, neuer Session oder anderem Eingangsweg kann es aber schlicht verschwinden.
Wenn du darauf gebaut hast, dass rohe Session-History Entscheidungen von letzter Woche zuverlässig trägt, war das Setup schon vorher fragil.
2. Workspace-Memory-Dateien
Dateien wie <code>MEMORY.md</code>, <code>SOUL.md</code>, <code>USER.md</code> und tägliche Notizen sind grundsätzlich langlebig, aber nur dann, wenn die Runtime sie nach dem Neustart auch wirklich noch sieht.
Genau hier glauben viele Leute, alles korrekt konfiguriert zu haben, obwohl ihre Docker-Mounts etwas anderes sagen.
3. Externe Persistenz
Datenbanken, Vector Stores, Archive, Notizen, Tickets oder andere Systeme außerhalb der Live-Session. Diese Ebene überlebt Neustarts meist problemlos, aber nur wenn der Verbindungs- und Retrieval-Pfad weiterhin funktioniert.
4. Operativer Konfigurations-State
Umgebungsvariablen, Agent-Konfiguration, Modell-Routing, Allowlists, gemountete Pfade, Cron-Definitionen und Tool-Verfügbarkeit. Die Erinnerung kann technisch noch existieren, während diese Ebene sich so verändert hat, dass der Agent sie nicht mehr lädt oder benutzt.
Genau deshalb kann ein Agent amnestisch wirken, obwohl keine einzige Datei verloren gegangen ist.
---
Das häufigste Fehlermuster nach Restart oder Upgrade
Hier ist die langweilige Standardgeschichte.
1. Der Betreiber updated OpenClaw oder baut einen Container neu.
2. Der Service kommt wieder hoch.
3. Nachrichten gehen weiterhin durch.
4. Der Agent antwortet, aber mit deutlich weniger Kontinuität.
5. Der Betreiber schließt daraus: Memory ist kaputt.
Was tatsächlich passiert ist, ist oft eines davon:
Gerade der letzte Punkt ist brutal, weil er sich wie Regression anfühlt, in Wahrheit aber nur eine schwache Architektur sichtbar macht.
Wenn dein System nur dann klug wirkt, wenn eine einzige lange Session nie stirbt, dann hast du keine Persistenz, sondern bloß Akkumulation.
---
So diagnostizierst du das Problem ohne Ratespiel
Der sauberste Weg ist, zwei Fragen strikt zu trennen: „Existiert die Erinnerung noch?“ und „Wird diese Erinnerung noch geladen?“ Das sind verschiedene Dinge.
Schritt 1: Prüfe, ob die Dateien noch existieren
Starte nicht mit Theorie, sondern mit Realität.
Prüfe, ob die erwarteten Dateien physisch noch dort liegen, wo der laufende OpenClaw-Prozess sie erwartet:
Wenn du Docker nutzt, prüfe von innen im Container, nicht nur auf dem Host. Host-Wahrheit und Container-Wahrheit sind oft nicht dieselbe Wahrheit.
Schritt 2: Prüfe, ob die Runtime sie lesen kann
Eine vorhandene Datei reicht nicht. Berechtigungen, falsche Mount-Modi, fehlerhafte relative Pfade oder ein geändertes Working Directory können eine gültige Datei praktisch unsichtbar machen.
Gerade nach „kleinen Aufräumarbeiten“ an Compose-Dateien oder Deploy-Skripten passiert das ständig.
Schritt 3: Prüfe, ob der Startup-Flow noch den richtigen Kontext lädt
Viele Betreiber verlassen sich auf AGENTS-Regeln oder Startkonventionen wie das Laden von <code>SOUL.md</code>, <code>USER.md</code> und aktuellen Daily Notes. Nach einem Upgrade kann eine Pfadänderung oder ein anderer Agent-Scope dazu führen, dass der Assistant zwar sauber startet, aber aus einem anderen Workspace oder Session-Typ heraus.
Das Ergebnis ist dann nicht Totalausfall, sondern teilweiser Persönlichkeitsverlust, teilweiser Memory-Verlust und merkwürdige Inkonsistenz.
Schritt 4: Prüfe Retrieval, nicht nur statisches Memory
Wenn dein Setup von semantischer Suche, pgvector, einem Recall-Service oder einer anderen externen Memory-Schicht abhängt, teste das Retrieval direkt. Vieles, was wie Vergessen aussieht, ist einfach still scheiterndes Retrieval, ein Timeout oder verlorene Credentials.
Schritt 5: Vergleiche Vorher-Nachher-Verhalten mit einem festen Prompt
Stelle vor und nach dem Neustart exakt dieselbe konkrete Frage, zum Beispiel:
`Welche Branch-Namensregel verwenden wir?`
oder
`Was haben wir zu öffentlich exponierten Ports entschieden?`
Wenn die Antwort sichtbar schlechter wird, ist das Problem reproduzierbar. Das ist Gold wert, weil diffuses „fühlt sich dümmer an“ schwer zu fixen ist.
---
Warum Docker häufiger beteiligt ist, als viele zugeben wollen
Ich sehe ständig, dass Betreiber OpenClaw selbst die Schuld geben, obwohl in Wahrheit das Container-Lifecycle-Verhalten das Problem ist.
Ein paar Klassiker:
Neu erzeugte leere State-Verzeichnisse
Du dachtest, der State liege in einem dauerhaften Volume. In Wirklichkeit bootete der neue Container gegen einen leeren Pfad.
Workspace auf dem Host vorhanden, aber nicht dort gemountet, wo die App ihn erwartet
Die Dateien existieren auf der Platte, aber die Runtime schaut woanders hin.
Versteckter Berechtigungsfehler
Das Verzeichnis ist da, aber der Service-User im Container darf nicht lesen oder schreiben, was nötig wäre.
Ein Image-Update hat alte Annahmen enttarnt
Eine neue Image-Version, ein anderes Entrypoint oder ein geändertes Startup-Working-Directory kann schlampige Pfadannahmen sichtbar machen, die vorher nur zufällig funktioniert haben.
Genau deshalb bestehen gute Operatoren auf expliziten Mounts und stabilen Pfaden. Das ist keine Paranoia, sondern die Vermeidung von Fake-Amnesie.
---
State Drift ist der eigentliche Langzeitgegner
Es gibt noch eine zweite Variante dieses Problems. Sie sieht aus wie Restart-Verlust, ist aber eigentlich State Drift.
State Drift bedeutet, dass das live laufende System sich langsam von dem System entfernt, das du zu betreiben glaubst.
Beispiele:
Dann kommt der Neustart und entfernt den provisorischen Kleber, der alles noch zusammenhielt. Viele sagen dann: „Der Neustart hat es kaputtgemacht.“ Oft hat der Neustart das Problem nur sichtbar gemacht.
Das ist frustrierend, aber auch hilfreich. Versteckte Drift ist gefährlicher als sichtbarer Ausfall.
---
Der robuste Fix: auf Cold-Start-Kontinuität bauen
Das richtige Ziel ist nicht „die aktuelle Session unsterblich machen“. Das Ziel ist: „Der Agent soll nach einem kalten Neustart sauber wieder zu sich kommen.“
Das bedeutet:
Dauerhafte Wahrheit gehört in Dateien oder externe Systeme, nicht in Bauchgefühl
Wenn etwas morgen noch wichtig ist, muss es an einem langlebigen Ort stehen, den der Agent lesen oder durchsuchen soll.
Core Memory klein und absichtlich halten
Eine aufgeblähte <code>MEMORY.md</code> ist keine robuste Intelligenz. Meist ist sie nur ein teurer Haufen veralteter Kontextmasse.
Session-History als Cache behandeln, nicht als Quelle der Wahrheit
Nützlich, schnell, temporär. Aber nicht autoritativ.
Mounts und Pfade explizit machen
Verlass dich nicht auf glückliche relative Pfade oder auf „ich glaube, der Container sieht diesen Ordner schon“.
Restart-Verhalten bewusst testen
Ein System ist nicht produktionsreif, weil es einmal funktioniert. Es ist produktionsreif, wenn es nach Restart, Rebuild und Upgrade korrekt zurückkommt.
Upgrades langweilig machen
Konfiguration dokumentieren, Relevantes pinnen und mysteriösen Handbetrieb minimieren.
---
Praktische Operator-Checkliste
Wenn OpenClaw nach einem Neustart vergesslich wirkt, gehe diese Liste in genau dieser Reihenfolge durch:
1. Prüfe, ob der richtige Workspace gemountet ist.
2. Prüfe, ob die erwarteten Memory-Dateien noch existieren.
3. Prüfe, ob der laufende Prozess sie lesen kann.
4. Prüfe, ob die Startup-Regeln noch die richtigen Dateien laden.
5. Prüfe, ob externes Retrieval noch funktioniert.
6. Prüfe, ob nur Session-History verloren ging und du das mit dauerhafter Erinnerung verwechselt hast.
7. Prüfe, ob aktuelle Updates Pfade, Nutzer oder Env-Loading verändert haben.
8. Erst danach an Prompts drehen oder Modelle wechseln.
Diese Reihenfolge ist entscheidend. Sonst schreibst du Persönlichkeitsdateien um, obwohl in Wahrheit ein Volume-Bug vorliegt.
---
Fazit
Wenn OpenClaw „alles vergessen“ hat, lautet die wichtigste Frage nicht: „Zu welchem Modell soll ich wechseln?“
Sondern diese:
Welche State-Ebene hat aufgehört, korrekt zu überleben, zu laden oder abgerufen zu werden?
Diese Frage verwandelt eine diffuse KI-Beschwerde in ein Operator-Problem, das man tatsächlich lösen kann.
Und genau das ist die eigentliche Lektion: Verlässliche Agent-Systeme entstehen nicht dadurch, dass man hofft, ein perfektes Modell werde schon alles für immer behalten. Sie entstehen dadurch, dass man Session-Memory, dauerhafte Erinnerung, Retrieval und Infrastruktur-State sauber trennt, sodass ein Neustart Routine statt Trauma ist.
Genau diese Operator-Perspektive, inklusive Persistenz-Patterns, Docker-sicherem Setup, Memory-Struktur, Upgrades, Backups und Produktions-Checks, vermittelt das OpenClaw Setup Playbook.