OpenClaws Write-Tool und das Datenverlust-Risiko geteilter Memory-Dateien

Am 8. März 2026 verlor ein OpenClaw-Betreiber innerhalb von acht Stunden dreimal große Teile einer gemeinsam genutzten Memory-Datei. Mehr als zehn isolierte Cronjobs schrieben im Abstand von 30 Minuten bis drei Stunden in denselben Workspace. Der Effekt war immer gleich: Nach jedem Lauf blieben nur noch rund 20 Zeilen Cron-Ausgabe übrig, der Rest war weg.

Issue #40001 im offiziellen OpenClaw-Repository dokumentiert diesen Vorfall, seit dem 16. Juni als P1 und mit impact:data-loss markiert. Relevant ist das für jeden, der unabhängige Agentenläufe auf dieselbe Datei schreiben lässt.

Expected vs. Actual

Die Erwartung ist simpel: Ein Cronjob ergänzt memory/YYYY-MM-DD.md, vorhandene Einträge bleiben erhalten. Beobachtet wurde etwas anderes. Das write-Tool ersetzte den vollständigen Dateiinhalt durch die neue Ausgabe.

Der Grund liegt in der Schreiboperation selbst. Das Tool arbeitete ohne sichere Append-Semantik, während der Memory-Workflow Ergänzungen am Dateiende voraussetzte – ein Agent musste deshalb den bisherigen Inhalt lesen, den neuen Abschnitt anhängen und alles zusammen zurückschreiben. Fällt ein Schritt aus oder schreibt gleichzeitig eine zweite Session, geht die ältere Fassung verloren.

Für isolierte Cron-Sessions ist genau das riskant. Sie koordinieren ihre Dateizugriffe nicht automatisch mit der Hauptsitzung oder untereinander. Aus einem vermeintlich einfachen Append wird so ein Read-Modify-Write-Ablauf mit Race-Condition.

Was im Betrieb sichtbar wird

Der Vorfall hinterließ ein klares Symptom: Die Datei schrumpfte auf die Länge des zuletzt geschriebenen Blocks. Ein weiterer Bericht vom 18. Mai beschreibt dasselbe Muster bei einem Aufruf mit append: true – mehrere vorhandene Dateien, darunter MEMORY.md, wurden auf die Größe des neuen Inhalts verkürzt.

Wer den Fehler sucht, sollte zuerst Dateigröße, Änderungszeit und Diff prüfen. Passt der verbleibende Inhalt exakt zu einer einzelnen Cron-Ausgabe, spricht das für eine vollständige Überschreibung. Cron-Logs helfen danach, den schreibenden Lauf und mögliche zeitgleiche Zugriffe zu identifizieren.

Im selben Issue-Thread ist die Fehlerklasse zusätzlich für OpenClaw-Version 2026.4.9 in einem Monitor-und-React-Cron dokumentiert. Für die spätere Stable-Version v2026.7.1-2 und die Beta v2026.8.1-beta.2 liegt kein eigener Reproduktionstest vor. Der ältere Befund zeigt deshalb nur den ursprünglichen Fehler – ob er in diesen Fassungen fortbesteht oder behoben ist, bleibt offen.

Warum Prompt-Guards nicht reichen

Härtere Prompts können einen Agenten anweisen, vor dem Schreiben zu lesen und den vollständigen Inhalt zu erhalten. Im dokumentierten Betrieb wurden solche Regeln trotzdem umgangen. Und sie lösen kein zweites Problem: zwei Sessions, die denselben Ausgangsstand lesen und anschließend unterschiedliche Fassungen zurückschreiben.

Die Grenze ist technisch, nicht organisatorisch. Solange mehrere unabhängige Läufe denselben Pfad ohne atomisches Append oder Locking verändern, hängt die Dateisicherheit von korrektem Modellverhalten und perfektem Timing ab. Für dauerhafte Memory-Dateien ist das zu wenig.

Sofortmaßnahmen für geteilte Workspaces

Die robusteste Übergangslösung: getrennte Ausgabepfade pro Cronjob. Jeder Lauf schreibt dann zunächst nur in seinen eigenen Bereich, ein kontrollierter Prozess führt die Dateien später zusammen.

Zusätzlich sollten Betreiber sensible Memory-Dateien versionieren oder in kurzen Abständen sichern. Vor und nach automatisierten Läufen lohnt ein Größen- oder Diff-Check, denn ungewöhnliche Verkürzungen müssen den Workflow sofort stoppen. Wo gemeinsame Schreibzugriffe unvermeidbar sind, braucht es einen einzigen Writer, File-Locking oder eine andere Form expliziter Koordination.

Backups begrenzen den Schaden, verhindern die Überschreibung aber nicht. Für die Wiederherstellung sollte deshalb feststehen, welche Kopie maßgeblich ist und wie nach einem Alarm weitere Schreibjobs angehalten werden.

Die Betriebsregel

Geteilte Tages- und Memory-Dateien sollten nur dann als append-sicher gelten, wenn die eingesetzte OpenClaw-Version und der konkrete Workflow das in einem Konkurrenztest bewiesen haben: zwei isolierte Läufe schreiben nahezu gleichzeitig, anschließend werden Vollständigkeit, Reihenfolge und Dateigröße geprüft.

Bis dieser Test besteht, gilt eine einfache Regel: ein Pfad pro Writer. So bleibt ein fehlerhafter Lauf lokal begrenzt – und aus einer einzelnen Cron-Ausgabe wird kein Ersatz für das Gedächtnis des gesamten Systems.