OpenClaw räumt Zombie-Runs nach Gateway-Restarts auf

OpenClaw arbeitet an einem Fix für einen unschönen Restart-Fall: Laut Pull Request #92712 können Sessions nach einem Gateway-Neustart mitten im Turn dauerhaft auf running stehen bleiben, obwohl keine Modellantwort mehr losläuft. Für Nutzer sieht das nach einer permanent busy blockierten Sitzung aus, die sich erst mit /new oder /reset wieder freischalten lässt.

Das ist kein exotischer Schönheitsfehler, sondern ein AgentOps-Problem. Wer einen Gateway-Prozess neu startet, rechnet mit einer sauberen Recovery oder wenigstens mit einem klaren Abbruch. Was niemand gebrauchen kann, ist ein Zustand, in dem die Runtime neue Turns zwar anstößt, aber keine LLM-Completion mehr dispatcht. Genau diesen Zwischenzustand adressiert der Patch.

Wo die Sitzung hängen bleibt

Laut PR-Beschreibung entsteht der Fehler, wenn ein Gateway einen laufenden Turn unterbricht. Die Restart-Recovery markiert die betroffene Session dann mit abortedLastRun=true. Gleichzeitig bleibt der Session-Status auf running. Solange diese Kombination stehen bleibt, sieht OpenClaw von außen nach aktiver Arbeit aus, intern ist der Turn aber nicht mehr sauber fortsetzbar.

Im Text zur PR ist der Ablauf ziemlich klar beschrieben: scheduleRestartAbortedMainSessionRecovery() startet nach dem Neustart die Wiederherstellung mit Exponential-Backoff. Wenn diese Wiederholungen erschöpft sind, passierte bisher nichts Aufräumendes mehr. Weder im .then()-Pfad noch im .catch()-Pfad wurde der verwaiste Marker entfernt. Das Ergebnis ist eine Session, die weiter als laufend gilt, aber bei der Dispatch-Logik keine neuen Modellantworten mehr lostritt.

Der Autor nennt das zu Recht einen Zombie-Zustand. assemble() feuert weiter, der Nutzer wartet, und der Gateway bleibt in einer Busy-Geste stecken, die operativ nichts mehr liefert. Für produktive Setups ist das genau die Sorte Fehler, die nicht spektakulär aussieht, aber Konversationen trotzdem kaputt macht.

Was der Patch konkret ändert

Laut Patch kommt die eigentliche Reparatur über eine neue Funktion namens clearStaleAbortedRunFlags(). Sie hängt in src/agents/main-session-restart-recovery.ts und läuft über alle Session-Stores, die die Restart-Recovery ohnehin kennt. Dort sucht sie nach Einträgen, bei denen gleichzeitig status === "running" und abortedLastRun === true gesetzt sind.

Findet der Code so einen Eintrag, löscht er den Flag, schreibt ein neues updatedAt und zählt den bereinigten Fall mit. Wenn mindestens eine Sitzung bereinigt wurde, erzeugt die Funktion laut Patch eine Warn-Logzeile, die genau diese Aufräumaktion meldet. Das ist eine vernünftige Wahl: Der Zustand ist ernst genug für Sichtbarkeit im Log, aber nicht so dramatisch, dass die Runtime dafür komplett stoppen müsste.

Wichtig ist auch, wann diese Bereinigung greift. Der Patch hängt sie nicht an einen frühen Recovery-Versuch, sondern an den Punkt, an dem alle Retries aufgebraucht sind und weiterhin fehlgeschlagene Fälle übrig bleiben. Zusätzlich soll derselbe Cleanup auch im Fehlerpfad des Schedulers anlaufen. OpenClaw behandelt den Marker also nicht als beliebiges Recovery-Signal, sondern als etwas, das nach einer gescheiterten Wiederaufnahme aktiv entfernt werden muss.

Warum das für Betreiber mehr ist als ein Komfort-Fix

