OpenClaw-Fix gegen Crash-Loops durch Anthropic-Thinking-Signaturen

OpenClaw hat ein hartnäckiges Laufzeitproblem behoben: Abgelaufene kryptografische Signaturen in Anthropic-„Thinking“-Blöcken konnten gespeicherte Agenten-Sessions in einen Crash-Loop zwingen. Der Fall zeigt ein grundlegendes Muster für Agenten-Runtimes: Langfristig gespeicherte Verläufe müssen provider-spezifisch bereinigt werden, bevor sie erneut an Modelle gesendet werden. Der Fix in Pull Request #88941 entfernt diese historischen Zwischenzustände vor dem Replay an die Anthropic API.

Das Problem: Abgelaufene Signaturen blockieren Sessions

Laut Issue #88932 tritt der Fehler in Sessions mit Anthropic-Modellen und aktiviertem Thinking-Modus wie thinking=adaptive auf. Die erweiterten Thinking-Blöcke enthalten zeitlich begrenzte, kryptografische Signaturen für das Replay.

Bisher entfernte die Logik nur Blöcke mit fehlender oder leerer Signatur. Blöcke mit vorhandener, aber abgelaufener Signatur wurden durchgelassen. Beim erneuten Senden an die Anthropic Messages API löste dies den Fehler Invalid signature in thinking block aus.

Die kritische Konsequenz war die Persistenz: Der fehlerhafte Verlauf wurde bei jedem weiteren Aufruf wiederverwendet und auf Disk gespeichert. Nach einem Neustart lud die Session denselben defekten Zustand erneut – ein klassischer Crash-Loop entstand.

Die Lösung: Historische Thinking-Blöcke streichen

Pull Request #88941 setzt in der Provider-Konvertierung an. In src/llm/providers/transform-messages.ts werden nun alle Thinking-Blöcke aus historischen Assistant-Nachrichten entfernt, unabhängig vom Signaturstatus. Der aktuelle Thinking-Block eines laufenden Turns bleibt über den separaten Stream-Handler erhalten.

Die Begründung ist pragmatisch: Frühere Thinking-Blöcke sind Provider-interner Zwischenzustand, kein nutzbarer Gesprächsinhalt. Ihr Replay birgt bei ablaufenden Signaturen mehr Risiko als Nutzen. Der PR ändert keine Konfigurationen, Migrationen oder Sicherheitseinstellungen. Das Hauptrisiko liegt im Over-Stripping, also dem versehentlichen Entfernen benötigter Blöcke, was durch die Trennung von aktuellem und historischem Pfad abgesichert wird.

Betriebliche Konsequenzen und Recovery

Für den Agenten-Betrieb ist das beschriebene Pattern relevanter als der spezifische Anthropic-Fehler: Langfristig gespeicherte Verläufe müssen provider-spezifisch bereinigt werden, bevor sie erneut an Modelle gesendet werden.

Issue #88932 dokumentiert zwei Produktionsausfälle mit Downtime im ein- bis mehrstelligen Stundenbereich. Die einzige manuelle Recovery bestand im Löschen des Session-Transcripts. Das unterstreicht, dass solche Fehler vor allem langlebige Agenten treffen, die ihren Zustand über viele Turns und Neustarts hinweg bewahren.

Die Lehre ist nicht, den Thinking-Modus zu meiden, sondern Transcripts vor dem Replay aktiv zu sanitizen. Reasoning- oder Thinking-Artefakte gehören nicht automatisch dauerhaft in den Gesprächsverlauf.

Einordnung für die Praxis

• Getestet mit: Analyse von Issue #88932 und Pull Request #88941 im OpenClaw-Repository.
• Relevanz: Besonders für lange OpenClaw-Sessions mit Anthropic-Modellen und persistentem Verlauf.
• Limitationen: Alte Session-Zustände mit bereits persistierten, ungültigen Blöcken könnten vor dem Fix weiterhin Probleme verursachen.
• Sicherheitsrisiko: Gering; der PR enthält laut Beschreibung keine Security-, Auth- oder Netzwerkänderungen.
• Betriebsaufwand: Niedrig, sobald der Fix in der eigenen Installation deployed ist.
• Recovery: Vor dem Fix nur manuell via Löschung des Session-Transcripts möglich.

Fazit

Betreiber von OpenClaw mit Anthropic und Thinking-Modus sollten prüfen, ob lange Sessions nach einem Neustart zuverlässig weiterlaufen. Entscheidend ist die Fähigkeit, gespeicherte Verläufe sauber fortzusetzen.

Für das Design von Agenten-Runtimes ist der Fall ein klares Signal: Es braucht eine klare Trennung zwischen nutzerrelevantem Gesprächszustand und providerinternen Artefakten. Andernfalls kann ein abgelaufenes Signaturfeld zum Auslöser für hartnäckige Betriebsprobleme werden. Weitere Hintergründe zu solchen Architekturmustern und wie Multi-Agenten-Systeme mit Zustand umgehen finden sich in unserem Artikel über KI-Agenten-Architektur für kleine Teams.