OpenClaw-Heartbeat kann Transkriptlimit umgehen und Gateway stoppen

312 Megabyte statt der konfigurierten 20 Megabyte: Eine Heartbeat-getriebene OpenClaw-Sitzung ist laut GitHub-Issue #136452 auf 11.705 aktive Ereignisse angewachsen. Danach beendete ein V8::FatalProcessOutOfMemory den Gateway mit SIGABRT. Der laut Issue als P0 eingestufte Fehler betrifft die Versionen OpenClaw 2026.8.1 und 2026.8.2.

Das Limit versagt. Betroffen ist ein besonders tückischer Betriebsfall: dauerhaft laufende Agenten, deren Hauptsitzung vor allem durch Heartbeats weitergeführt wird.

Der Grenzwert liegt hinter dem frühen Rücksprung

Laut der technischen Analyse in Issue #136452 kehrt runSessionCompactionIfNeeded bei Heartbeat-Läufen zurück, bevor resolveMaxActiveTranscriptBytes den konfigurierten Byte-Grenzwert liest. Die Einstellung wird demnach korrekt ausgewertet, nur erreicht dieser Ausführungspfad sie nicht.

Im dokumentierten Fall schrieb jeder Heartbeat außerdem einen Kontextblock von ungefähr 300 bis 400 Kilobyte zurück ins Transkript, wodurch älterer Kontext erneut im Verlauf landet und das Wachstum massiv verstärkt. Aus einer übersprungenen Prüfung entsteht so ein selbstbeschleunigender Speicherverbrauch.

Der Codex-Neustart schützt nur eine Ebene

Der Codex-Tokenwächter reagierte nach Angaben des Reporters durchaus, erkannte sein aktives Tokenlimit und startete einen frischen Codex-Thread. Das OpenClaw-Sitzungstranskript blieb davon jedoch unberührt und wuchs weiter.

Das überrascht. Ein sichtbarer Thread-Neustart kann wie eine erfolgreiche Entlastung wirken, obwohl der speicherrelevante Verlauf im Host bestehen bleibt. Im Betrieb reicht es deshalb nicht, allein auf zurückgesetzte Modell-Threads zu achten. Die Größe der OpenClaw-Sitzung und die Stabilität des Gateway bleiben die maßgeblichen Signale.

Isolation begrenzt den bekannten Fehlerpfad

Als vorläufige Gegenmaßnahme nennt Issue #136452 die Kombination aus isolatedSession: true und lightContext: true für den Heartbeat. Beim Reporter stoppte sie das Wachstum, weil die Heartbeats nicht mehr den fortlaufenden Hauptverlauf aufblähten.

Das ist ein belastbarer Hinweis, aber keine allgemeine Garantie für jede Umgebung. Bis ein Fix veröffentlicht und im realen Lauf nachgewiesen ist, sollten Betreiber der betroffenen Versionen Heartbeats auf nicht isolierten Hauptsitzungen als Verfügbarkeitsrisiko behandeln und den beschriebenen Isolationsweg prüfen.

Der Reparatur-PR bleibt vor dem Merge blockiert

PR #136533 soll laut seinem Review den bestehenden Byte-Grenzwert auch bei Heartbeat-Läufen durchsetzen. Zusätzlich sieht die Änderung eine Synchronisierung zwischen Host und Codex nach einer Kompaktierung durch die Context Engine vor.

Freigegeben ist der Patch noch nicht. Der Review vom 3. September nennt acht offene Punkte und verlangt einen realen Verhaltensnachweis vor dem Merge, insbesondere für den erweiterten Codex-Pfad. Als Runtime-Fix ist der Ansatz plausibel, doch als Entwarnung reicht ein offener PR nicht: Produktive Gateways brauchen bis zur verifizierten Veröffentlichung eine eigene Begrenzung dieses Fehlerpfads.