OpenClaw stolpert in Discord-Threads über verlorene ACP-Antworten

Eine ACP-Session in einem Discord-Thread kann intern weiterarbeiten, während im Thread keine Antwort mehr erscheint. Das ist mehr als ein Darstellungsfehler: Wer dort auf eine Rückmeldung wartet, sieht einen stillen Agenten und kann nicht erkennen, ob der Lauf hängt, fehlgeschlagen ist oder seine Antwort nur den falschen Weg genommen hat.

Ein GitHub-Issue vom 25. Juni beschreibt diesen Ablauf in einer Linux-Umgebung mit Discord, acpx als ACP-Backend und einem Claude-Modell. Der Bericht ist kein Beleg dafür, dass jede OpenClaw-Installation oder der aktuelle Stable-Stand betroffen ist. Er taugt aber als präziser Testfall für Teams, die ACP-Sessions an Discord-Threads binden.

Der auffällige Ablauf

Im beschriebenen Fall startet ein Agent in einem Discord-Thread. Ein Follow-up landet im selben Thread, die gebundene Session verarbeitet es weiter – sichtbar bleibt die Antwort dennoch aus.

Die Session-Transcripts enthalten nach Angaben des Issues weitere Nutzerfragen und erzeugte Assistentenantworten. Der Modelllauf erscheint daher nicht als naheliegender Ausgangspunkt für die Suche. Der Bruch liegt plausibel zwischen der fertigen Antwort und ihrer Zustellung in den ursprünglichen Thread.

Auch der Zustellkontext wirkt im Bericht nicht vollständig verloren: route, deliveryContext und originatingThreadId sollen auf dieselbe Discord-Thread-ID zeigen. Der Bot kann außerdem manuell in diesen Thread posten, wenn ein Parent-Agent das message-Tool direkt ausführt. Das schließt fehlende Discord-Rechte nicht endgültig aus, verschiebt den Fokus aber auf den Follow-up- und Delivery-Pfad.

Was im Thread wirklich geprüft werden muss

Ein erfolgreicher initialer Spawn genügt hier nicht. Der relevante Test beginnt mit einer weiteren Nachricht im bereits gebundenen Thread.

1. Einen neuen Thread mit einer ACP-Session starten.
2. Nach einer sichtbaren Antwort ein klar erkennbares Follow-up senden.
3. Prüfen, ob die nächste Antwort im selben Thread erscheint.
4. Fehlt sie, Session-Transcript und Zustellinformationen für genau diesen Lauf vergleichen.

Expected ist ein einfacher Ablauf: Die Session verarbeitet das Follow-up und die Antwort erscheint wieder im selben Thread. Actual im beschriebenen Fehlerfall: Das Transcript zeigt weitere Aktivität, Discord bleibt still.

Diese Kombination ist der Alarm. Eine grüne Session, frische Zeitstempel oder steigende Modellaktivität helfen dann nicht weiter, weil sie die Zustellung nicht belegen. Für mich gehört deshalb ein sichtbares Thread-Ergebnis zu jedem Monitoring-Signal für solche Workflows.

Die Verdachtszone sauber eingrenzen

Das Issue verweist auf den Zustellweg für Follow-up-Antworten. Bei vorhandenem Origin-Route-Kontext soll der Rückweg über routeReply() laufen. Scheitert dieser Schritt und bleibt der Fehler nur im Verbose-Log, entsteht ein besonders schlechter Betriebszustand: Die Session wirkt gesund, während Nutzer keine Antwort erhalten.

Ein weiterer Hinweis betrifft den ACP-sessionKey. Im Bericht fehlt dort ein :thread:-Suffix, aus dem Fallback-Logik Thread-Informationen ableiten kann. Das ist keine bestätigte Ursache. Es ist ein sinnvoller Prüfpunkt, wenn sich der Fehler lokal reproduzieren lässt: Erbt der Follow-up-Lauf den ursprünglichen Thread-Kontext, und welcher Zustellweg wird anschließend tatsächlich gewählt?

Der Ticketstatus und vorhandene Tests sind dabei Hintergrund, keine Entwarnung. Für den Betrieb zählt, ob der eigene Follow-up-Lauf im richtigen Thread ankommt.

Was bis zur Klärung hilft

Wenn eine gebundene ACP-Session Antworten erzeugt, aber Discord still bleibt, sollte sie keine Aufgaben übernehmen, deren Ergebnis zeitkritisch oder sicherheitsrelevant ist. Ein kurzer Statusjob kann weiterlaufen, solange sein Output begrenzt ist. Für Support-, Freigabe- oder Incident-Workflows braucht es dagegen einen sichtbaren Fallback: etwa einen separaten Kanal, eine Benachrichtigung oder einen manuellen Check des Transcripts.

Nach einem OpenClaw-Update oder einer Änderung an Discord, ACP oder Routing lohnt derselbe Wiederholungstest erneut. Damit wird aus einem schwer sichtbaren Issue eine klare Betriebsregel: Eine Thread-Session gilt erst als gesund, wenn das Follow-up verarbeitet wurde und die Antwort im selben Thread sichtbar angekommen ist.

Für angrenzende Kontrollen helfen Sandboxing & Exec-Approvals und Dashboard, Monitoring und Agenten-Sichtbarkeit.