Nach Angaben im PR-Text war das alte Verhalten deshalb so unerquicklich, weil neue Nachrichten nicht sauber weiterliefen, obwohl die Session formal noch aktiv war. Der Nutzer bekommt damit kein sauberes „Turn verloren, bitte erneut senden“, sondern eine Art Halbtot-Zustand. Für Telegram-, Discord- oder andere Dauerläufer ist das ein schlechter Fehler, weil er nicht sofort wie ein Crash aussieht. Die Sitzung antwortet nur nicht mehr sinnvoll.

Der Pull Request liefert sogar einen klaren Praxisrahmen mit: getestet wurde laut PR auf einer lokalen Gateway-Instanz in Version v2026.6.2, mit Node v26.2.0, isoliertem State-Verzeichnis und mehreren geladenen Plugins. Der Autor beschreibt außerdem einen Telegram-Chat als sichtbaren Beleg dafür, dass eine durch Restart unterbrochene Unterhaltung nach dem Fix wieder in einen sauberen Zustand kommt, statt permanent busy zu bleiben.

Das macht den Patch nicht automatisch merge-reif. In den Labels hängen ausdrücklich P1, zwei Session- und Message-Delivery-Risiken sowie status: needs proof. Aber gerade diese Label-Kombination zeigt, warum der Fall relevant ist: Hier geht es nicht um kosmetische Logs, sondern um Session-State und Zustellverhalten. Wenn eine Runtime nach einem Neustart den falschen Laufzustand konserviert, trifft das direkt die Verlässlichkeit des Produkts.

Die Restgefahr sitzt im False Positive

Die PR benennt ein klares Restrisiko selbst: Das Bereinigen könnte problematisch werden, wenn eine Sitzung in Wahrheit noch wirklich arbeitet und nur fälschlich wie ein verwaister Recovery-Fall aussieht. Dann würde das Entfernen von abortedLastRun eventuell einen konkurrierenden neuen Turn ermöglichen.

Der Gegenpunkt im PR ist technisch nachvollziehbar. Die Bereinigung greift nur auf Sessions, die gleichzeitig running und abortedLastRun=true sind. Laut Begründung wird dieses Flag gerade durch die Restart-Recovery gesetzt und dient damit als Marker für einen unterbrochenen, nicht für einen gesunden Live-Turn. Die neue Logik sagt also sinngemäß: Wenn alle Wiederherstellungsversuche fehlgeschlagen sind und dieser Marker noch immer steht, dann blockiert nicht mehr echte Arbeit, sondern veralteter Zustand.

Für Betreiber heißt das praktisch: Der Patch verschiebt den Default von „manuell entklemmen“ zu „Runtime räumt den Marker selbst weg“. Das ist genau die Richtung, die man bei Restart-Fehlern haben will. Recovery muss so weit wie möglich den beschädigten Zustand zurückbauen, statt die Reparatur an Slash-Commands zu delegieren.

Was vor einem Merge noch zählt

Laut PR ist der destruktive Repro eines echten Mid-Turn-Restarts in der lokalen Testumgebung noch nicht vollständig nachgestellt worden. Verifiziert wurden stattdessen Codepfad, kompiliertes Bundle, Session-Store-Zustand und ein Live-Gateway mit sauberem Health-Check. Das ist brauchbarer Beleg dafür, dass die neue Cleanup-Funktion an der richtigen Stelle sitzt. Es ist aber noch kein endgültiger Beweis, dass jeder reale Restart-Fall damit entschärft ist.

Genau deshalb ist dieser Patch für OpenClaw-Nutzer gerade jetzt lesenswert. Er zeigt eine typische Schwachstelle von Agenten-Runtimes: Nicht jeder Fehler ist ein Crash, viele sind hängengebliebene Zustandsmarker. Wenn ein System daraus keinen sauberen Recovery-Pfad macht, sehen Nutzer nur eine stumme Busy-Oberfläche. Der Fix in PR #92712 ist deshalb weniger eine kleine Codekorrektur als ein Test dafür, wie ernst OpenClaw seinen eigenen Session-State nimmt.