OpenClaw Telegram antwortet nicht: Stalls, Replay-Fehler und Recovery

Wenn OpenClaw in Telegram nicht antwortet, ist der Messenger nur die sichtbare Oberfläche. Zwei konkrete OpenClaw-Vorgänge vom 22. Mai 2026 zeigen das gut: Ein Pull Request räumt alte Reply-Run-Zustände auf, die eine Unterhaltung blockieren konnten; ein GitHub-Issue beschreibt einen Replay-Fehler, bei dem überlange GitHub-Copilot-Reasoning-IDs den nächsten Antwortlauf verhindern können. In den Quellen sind das PR #85001 und Issue #85197. Für den Betrieb heißt das: Nicht zuerst am Telegram-Bot herumraten, sondern prüfen, an welcher Runtime-Schicht der Chat stecken bleibt.

Das typische Fehlerbild ist leicht zu beschreiben, aber im Betrieb nervig: Telegram nimmt die Nachricht an, OpenClaw startet scheinbar, vielleicht erscheint sogar eine Teilantwort — danach kommt nichts mehr. In einem anderen Pfad wird die eingehende Nachricht zwar als erledigt behandelt, aber der Assistant erzeugt gar keinen Output. Beide Varianten sehen vorne wie „OpenClaw Telegram antwortet nicht“ aus, haben hinten aber unterschiedliche Ursachen.

Fehlerbild: Telegram ist erreichbar, aber der Run hängt

Bei PR #85001 geht es nicht um einen kaputten Telegram-Transport, sondern um einen alten interaktiven Reply-Run. Laut PR räumt OpenClaw den Registry-Zustand früher auf, wenn eine laufende Operation abgebrochen wird und kein angebundener Backend-Handle mehr existiert. Vorher konnte ein solcher Zustand stehen bleiben und spätere Nachrichten in derselben Session blockieren oder erst nach zusätzlichem Nutzer-Anstoß weiterlaufen.

Die wichtige Diagnosefrage lautet deshalb: Ist der Kanal wirklich tot, oder hält die Runtime noch eine alte Session-Lane für aktiv? Wenn Telegram neue Nachrichten annimmt, aber dieselbe Unterhaltung still bleibt, spricht das eher für einen steckengebliebenen Run-Zustand als für einen reinen Bot- oder Token-Fehler. Das passt zu älteren OpenClaw-Failure-Modes, die im PR-Kontext erwähnt werden: Der Transport bleibt gesund, aber eine stale interactive run/session lane verarbeitet Folgemessages nicht sauber.

Der Fix ist eng begrenzt. Der PR beschreibt kein großes neues Messaging-Feature, sondern Lifecycle-Cleanup an einer kritischen Kante: Abbruch, fehlender Backend-Griff, aufgeräumter Reply-Run. Genau solche kleinen Invarianten entscheiden im Chat-Betrieb darüber, ob ein Agent robust wirkt oder zufällig hängen bleibt.

Zweiter Pfad: Replay baut einen ungültigen Provider-Request

Issue #85197 beschreibt ein anderes Fehlerbild mit ähnlicher Außenwirkung. Eine Telegram-Direct-Session läuft über GitHub Copilot native Responses mit gpt-5.5; in der gespeicherten Assistant-History liegt ein thinkingSignature-Reasoning-Item mit überlanger ID; beim nächsten Telegram-Direct-Reply baut OpenClaw aus dieser History wieder einen Responses-input[]-Payload. Laut Issue kann der Provider den Request dann ablehnen, bevor Assistant-Output entsteht, weil input[].id höchstens 64 Zeichen lang sein darf.

Expected vs. Actual ist hier entscheidend:

• Expected: OpenClaw erhält gültige kurze Responses-Replay-Item-IDs oder normalisiert überlange Replay-IDs vor dem Versand.
• Actual laut Issue: Die Telegram-Nachricht wird akzeptiert und dispatched, der Agent-Run scheitert vor der Antwort, und das Gateway markiert den Inbound trotzdem als abgeschlossen.

Das ist ein klassischer Replay-Bug: Nicht der neue Prompt ist das Problem, sondern ein altes History-Fragment, das beim Wiederaufbau des Provider-Requests zu wörtlich übernommen wird. Wer nur Telegram neu startet, wird damit nicht zwingend weiterkommen.

