OpenClaw-Sitzungsindex: Wenn Cron-Transkripte unsichtbar werden

Der Index kann Transkripte übersehen

458 von 971 JSONL-Dateien lagen in einer vermessenen OpenClaw-Hauptinstanz auf dem Datenträger, ohne dass der Sitzungsindex sie noch referenziert hätte. Das entspricht 47,2 Prozent. Der Fehlerbericht vom 15. August 2026 beschreibt damit keine kosmetische Abweichung: Kosten-Reports, History-Abfragen und Cleanup-Jobs können ein unvollständiges Bild liefern, obwohl die Transkripte weiterhin gespeichert sind.

Besonders heikel ist das in Installationen mit vielen Cron-Läufen. Wer dort Monatskosten ausschließlich aus dem Index aggregiert, erhält womöglich eine plausible Zahl – nur eben nicht die vollständige.

Ein Slot pro Key, letzter Schreiber gewinnt

Die Mechanik ist unspektakulär und gerade deshalb tückisch: Der Sitzungsindex hält pro stabilem Session-Key nur den neuesten Lauf. Feuert ein Cronjob erneut, verbindet sich ein Dashboard neu oder rotiert ein datumsgebundener Key, ersetzt der neue Zeiger den vorherigen Eintrag, während dessen JSONL-Transkript auf dem Datenträger liegen bleibt.

Kein Crash. Keine Warnung.

Nach Angaben des Berichts tritt der Effekt bei wiederkehrenden Cron-Läufen, Dashboard-Reconnects und datumsrotierten Keys auf. Gemeinsam ist diesen Fällen das Missverhältnis zwischen Expected und Actual: Erwartet wird ein auffindbarer Eintrag je gespeichertem Transkript; tatsächlich kann nur der letzte Zeiger eines Keys im Index verbleiben.

Der Bericht vermisst eine konkrete Hauptinstanz. Daraus folgt weder eine allgemeine Orphan-Rate für jede Umgebung noch der Nachweis, dass jede aktuelle OpenClaw-Version identisch betroffen ist. Der belastbare Befund ist enger: Ein vorhandenes Transkript kann außerhalb des Sitzungsindexes liegen.

Folgen für Kosten- und Cleanup-Werkzeuge

In derselben Instanz entfielen laut Messung im Fehlerbericht rund 38,6 Prozent des erfassten Monats-Spends auf nicht indexierte Dateien. Fast vier von zehn ausgegebenen Dollar waren damit für eine rein indexbasierte Auswertung unsichtbar.

Das Gefährliche daran ist die Ruhe. Ein Kosten-Dashboard muss keinen Fehler melden, sondern zeigt lediglich eine glaubwürdige, zu niedrige Summe. Cleanup-Routinen können umgekehrt den tatsächlichen Speicherbestand unterschätzen, und History-Suchen finden Sitzungen nicht, obwohl deren Inhalt noch vollständig vorhanden ist.

Prüfen, ohne Belege zu vernichten

Für eine Bestandsaufnahme müssen Betreiber zwei Mengen getrennt erfassen: die vom Sitzungsindex referenzierten Einträge und die tatsächlich vorhandenen JSONL-Transkripte. Anschließend werden die Kennungen beider Mengen verglichen; nicht referenzierte Dateien sind zunächst Prüfobjekte, keine Löschkandidaten.

Ein sinnvoller Diagnoseablauf besteht aus drei Schritten: zuerst den Index und den Dateibestand zum selben Zeitpunkt erfassen, dann einige nicht zugeordnete Transkripte auf Zeitstempel, Session-Key und enthaltene Nutzung prüfen und schließlich kontrollieren, ob deren Kosten oder Verlauf in der indexbasierten Ansicht fehlen. Erst diese Stichprobe zeigt, ob die Lücke in der eigenen Umgebung praktisch relevant ist.

Vor einer Reparatur oder Bereinigung gehört der Bestand gesichert. Nicht indexiert bedeutet nicht wertlos: Die Dateien können die einzige Grundlage für Kostenrekonstruktion, Incident-Analyse oder eine spätere Wiederherstellung sein.

Die betriebliche Mindestregel

Indexbasierte Auswertung und Speicherinventar bleiben getrennte Wahrheiten, bis ihre Vollständigkeit für die eigene Installation geprüft ist. Der Sitzungsindex beantwortet, was referenziert wird. Der Datenträger beantwortet, was noch existiert.

Für cron-intensive Umgebungen folgt daraus eine klare Grenze: Kosten, Aufbewahrung und Löschung dürfen nicht allein am Index hängen. Wer beide Bestände regelmäßig vergleicht und Abweichungen vor dem Cleanup sichert, verhindert, dass ein unauffälliger Zeigerverlust zur falschen Kostenrechnung oder zum Verlust wichtiger Betriebsdaten wird.