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

OpenClaw hat ein Discord-Problem, das im Betrieb teurer werden kann als ein normaler Thread-Bug: In thread-gebundenen ACP-Sessions lassen sich Follow-up-Nachrichten weiter verarbeiten, ohne dass die Antwort noch im betroffenen Discord-Thread auftaucht. Das offene GitHub-Issue #96665 vom 25. Juni beschreibt damit keinen bloßen Schönheitsfehler, sondern einen Fall, bei dem Agentenantworten intern entstehen und extern trotzdem verloren gehen.

Gerade für Teams, die ACP-Sessions an Discord-Threads binden, trifft das den Kern des Workflows. Der Thread ist dort nicht nur Gesprächsverlauf, sondern sichtbarer Rückkanal. Wenn der Agent intern weiterläuft, im Thread aber Schweigen herrscht, wirkt ein eigentlich aktiver Ablauf für Nutzer wie ein Ausfall.

Das Modell antwortet, aber der Thread bleibt still

Der Report beschreibt eine aktuelle OpenClaw-Umgebung auf Linux mit Discord als Transportkanal, acpx als ACP-Backend und claude-opus-4-8 als Modell. Das beobachtete Muster ist klar: Thread starten, Follow-up im Thread senden, keine sichtbare Antwort zurückbekommen.

Entscheidend ist dabei die Trennung zwischen Generierung und Zustellung. Nach Angaben im Issue enthalten die Session-Transcripts mehrere Follow-up-Fragen, auf die intern Assistentenantworten erzeugt wurden. Der Modelllauf scheint also nicht zu hängen. Der Bruch sitzt offenbar danach, wenn die Antwort wieder in denselben Discord-Thread zugestellt werden soll.

Der Reporter nennt dafür noch einen wichtigen Hinweis: In den Session-Metadaten sollen route, deliveryContext und originatingThreadId dieselbe Discord-Thread-ID tragen. Der Kontext für die Zustellung ist demnach nicht einfach verschwunden. Zusätzlich verweist das Ticket darauf, dass der Bot manuell in denselben Thread posten kann, wenn der Parent-Agent das message-Tool direkt nutzt. Ein reines Rechteproblem auf Discord-Seite wirkt damit eher unplausibel.

Warum das mehr ist als ein UX-Fehler

OpenClaw hat das Ticket mit impact:message-loss, impact:session-state und P2 markiert; dazu kommt clawsweeper:needs-live-repro. Diese Kombination ist die eigentliche Nachricht. Der Fall wird nicht als harmlose Einzelanomalie behandelt, aber eben auch noch nicht als vollständig verifizierter Plattformfehler.

Der ClawSweeper-Kommentar läuft in dieselbe Richtung. Das Ticket bleibt offen, weil der Report einen konkreten Discord-ACP-Fall mit Session-Belegen beschreibt und weder ein gemergter Fix noch eine saubere Dublette vorliegt. Gleichzeitig fehlt weiter eine belastbare Live-Reproduktion.

Für Betreiber ist genau diese Zwischenlage wichtig. Der Vorfall ist zu konkret, um ihn als bloßes Forenrauschen abzuhaken. Er ist aber noch nicht sauber genug bestätigt, um jede Discord-Installation mit ACP pauschal unter Generalverdacht zu stellen. Die richtige Reaktion ist deshalb nicht Alarmismus, sondern ein gezielter Check des eigenen Setups.

Wo die Bruchstelle plausibel sitzt

Der Report grenzt den Verdacht auf den Zustellpfad für Follow-up-Antworten ein. Beschrieben wird ein Ablauf, bei dem deliver(kind, payload) bei vorhandenem Origin-Route-Kontext intern routeReply() nutzt. Wenn dieser Rückweg scheitert, landet der Fehler laut Issue offenbar nur in einem logVerbose()-Eintrag. Genau das macht den Fall im Alltag heikel: Die Session wirkt aktiv, aber im Thread kommt nichts an.

Ein zweiter Hinweis betrifft den ACP-sessionKey. Nach Angaben des Reporters trägt er keinen :thread:-Suffix, obwohl Fallback-Logik Thread-Informationen auch aus so einem Suffix ableiten kann. Das ist noch kein bestätigter Root Cause, aber eine plausible Schwachstelle. Wenn Follow-up-Runs den Thread-Kontext nicht sauber erben oder unterwegs auf eine schwächere Route fallen, kann die Antwort intern erzeugt und extern trotzdem verloren gehen.

Interessant ist das Ticket auch deshalb, weil der ClawSweeper-Kommentar sinngemäß darauf verweist, dass Teile der Routen-Weitergabe im aktuellen Code bereits abgedeckt seien und es separate Tests für Discord-Thread-Zustellung gebe. Das sieht also weniger nach fehlendem Feature aus als nach einem Loch zwischen Session-Bindung, Delivery-Context und tatsächlichem Follow-up-Pfad.

Was du im Betrieb konkret prüfen solltest

Wenn du OpenClaw mit Discord-Threads und ACP-Sessions betreibst, ist das vor allem ein Runtime- und Monitoring-Thema. Die gefährliche Variante dieses Bugs ist kein Crash, sondern eine Session, die intern gesund aussieht und extern trotzdem verstummt. Wer nur auf laufende Sessions, frische Timestamps oder Modellaktivität schaut, kann das leicht übersehen.

Der wichtigste Praxistest ist deshalb nicht der initiale Spawn, sondern das Follow-up im bereits gebundenen Thread. Genau dort beschreibt das Issue die Lücke. Erwartet wird: Der Agent verarbeitet die Nachricht und liefert die Antwort wieder sichtbar im selben Thread zurück. Bleibt die Antwort aus, obwohl die Session intern weiterläuft oder im Transcript neue Antworten auftauchen, hast du genau das verdächtige Muster aus #96665 vor dir.

Ebenso wichtig ist die Sichtbarkeit des Fehlers. Wenn Route-Probleme in diesem Pfad tatsächlich nur verbose geloggt werden, fällt der Defekt schnell unter den Tisch. Bis OpenClaw dafür klarere Statussignale, Counter oder lautere Fehlerpfade anbietet, bleibt ein einfacher Praxistest oft am zuverlässigsten: echte Follow-ups im Thread schicken und den sichtbaren Rückweg kontrollieren, nicht nur die interne Session-Aktivität.

Der eigentliche Schaden ist Vertrauensverlust

Thread-basierte Agenten-Workflows funktionieren nur dann sauber, wenn Kontext, Ausführung und sichtbares Ergebnis zusammenbleiben. Wenn OpenClaw intern korrekt antwortet, die Rückgabe in den Thread aber ausfällt, entsteht der schlechteste Zwischenzustand: technisch aktiv, operativ unsichtbar. Für Teams ist das oft schwerer zu handhaben als ein harter Fehler, weil Message Loss spät auffällt und schnell wie Bedienfehler oder stilles Nutzerverhalten aussieht.

Genau deshalb ist Issue #96665 schon jetzt relevant, obwohl noch kein bestätigter Fix vorliegt. Das Ticket liefert eine benannte Umgebung, Session-Belege, passende Impact-Labels und eine nachvollziehbare Verdachtszone im Delivery-Pfad. Was noch fehlt, ist kein grober Problemaufriss mehr, sondern ein enger Repro auf aktuellem Stand samt Regressionstest. Bis dahin gilt für Discord-gebundene ACP-Sessions eine einfache Betriebsregel: Prüfe nicht nur, ob der Agent läuft, sondern ob seine letzte Antwort auch wirklich im Thread angekommen ist.