Kanal-Fehlersuche

Wenn ein Kanal kaputtgeht, geben viele dem Modell zu früh die Schuld. In der Praxis passieren die meisten OpenClaw-Messaging-Fehler entweder vor dem Modell oder nachdem das Modell längst fertig ist.

Genau deshalb wird Kanal-Fehlersuche besser, sobald du nicht mehr in "der Bot ist komisch" denkst, sondern in Schichten. Erst Identität, dann Transport, dann Antwortverhalten. Das ist eher wie das Debuggen einer Zuglinie als das Debuggen eines Satzes. Der Badge-Scanner am Bahnhof kann scheitern, die Strecke kann scheitern, oder der Zug kommt an und nur die Anzeigetafel erzählt Unsinn.

Die offizielle OpenClaw-Doku zu channels/troubleshooting ist hier erfreulich praktisch. Sie startet mit einer Kommandoleiter und ordnet danach typische Fehlersignaturen pro Kanal, statt so zu tun, als sähe jedes Slack-, Telegram-, Discord- oder Signal-Problem gleich aus.

Die schnellste erste Diagnoseleiter

Führe zuerst die Basischecks aus. Nicht weil es aufregend wäre, sondern weil planloses Raten langsamer ist.

openclaw status
openclaw gateway status
openclaw logs --follow
openclaw doctor
openclaw channels status --probe

Diese Reihenfolge beantwortet die fünf wichtigsten Fragen:

• läuft die Runtime überhaupt
• ist das Gateway gesund
• was scheitert in Echtzeit, wenn eine Nachricht ankommt
• gibt es beschädigte Abhängigkeiten oder lokale Umgebungsprobleme
• meldet der Kanaltransport verbunden, schreibbar und grundsätzlich gesund

Wenn du das überspringst und direkt Konfigurationschirurgie betreibst, reparierst du meist die falsche Schicht.

Was meistens zuerst kaputtgeht

Meist ist der erste Fehler unerquicklich normal. Credentials fehlen, ein Absender wurde nie freigegeben, ein Raum wird von einer Policy blockiert oder ein Kanal-Account ist konfiguriert, aber nicht verfügbar.

Die aktuelle offizielle Doku macht dieses Muster kanalübergreifend ziemlich klar. Bei Telegram sind es oft Token-, Privacy-Mode- oder Pairing-Probleme. Bei Slack meist Bot-Token, App-Token oder Scope-Mismatches. Discord scheitert gern still, wenn Message Content Intent oder Raumrechte falsch gesetzt sind. Signal stolpert oft schon an Daemon oder Account-Ebene, bevor die Chatlogik überhaupt drankommt.

Die gemeinsame Lektion ist schlicht: Wenn der Kanal sich nicht sauber authentifizieren kann, ist alles darüber nur Theater.

Denk in drei Schichten: Auth, Transport, Antwortverhalten

Dieses Denkmodell entfernt viel Nebel.

1. Auth und Zugriff

Diese Schicht beantwortet: Hat OpenClaw die richtige Identität und darf dieser Absender oder Raum sie überhaupt nutzen?

• abgelaufener oder falscher Bot-Token
• SecretRef ist konfiguriert, aber unavailable
• Pairing wurde nie genehmigt
• DM-Policy oder Allowlist blockiert den Absender
• Gruppen- oder Kanal-Policy schließt den Raum aus

Wenn ein Kanal "connected" meldet, DMs aber trotzdem nichts auslösen, sollten Pairing und Allowlists weit oben auf deiner Liste stehen. Die offizielle Troubleshooting-Seite wiederholt dieses Muster bei WhatsApp, Telegram, Slack, iMessage und Signal nicht ohne Grund.

2. Transport und Konnektivität

Diese Schicht beantwortet: Können Nachrichten überhaupt zuverlässig bewegt werden?

• Polling hängt oder stallt
• Proxy-, DNS- oder IPv6-Probleme
• Socket Mode verbindet sich und fällt dann still wieder aus
• Gateway-Reconnect-Loops oder verspätete Zustellung
• externe Daemons wie signal-cli sind erreichbar, aber ungesund

Hier verdienen sich Logs und openclaw channels status --probe ihren Platz. Transportprobleme hinterlassen meist Spuren: Reconnect-Loops, API-Fehler, Timeouts oder Probe-Ausgaben, die in einem Feld verbunden und im nächsten kaputt aussehen.

3. Antwortschicht und Formatierung

Das ist die heimtückische Schicht. Der Agent kann die Nachricht empfangen, darüber nachgedacht und sogar Tokens verbraucht haben, während die sichtbare Antwort nie dort auftaucht, wo der Mensch sie erwartet.

• Mention Gating blockiert Gruppenantworten
• Privacy Mode oder Sichtbarkeitseinstellungen verstecken Nachrichten
• Ambient-Room-Verhalten wird mit einem normalen Chatfluss verwechselt
• ein message_tool-Raum erwartet explizites Send-Verhalten
• Plattform-Formatierung lehnt ein Payload ab oder unterdrückt es