Diagnose: vier Schichten statt ein Schuldiger

Für die Fehlersuche hilft ein vierstufiges Modell:

1. Channel-Annahme: Kommt die Telegram-Nachricht überhaupt bei OpenClaw an? Wenn nein, liegt der Fehler eher bei Bot-Konfiguration, Webhook/Polling, Token oder Gateway-Erreichbarkeit.
2. Session-Zuordnung: Landet die Nachricht in der erwarteten Direct-Session oder in einer anderen Gesprächsspur? Wenn der falsche Kontext reaktiviert wird, sieht das vorne wie Funkstille aus, obwohl der Bot technisch erreichbar ist.
3. Runtime-Lane: Wird für dieselbe Unterhaltung noch ein alter interaktiver Run gehalten? Wenn neue Nachrichten angenommen werden, aber nicht weiterlaufen, ist ein stale Reply-Run plausibel.
4. Provider-Replay: Scheitert der Run beim Aufbau oder Versand des Provider-Requests? Dann lohnt der Blick auf gespeicherte Session-History, Replay-Items und provider-spezifische Payload-Grenzen.

In der Praxis trennt diese Reihenfolge zwei Fragen, die gern vermischt werden: „Erreicht Telegram OpenClaw?“ und „kann OpenClaw aus dem aktuellen Session-Zustand eine gültige Antwort erzeugen?“ Der Channel-Teil ist Messenger-Setup. Der Replay-Teil ist AgentOps.

Als schnelle Triage reicht oft diese Matrix:

Beobachtung	Wahrscheinliche Schicht	Nächster sinnvoller Check
Telegram zeigt keinen Eingang in OpenClaw	Transport	Bot-Token, Webhook/Polling und Gateway-Erreichbarkeit prüfen
Eingang wird registriert, aber dieselbe Unterhaltung bleibt stumm	Runtime-Lane	Auf alte interaktive Runs oder abgebrochene Reply-Zustände achten
Neue Unterhaltung antwortet, alte Unterhaltung nicht	Session-Zustand	Persistierte History und Session-Zuordnung als Verdächtige behandeln
Run startet, bricht aber vor Assistant-Output ab	Provider-Replay	Replay-Items und provider-spezifische Payload-Grenzen prüfen

Wichtig ist die Reihenfolge: Erst feststellen, ob der Inbound wirklich ankommt; dann prüfen, ob der richtige Session-Kontext läuft; erst danach Provider oder Modell wechseln. Sonst repariert man am sichtbaren Messenger herum, obwohl der Fehler hinter der Zustellung sitzt.

Wenn du zuerst das generelle Setup absichern willst, passt der Einstieg über Telegram und WhatsApp in OpenClaw verbinden. Wenn die Zustellung über geplante Jobs oder Follow-ups still bleibt, ist der verwandte Guide zu OpenClaw-Crons, Sessions und Delivery näher am Problem. Für die Sicherheitsseite rund um Befehle und Recovery-Pfade ist Sandboxing und Exec-Approvals der bessere Nachbarartikel.

Recovery und Workaround

Aus den beiden belegten Fällen lässt sich kein universeller „ein Kommando fixt alles“-Runbook ableiten. Sinnvoll ist aber ein vorsichtiger Recovery-Pfad:

• Nicht sofort den Telegram-Bot neu bauen. Wenn Nachrichten angenommen werden, ist der Transport wahrscheinlich nicht der erste Verdächtige.
• Betroffene Session isolieren. Tritt der Stall nur in einer Direct-Session auf, ist Session-Zustand wahrscheinlicher als ein globaler Gateway-Ausfall.
• Frische Unterhaltung testen. Wenn ein neuer Chat oder eine neue Session antwortet, spricht das gegen Telegram als Ursache und für stale Runtime- oder Replay-History.
• Provider-Wechsel nicht überbewerten. Ein anderer Provider kann den Replay-Pfad umgehen, beweist aber nicht, dass Telegram repariert wurde.
• History-/Replay-Risiko prüfen. Bei Copilot native Responses ist laut Issue speziell relevant, ob persistierte Reasoning-Items mit ungültigen IDs wieder in den Request wandern.
• Erfolg sauber definieren. Eine angenommene Telegram-Nachricht ist noch keine erfolgreiche Antwort. Erst Assistant-Output oder ein klarer Fehler im Antwortpfad zählt als verwertbares Ergebnis.

