OpenClaw meldet frische Heartbeat-Sessions, führt aber alte Transkripte weiter

OpenClaw hat ein Heartbeat-Problem, das im Alltag leicht übersehen wird und genau deshalb teuer werden kann. Laut GitHub-Issue #65564 erzeugt die Runtime mit aktivierter isolierter Session zwar pro Lauf eine neue Session-ID, schreibt aber weiter in dasselbe Transcript. Für Betreiber ist das die unangenehme Variante eines Session-Bugs: Die Oberfläche sieht sauber aus, der Verlauf offenbar nicht.

Für den Betriebsrahmen passt dazu unser Guide zu Cron-Jobs, Heartbeats und Automationen in OpenClaw, weil dort die Trennung zwischen geplanten Läufen, Heartbeat-Takt und Session-Modus sauberer aufgedröselt ist.

Neue Session, alter Ballast

Der Fehler wurde laut Issue am 12. April 2026 gegen OpenClaw 2026.4.11 unter Debian 12 gemeldet. Das Repro ist kurz und damit im besten Sinn brauchbar: Ein dedizierter Heartbeat-Agent läuft mit isolatedSession: true und lightContext: true, wird zweimal gestartet, danach werden Session-Store und Transcript-Datei geprüft.

Nach Angaben des Reports wechselt die Session-ID dabei von 31ec7166-6c8c-4730-b136-e5a4110fc3a8 auf 6e1f19ae-991f-4053-b8a2-a7c8a0864a9a. Gleichzeitig wächst dieselbe Transcript-Datei von 177126 auf 178358 Byte. Sichtbar beginnt also ein neuer Lauf, praktisch hängt aber alter Verlauf weiter dran.

Genau dort wird isolatedSession zum Risiko. Im Betrieb zählt nicht, ob eine frische Kennung auftaucht, sondern ob der gespeicherte Kontext wirklich neu startet. Wenn die Runtime nur die Session-ID rotiert, die Historie aber mitschleppt, trennt sie Sessions nicht sauber, sondern kaschiert den Zustand nur besser.

Warum das ausgerechnet Heartbeats trifft

Heartbeats sollen klein, billig und zustandsarm bleiben. Sie prüfen, ob ein System noch sauber läuft, und sollten dabei möglichst wenig eigenen Verlauf aufbauen. Laut dem GitHub-Issue kippt genau dieser Vertrag: Der Heartbeat startet formal neu, nimmt aber offenbar Altlasten in den nächsten Lauf mit.

Der eigentliche Schaden zeigt sich nicht erst beim Crash, sondern schon vorher in den Zahlen. Im Report steigen die Eingabetoken eines frühen Turns über mehrere Läufe hinweg von 12314 auf 13753 und dann auf 17190. Das ist die operative Warnlampe. Wenn ein Heartbeat bei jedem Lauf etwas alten Verlauf mitschleppt, wachsen Kontext, Kosten und potenzielle Diagnosefehler gleichzeitig.

Für AgentOps ist das heikel, weil eine neue Session-ID dann kein verlässlicher Prüfpunkt mehr ist. Wer nur auf frische IDs schaut, kann annehmen, dass die Isolation greift. Wer zusätzlich Transcript-Größe und frühe Tokenzahlen beobachtet, sieht eher, ob die Runtime wirklich neu startet oder nur so tut.

Ein einzelner Report, aber ein klares Betriebssignal

Die Quelle bleibt eng an einer konkreten Umgebung: OpenClaw 2026.4.11, Debian 12, global per npm installiert, mit gemini-3.1-flash-lite und Routing über google/gemini-3.1-flash-lite-preview. Laut Issue fehlt damit ein breiter Vergleich über mehrere Plattformen. Für eine Betriebswarnung reicht der Fall trotzdem, weil Reproduktion, erwartetes Verhalten und beobachtete Abweichung klar nebeneinanderstehen.

Auch die Einordnung im Issue selbst spricht eher für einen ernst zu nehmenden Fehler als für einen vagen Randfall. Das Ticket ist laut GitHub unter anderem mit bug, impact:session-state und issue-rating: diamond lobster markiert und als P2 eingeordnet. Das ist noch kein Fix und keine Entwarnung, aber genug, um den Fall nicht als kosmetischen Nebeneffekt abzutun.

Wichtig ist auch, was die Quelle gerade nicht hergibt. Der Report beschreibt keinen Absturz und keine blockierte Ausführung. Das Problem gehört in die unangenehmere Klasse von State-Fehlern: Das System läuft weiter, aber die Zustandsgrenzen verwischen. Gerade bei Heartbeats fällt so etwas oft später auf als ein harter Crash.

Was du jetzt prüfen solltest

Aus dem Issue lässt sich vor allem eine einfache Betriebsregel ableiten: Session-Isolation darf nicht über die Kennung allein bewertet werden. Entscheidend ist, ob Transcript und früher Modellkontext pro Lauf tatsächlich neu anfangen. Wenn einer dieser Teile kleben bleibt, stimmt das Betriebsbild nicht mehr.

Für bestehende OpenClaw-Setups heißt das: Heartbeats nicht nur auf erfolgreiche Ausführung prüfen, sondern zusätzlich auf Transcript-Wachstum und auffällige Steigerungen der frühen Eingabetoken. Genau diese Kombination macht den beschriebenen Fehler sichtbar. Eine neue Session-ID ohne frischen Verlauf ist im Zweifel weniger wert als ein stabil kleiner Anfangsturn.

Einen bestätigten Fix oder eine Release-Notiz, die das Verhalten laut Quelle bereits auflöst, gibt es im belegten Stand noch nicht. Bis dahin ist der Fall keine erledigte Bug-Notiz, sondern eine laufende Betriebswarnung.

Die praktische Konsequenz ist klar: Bei Heartbeat-Agenten ist das Transcript derzeit der verlässlichere Prüfpunkt als die sichtbare Session-ID. Wer diese Abweichung früh erkennt, sucht später nicht erst am Modell oder am Prompt, obwohl das eigentliche Problem im Session-State der Runtime steckt.