OpenClaw: Auth-Cooldown kann Kanalantworten bei der Kompaktierung stoppen

Das normale Antwortmodell arbeitet einwandfrei, und trotzdem bleibt eine eingehende Kanalnachricht unbeantwortet. Ein GitHub-Issue vom 16. September 2026 beschreibt dieses Verhalten für den Fall, dass OpenClaw vor der Antwort den Kontext kompaktieren muss und bereits die Auth-Vorbereitung scheitert. Statt einer Fehlermeldung landet die Nachricht in der Retry-Behandlung.

Ein Cooldown, zwei Wege

Der Auslöser ist unspektakulär: Das Auth-Profil des ausdrücklich gewählten Kompaktierungsmodells steckt im Cooldown. Im Issue erscheint dazu die Meldung „Auth profile "summary:default" is temporarily unavailable for summary/compact-model.“ Für die Reproduktion braucht es weder Provider- noch Kanalzugänge; im synthetischen Cooldown-Szenario tritt der Fehler deterministisch auf.

Aufschlussreich ist der Vergleich der beiden Einstiegspunkte. Der direkte Kompaktierungsweg behandelt denselben Zustand sauber und liefert das erwartete erfolglose Resultat. Der Queue-Weg wirft dagegen eine Exception, noch bevor Kontext-Engine, Credential-Auflösung oder Summary-Anfrage laufen.

Gleicher Zustand, anderes Verhalten.

Die Reihenfolge macht daraus ein Problem für Nutzer. Die Kompaktierungsprüfung läuft vor der Übernahme der Eingabe. Weil der Fehlerklassifikator für Antworten die nackte Exception nicht erkennt, reicht der Dispatch sie bis zur Retry-Behandlung am Ingress weiter. Für Discord ergibt sich aus dem im Issue untersuchten Quellcode eine Richtlinie mit insgesamt acht Fehlversuchen; die anschließende Dead-Letter-Behandlung erzeugt keine Discord-Antwort. Einen Live-Test auf Discord beansprucht der Autor ausdrücklich nicht.

Die Reparatur gehört an die Fehlergrenze

Der vorgeschlagene Eingriff ist eng begrenzt. Nur der Fehler an der Auth-Planungsgrenze der Kompaktierung soll normalisiert werden. Eine gewöhnliche Ablehnung der Auth-Planung käme danach als erfolgloses Kompaktierungsresultat an. Daraus baut der bestehende Preflight-Pfad seine Fehlerantwort mit den Optionen, es erneut zu versuchen, /compact zu nutzen oder mit /new eine neue Session zu starten. Retry-Richtlinie, Konfiguration und gespeicherter Zustand bleiben unberührt.

Der Ansatz überzeugt, weil fast alles schon vorhanden ist: die Fehlermeldung, der Pfad dorthin und ein direkter Kompaktierungsweg, der sich bereits korrekt verhält. Es fehlt die Übersetzung der Exception in ein Resultat, das der restliche Ablauf versteht. Ein gesundes Hauptmodell rechtfertigt dabei keinen stillen Wechsel des ausdrücklich konfigurierten Kompaktierers. Profilreihenfolge, Cooldown-Regeln und Session-Zuständigkeit sollen unverändert bleiben.

Dokumentiert sind der reproduzierte Fehler und ein Reparaturvorschlag. Welche OpenClaw-Version konkret betroffen war und ob oder wann ein Fix ausgeliefert wurde, lässt sich aus dem Issue nicht bestimmen.

Diagnose im Betrieb

Das Symptom führt leicht auf die falsche Spur. Wer bei stummen Kanälen zuerst das Antwortmodell prüft, findet dort nichts: Die Anfrage scheitert, bevor überhaupt ein Modellaufruf stattfindet. Die Ursache liegt eine Ebene tiefer beim Modell, das den Kontext zusammenfassen soll.

Verdächtig ist vor allem diese Kombination: Nachrichten bleiben ohne Antwort und Fehlermeldung, das Antwortmodell ist erreichbar, und für die Kompaktierung ist ein eigenes Modellziel konfiguriert. Eine Meldung nach dem Muster „temporarily unavailable for …“ zum Profil dieses Modells passt zum dokumentierten Ablauf.

Als Mindestregel gilt deshalb: Bleiben Kanalantworten trotz gesundem Antwortmodell aus, prüfst du zuerst Auth-Status und Cooldown des ausdrücklich gewählten Kompaktierungsmodells. Im beschriebenen Testszenario reicht ein einziges Profil im Cooldown als Auslöser.