Für ein Runbook heißt das: Nicht mehrere Stellschrauben gleichzeitig drehen. Wenn du Bot-Token, Session und Provider in einem Schritt wechselst, weißt du danach nicht, welcher Teil den Stall gelöst oder maskiert hat. Besser ist ein reproduzierbarer Vergleich: gleiche Nachricht, gleiche Unterhaltung, dann frische Unterhaltung, dann erst Provider-/Replay-Pfad.

Nicht getestet ist hier ein sauber dokumentierter manueller Eingriff in einzelne gespeicherte History-Items. Ohne belastbare Upstream-Dokumentation wäre eine Anleitung zum Löschen konkreter Zustandsdateien oder Datenbankzeilen Fake-Ops-Tiefe. Der sichere Schluss ist enger: Wenn eine alte Session reproduzierbar scheitert, eine frische Session aber antwortet, sollte die Diagnose auf Runtime-Registry und Replay-History gehen — nicht auf Telegram allein.

Sicherheitsgrenzen: nicht blind History wegwerfen

Bei Messenger-Agenten ist Recovery immer auch ein Sicherheitsproblem. Session-History enthält Kontext, potenziell private Nutzereingaben und manchmal provider-nahe Metadaten. Wer zur Reparatur blind Verlauf löscht, kann zwar einen Stall umgehen, verliert aber Auditierbarkeit und möglicherweise wichtige Zustandsgrenzen. Umgekehrt darf ein Gateway einen Inbound-Event nicht als erfolgreich behandeln, wenn nie Assistant-Output entstanden ist.

Die robuste Ziel-Invariante ist deshalb dreiteilig: Ein abgebrochener Run blockiert keine Session-Lane; ein Replay verschickt keine provider-ungültigen IDs; ein Kanal meldet nicht vorschnell Erfolg, wenn der Antwortpfad vor dem Stream abbricht. Das klingt trocken. Genau dort entsteht aber Produktionsqualität.

Reality Check

• Belegt: PR #85001 beschreibt Cleanup für orphaned reply run aborts ohne attached backend; Issue #85197 beschreibt überlange Copilot-Reasoning-Item-IDs im Telegram-Direct-Replay.
• Belegt: Der PR dokumentiert einen versuchten fokussierten Vitest-Lauf, der in einem Scratch-Checkout wegen fehlender Registry-Metadaten für @copilotkit/aimock nicht durchlief.
• Nicht belegt: Ein allgemeines Kommando, das jeden Telegram-Stall zuverlässig repariert.
• Nicht getestet: Manuelles Bereinigen einzelner Replay-History-Einträge als Recovery-Methode.
• Operative Lehre: Bei „Telegram antwortet nicht“ zuerst zwischen Transport, Session-Zuordnung, Reply-Run-Lane und Provider-Replay unterscheiden.

FAQ: OpenClaw Telegram antwortet nicht

Ist Telegram schuld, wenn keine Antwort kommt?

Nicht zwingend. Wenn OpenClaw die Nachricht annimmt, aber kein Assistant-Output entsteht, kann der Fehler hinter dem Messenger liegen: in einem alten Reply-Run-Zustand, im Session-Replay oder im Provider-Payload.

Warum hilft ein Neustart manchmal nur kurz?

Ein Neustart kann flüchtige Runtime-Zustände leeren. Wenn die Ursache aber in gespeicherter Session-History oder einem wiederverwendeten Replay-Item liegt, kann der Fehler beim nächsten Direct-Reply wieder auftauchen.

Soll ich einfach den Chat-Verlauf löschen?

Nur als bewusstes Recovery-Experiment, nicht als Standardreflex. Verlauf kann relevante Nutzerdaten, Audit-Kontext und Provider-Metadaten enthalten. Ohne klares Backup- und Restore-Verständnis ist blindes Löschen riskant.

Woran erkenne ich einen Replay-Fehler?

Ein Hinweis ist: Die Nachricht wird angenommen, aber der Run scheitert, bevor Assistant-Output entsteht. In #85197 lag der konkrete Auslöser bei überlangen Copilot-Reasoning-IDs, die aus gespeicherter History wieder in input[] übernommen wurden.