OpenClaw: Claude-CLI-Fragen verschwinden im Chatkanal

Claude-CLI-basierte Agenten stellen eine Rückfrage, und niemand sieht sie. Das GitHub-Issue #116554 vom 30. Juli 2026 beschreibt, wie das Gateway die ask_user-Frage erzeugt und darauf blockiert, ohne sie in den ursprünglichen Chatkanal zuzustellen. Der Reparatur-PR #117152 ist bislang der sichtbare Stand der Aufarbeitung — und er ist offen.

Zwei Fehler, die zusammen wie ein Hänger aussehen

Der erste Fehler ist die ausbleibende Zustellung. Laut Issue #116554 sah der Reporter weder die interaktive Karte noch den nummerierten Text-Fallback im Kanal. Es erscheint schlicht nichts. Damit fehlt beiden Seiten der Anker: Der Agent wartet auf eine Antwort, die niemand geben kann, weil die Aufforderung dazu unsichtbar bleibt.

Der zweite Fehler ist ein Zeitlimit, das die Symptomatik verschiebt. Der Gateway-WebSocket-Pfad beendet das Warten nach rund 60 Sekunden, obwohl ask_user standardmäßig ein Fenster von 900 Sekunden vorsieht. Der Workflow endet also nicht an der ausbleibenden Antwort, sondern deutlich früher an einem Transport-Timeout, das mit der eigentlichen Frage nichts zu tun hat. Im Betrieb sieht das nach einem hängenden oder abgebrochenen Lauf aus, nicht nach einer offenen Rückfrage. Das Issue ist als P1 und als mögliches Message-Loss-Problem markiert.

Diese Trennung ist mehr als Diagnose-Kosmetik: Wer nur den Timeout hochsetzt, behebt nichts — die Frage bleibt unsichtbar. Wer nur die Zustellung repariert, läuft weiter in den Cap.

Der Reparaturpfad ist beschrieben, aber nicht ausgeliefert

Nach Angaben von PR #117152 vom 24. August 2026 sollen Claude-CLI-Loopback-Aufrufe künftig denselben konversationsbewussten Zustellzyklus reservieren und nutzen wie eingebettete Agenten. Dokumentiert sind dort 173 fokussierte Tests für ask_user und eingebettete Zustellung als bestanden. Erwähnt wird außerdem ein Punkt, der über den reinen Message-Loss hinausgeht: Lange Frage-Wartezeiten konnten zusätzlich das Standard-Zeitlimit externer MCP-Anfragen von Claude Code überschreiten. Wer nur den WebSocket-Cap betrachtet, greift also zu kurz.

Der Stand zum Redaktionsschluss am 25. August 2026: PR #117152 ist offen. Der Zustellpfad wäre repariert, wenn der PR in dieser Form übernommen wird — übernommen ist er nicht, ausgeliefert also auch nicht. Zwischen einem beschriebenen Fix und einem wirksamen Fix liegt hier ein Merge, und der Status kann sich nach Veröffentlichung dieses Artikels ändern.

Prüfmaßstab für den Übergangsbetrieb

Bis zur Übernahme dürfen Claude-CLI-Workflows mit ask_user nicht darauf vertrauen, dass die Frage im Kanal erscheint. Beobachtbar prüfen heißt: kontrollieren, ob die Präsentation im Zielkanal tatsächlich auftaucht und ob der Antwortweg zurück zum wartenden Agent trägt — beides einzeln, nicht als Annahme.

Praktisch heißt das zweierlei. Erstens gehört jeder ask_user-Aufruf in einem Claude-CLI-Pfad an ein eigenes Timeout, das kürzer ist als das, was der Transport ohnehin abschneidet — sonst verwechselt die Auswertung Transport- und Antwortfehler. Zweitens braucht jeder solche Lauf einen menschlichen Beobachter, solange der Nachweis der Zustellung fehlt. Wo dieser Nachweis fehlt, gehört ask_user in Claude-CLI-Pfaden nicht in einen unbeaufsichtigten Workflow.