OpenClaws Write-Tool bleibt ein Risiko für geteilte Memory-Dateien

OpenClaw hat weiter ein offenes Problem mit stillen Dateiüberschreibungen in geteilten Workspaces. Laut Issue #40001 im offiziellen Repository kann das write-Tool in isolierten Cron-Sessions gemeinsame Dateien wie memory/YYYY-MM-DD.md komplett ersetzen, statt neue Inhalte anzuhängen. Das Ticket ist am 16. Juni 2026 noch offen, als P1 markiert und zusätzlich mit impact:data-loss gelabelt.

Relevant ist das nicht wegen einer theoretischen Ecke, sondern wegen eines dokumentierten Produktionsvorfalls. In der ursprünglichen Beschreibung nennt der Reporter einen Betrieb mit mehr als zehn isolierten Cronjobs im Abstand von 30 Minuten bis drei Stunden. Laut Issue trat der Datenverlust am 8. März 2026 dort dreimal innerhalb von acht Stunden auf. Die betroffene Tagesdatei schrumpfte jeweils auf rund 20 Zeilen Cron-Ausgabe, während über Stunden angesammelter Inhalt verschwand.

Das Problem liegt im Primitive, nicht im Prompt

Laut Issue-Beschreibung hat das write-Tool keinen Append-Modus. Die Formulierung ist klar: Das Tool erstellt oder überschreibt eine Datei vollständig, hängt aber nichts sicher ans Ende an. Genau daraus entsteht der Bruch zwischen dem, was Nutzer bei einer täglichen Memory-Datei erwarten, und dem, was die Runtime tatsächlich absichert.

Ein RCA-Kommentar vom 8. März 2026 beschreibt das Problem als Kombination aus zwei Lücken: erstens einem zugrunde liegenden Schreib-Primitive ohne Append-Semantik, zweitens einer OpenClaw-Integration, die append-artige Memory-Workflows voraussetzt. Für isolierte Cron-Sessions wird das besonders heikel, weil sie laut diesem Kommentar nicht mit der Hauptsitzung koordinieren und ein Muster aus „lesen, anhängen, alles neu schreiben“ leicht übersprungen werden kann und zusätzlich Race-Conditions erzeugt.

Das ist mehr als eine unglückliche Tool-Bezeichnung. Im Issue heißt es ausdrücklich, dass Agenten den Befehl „in eine Datei schreiben“ regelmäßig als Anhängen verstehen, obwohl das konkrete Tool destruktiv arbeitet. Wenn die Runtime dann nur Overwrite anbietet, hängt Dateisicherheit am Modellgehorsam und an einer mehrstufigen Prompt-Choreografie. Für Shared-Memory-Dateien ist das ein fragiler Vertrag.

Die Kommentare sprechen gegen einen bloßen Einzelfall

Die Metadaten des Issues nennen elf Kommentare. Inhaltlich verdichten sie das Bild eher, als dass sie es relativieren. Ein Kommentar vom 9. März bestätigt den Produktionsvorfall des ursprünglichen Reporters noch einmal und nennt drei Stopgap-Maßnahmen: härtere Prompt-Guards, ein externes Backup im 15-Minuten-Takt und separate Ausgabedateien für Cronjobs. Die Kernaussage dort ist eindeutig: Der saubere Fix liegt auf Tool-Ebene, nicht in zusätzlichen Warnsätzen.

Ein weiterer Kommentar vom 12. März beschreibt das Verhalten als „real operational pain point“ und argumentiert, dass isolierte Cron-Sessions ohne Bewusstsein für konkurrierende Schreibzugriffe jede gemeinsam genutzte Workspace-Datei in eine tickende Zeitbombe verwandeln. Die praktische Konsequenz daraus ist nüchtern: Unabhängige Backups bleiben die einzige belastbare Verteidigungslinie, solange das Schreibverhalten unverändert ist.