Discord ist laut offizieller Doku das klassische Beispiel. Du kannst Typing oder Token-Nutzung sehen, aber keine sichtbare Guild-Antwort bekommen, weil der Raum eher wie eine Ambient- oder Explicit-Send-Oberfläche läuft und nicht wie ein normaler "antworte automatisch"-Raum. Das wirkt nur so lange mysteriös, bis du die richtige Schicht isolierst. Danach ist es einfach Konfiguration.

So isolierst du die fehlerhafte Schicht schnell

Nutze eine einfache Verengungsfolge, statt alles gleichzeitig zu prüfen.

Starte mit einer bekannten Testfläche

Nimm einen bekannten DM oder einen klar erlaubten Raum und teste zuerst dort. Wenn jede Oberfläche anders ist, wird dein Signal schnell matschig.

Prüfe Identität vor Transport

Wenn Credentials oder Pairing falsch sind, verschwenden Transportchecks deine Zeit. Ein toter Badge-Scanner macht Flurdiagnostik plötzlich sehr gelehrt und gleichzeitig nutzlos.

Prüfe Transport vor Formatierung

Wenn sich die Nachricht nie bewegt hat, ist jede Theorie über sichtbare Antworten Ablenkung. Suche nach Probe-Ausgaben, API-Fehlern in Live-Logs, Reconnect-Loops und festhängendem Polling.

Erst dann das Raumverhalten prüfen

Wenn Auth und Transport sauber sind, frage dich, ob der Raum überhaupt sichtbar antworten sollte. Mention-Anforderungen, Group Policy, Ambient Events und explizite Send-Semantik liegen genau hier.

Kanalspezifische Fehlersignaturen, die du kennen solltest

Die offizielle Doku behandelt Kanäle nicht als austauschbar, und du solltest das auch nicht tun.

Telegram

Häufige Probleme starten mit getMe-Tokenfehlern, Privacy Mode in Gruppen, Pairing-Blocks oder Polling-Stalls. Wenn der Bot in DMs funktioniert, aber in Gruppen nicht, prüfe zuerst Sichtbarkeitsregeln statt das ganze Setup umzubauen.

Slack

Das wiederkehrende Muster ist verbundener Socket Mode ohne echte Antworten. Das weist meist auf Token-Setup, fehlende Scopes oder Raum-Policies hin. Slack bestraft Wunschdenken. "Connected" ist nicht dasselbe wie "vollständig autorisiert für alles, was du vorhast".

Discord

Message Content Intent, Kanalrechte, Mention Gating und sichtbares Antwortverhalten sind hier die Hauptverdächtigen. Wenn Arbeit sichtbar passiert, der Raum aber still bleibt, prüfe lieber die letzte Antwortschicht als vorschnell ein eingefrorenes Modell zu vermuten.

Signal

Signal bringt ein zusätzliches bewegliches Teil mit, weil das Gateway über signal-cli spricht. Dadurch startet die Fehlersuche manchmal eher beim externen Daemon, beim Account-Binding oder beim Nummernmodell als bei OpenClaw selbst.

Recovery-Gewohnheiten, die echte Zeit sparen

Die beste Troubleshooting-Gewohnheit ist kein cleverer Befehl. Es ist Disziplin.

• halte die feste Reihenfolge ein: Basis, Auth, Transport, Antwortverhalten
• ändere immer nur eine Variable gleichzeitig
• teste danach erneut in einem bekannten DM oder Raum
• beobachte Live-Logs, während du das Problem reproduzierst
• greife erst dann in die kanalgenauen Docs, wenn die fehlerhafte Schicht klar ist

Auch die offiziellen Schritte nach Updates sollte man sich merken. Wenn ein Kanal nach einem Update verschwindet, verweist die Doku zuerst auf openclaw doctor --fix und einen Gateway-Restart, besonders wenn Plugin-Abhängigkeiten beim Laden beschädigt wurden. Das ist deutlich besser, als blind in Dateien herumzustochern und den nächsten Tag gleich mit zu ruinieren.

Was die lokale Quellprüfung bestätigt

Aktuelle lokale OpenClaw-Artefakte stützen genau dieses Bild. Die Runtime kennt Kanal-Account-Zustände wie configured_unavailable, Telegram-Stall-Threshold-Einstellungen und kanalspezifische Probe-Logik. Anders gesagt: Die Doku erfindet keine saubere Taxonomie im Nachhinein. Die Software selbst unterscheidet fehlende Credentials, beschädigten Transport und Edge Cases im Antwortpfad.

Die praktische Regel

Debugge Kanäle nicht als ein einziges Mysterium. Debugge sie als Stack.

Beweise zuerst die Identität. Dann die Leitung. Dann das Raumverhalten. Der meiste Schmerz verschwindet, sobald du jeden stillen Bot nicht mehr wie ein philosophisches Problem behandelst.