Die Evidenz endet zudem nicht im März. Am 2. Mai bringt ein weiterer Nutzer frische Beobachtungen aus OpenClaw 2026.4.9 ein und beschreibt dieselbe Fehlerklasse in einem Monitor-und-React-Cron. Am 4. Mai folgt ein Kommentar, der eine bereits existierende Append-PR-Linie gegen origin/main nachgetestet haben will. Laut diesem Test picken die relevanten Commits sauber, git diff --check und lint:core liefen durch, und gezielte Tool-Tests bestanden ebenfalls. Die Diskussion dreht sich also nicht nur um Reproduktion, sondern längst auch um einen konkreten Reparaturpfad.

Warum das für OpenClaw-Setups sofort praktisch wird

Für Teams und Einzelbetreiber liegt der Schaden nicht nur im verlorenen Text. Laut Issue betrifft der Verlust operative Kontexte, Sitzungszusammenfassungen und Entscheidungsprotokolle. Gerade diese Dateien werden in Agenten-Setups oft als billige, robuste Persistenz behandelt. Wenn ausgerechnet dort eine isolierte Sub-Session denselben Pfad ohne Koordination neu schreibt, ist nicht nur ein Tageslog kaputt, sondern im Zweifel die handhabbare Erinnerung des Systems.

Die Kommentarkette erweitert das Risiko sogar über Cronjobs hinaus. Ein Bericht vom 18. Mai schildert eine Sitzung, in der write mit einem append: true-Argument mehrere bestehende Dateien trotzdem verkürzte, darunter MEMORY.md. Der Kommentar nennt konkrete Vorher-Nachher-Größen, bei denen die Nach-Datei exakt der Länge des neu geschriebenen Inhalts entsprach. Falls sich das generalisieren lässt, wäre das Problem nicht mehr nur ein Spezialfall isolierter Crons, sondern ein grundsätzlich missverständliches Schreibverhalten an einer zentralen Tool-Grenze.

Für die Praxis folgt daraus eine einfache Trennung. Prompt-Guards können helfen, sind laut Issue aber schon mehrfach umgangen worden. Backups helfen nur nachgelagert. Solange kein belastbares Append-Primitive existiert, sollten geteilte Tages- oder Memory-Dateien nicht als sicherer Sammelpunkt für unabhängige Agentenläufe gelten.

Welche Fix-Richtung im Thread am plausibelsten wirkt

Die Vorschläge im Issue laufen auf vier Richtungen hinaus: ein echtes append-Tool, eine deutlichere Benennung von write als Overwrite-Operation, Backups vor destruktiven Schreibvorgängen und Koordination über File-Locking oder Schutzregeln für sensible Workspace-Dateien. Von diesen Optionen wirkt im Thread vor allem ein eigenes Append-Primitive wie die strukturelle Antwort auf das Kernproblem.

Der Grund ist simpel. Wenn ein append-orientierter Workflow intern immer erst den Volltext lesen und danach die komplette Datei neu schreiben muss, bleibt derselbe Race-Zustand bestehen. Bessere Warnungen machen die Kante sichtbarer, entschärfen sie aber nicht. Dass das Issue Mitte Juni weiterhin offen ist, obwohl es P1-, Data-Loss- und Linked-PR-Labels trägt, zeigt vor allem eins: Die Lücke ist klar benannt, aber noch nicht dauerhaft aus der Runtime verschwunden.

Was du daraus heute ableiten solltest

Die operative Schlussfolgerung ist unbequem, aber direkt. Wer OpenClaw mit isolierten Cronjobs auf gemeinsame Memory-Dateien loslässt, sollte diese Dateien nicht als append-sicher behandeln. Laut dem aktuellen Stand des offiziellen Issues entsteht genau an dieser Annahme der Datenverlust.

Bis ein echter Fix in der Runtime landet, ist die vernünftigste Haltung defensiv: getrennte Ausgabepfade für unabhängige Läufe, engere Schutzregeln für sensible Dateien und Backups, die nicht nur theoretisch vorhanden sind. Das eigentliche Signal aus dem Thread ist nicht, dass ein Prompt schlecht verstanden wurde. Das Signal ist, dass ein zentrales Schreibwerkzeug in geteilten Agenten-Setups derzeit noch zu leicht in einen Datenverlustmodus kippt.