OpenClaw auf Main ergänzt bestätigte Sendungen im Verlauf des Zielchats

In OpenClaw können Agenten Nachrichten per Message-Tool oder über Cron-Jobs in Chats schicken. Landet so eine Nachricht in einem anderen Chat, sehen die Menschen dort sie sofort. Das Modell dieses Chats sah sie bisher nicht immer.

Pull Request #182329 wurde am 26. Oktober 2026 in den Main-Branch von OpenClaw gemergt. Laut dem PR landen Nachrichten, die in einen anderen Chat gesendet werden, jetzt einmal im Modellverlauf dieses Chats. Das gilt für Zustellungen, die der Kanal bestätigt hat und deren Zielchat sich eindeutig demselben Agenten zuordnen lässt. Ausnahmen bleiben trotzdem. Rein native Inhalte wie Umfragen kommen laut OpenClaw-Dokumentation auch dann nicht in den Verlauf. Für Rückfragen im Zielchat ist das eine echte Verbesserung. Trotzdem solltest du die Grenzen kennen. Eine Zeile im Verlauf, ein tatsächlicher Versand und die Erlaubnis zu senden sind drei verschiedene Dinge.

Was vorher fehlte

Nachrichten, die über das Message-Tool in einen anderen Chat gingen, wurden laut PR nur als reine Transcript-Spiegel gespeichert. Das Design-Dokument „Conversation transcript ownership“ in der OpenClaw-Dokumentation ergänzt, dass solche Spiegel bei der Wiedergabe des Verlaufs an das Modell übersprungen werden. Cron-Fehlermeldungen wurden gar nicht aufgezeichnet. Und jeder ausgehende Versandweg schrieb seine Verlaufseinträge auf eigene Weise.

Der Chat zeigte also Nachrichten, die in seinem Modellverlauf fehlten.

Welche Sendungen jetzt im Zielverlauf landen

Der PR zählt dazu Message-Tool-Sendungen über Chatgrenzen, Cron-Ergebnisse und Fehlerhinweise, weitergeleitete Antworten, Abschlüsse von Subagenten, Workshop-Hinweise und Plugin-Sendungen, die der Gateway ausführt. Fragt jemand im Zielchat „Was hast du hier gerade geschickt?“, kann das Modell die Nachricht jetzt sehen. Das setzt voraus, dass sie bestätigt, eindeutig zugeordnet und keine rein native Nutzlast ist.

Als Grundregel formuliert die Dokumentation: Eine Nachricht steht genau dann im modellsichtbaren Verlauf eines Chats, wenn dieser Chat sie angezeigt hat. Geschrieben wird sie einmal, als dieselbe Nachricht, nachdem der Kanal die Zustellung bestätigt hat. Ausnahmslos gilt das nicht. Gleich darunter listet die Dokumentation erlaubte Ausnahmen, darunter Chats eines anderen Agenten und rein native Inhalte, für die es keinen ehrlichen Text gibt.

Eingetragen wird laut PR an einer zentralen Stelle: Der Teil von OpenClaw, der eine Nachricht verschickt, schreibt nach jeder bestätigten Zustellung auch den Verlaufseintrag. Den Zielchat bestimmt er bevorzugt aus der Route, die mit der Nachricht mitläuft; nur ohne sie greift er auf den Zustellkontext, eine exakte lokale Bindung oder zuletzt auf die Auflösung über den Kanal zurück. Bleibt das Ziel mehrdeutig, entfällt der Eintrag. Bestätigte Dokumente behalten im modellsichtbaren Text Bildunterschrift und Dateinamen, gewähren laut Dokumentation aber keinen Zugriff auf lokale Dateien und erzeugen keine Download-URLs. Den Prompt-Cache stört das nicht: Einträge werden am Ende angehängt und schreiben früheren Verlauf nie um, das gecachte Präfix bleibt gültig.

Was nicht oder nicht doppelt im Verlauf landet

Eine normale Antwort im selben Chat bekommt keine zweite Zeile. Die Dokumentation fasst diese Ausnahme eng: Übersprungen wird der Eintrag nur, wenn die Sendung die Antwort eines Zuges im selben Gespräch ist. Dieser Zug hat sie bereits geschrieben.

Übersprungen werden außerdem agentenübergreifende Ziele, mehrdeutige Ziele und rein native Nutzlasten; wo es sinnvoll ist, entsteht eine Diagnose. Ist der Zielchat an einen anderen Agenten gebunden, wird die Nachricht gesendet, aber kein Transcript eines Agenten erhält sie. Als Beispiel für eine rein native Nutzlast nennt die Dokumentation ein Discord-Embed ohne Text. Auch Umfragen gelten dort als rein nativ und kommen nicht in den Verlauf.

Bei Mehrdeutigkeit gibt es eine Ausnahme. Pinnt ein Aufrufer den Empfängerchat, etwa bei Subagent-Abschlüssen oder Cron-Ergebnissen, gilt dieser Chat auch dann, wenn sich mehrere Chats eine Zustelladresse teilen.

Führt der Gateway eine Message-Aktion für einen entfernten Client aus, überlässt er den Eintrag im Zielverlauf diesem Client. So wird eine Sendung nicht zweimal unter verschiedenen Identitäten aufgezeichnet. Bei wiederhergestellten Sendungen kommt laut Dokumentation nur eine einzelne akzeptierte Nutzlast mit normalisiertem Text in den Verlauf; Batches mit mehreren Nutzlasten sowie Medien-, Präsentations- oder native Batches werden mit Warnung übersprungen.

Verlauf, Versand und Berechtigung auseinanderhalten

Die Aufzeichnung wartet nie auf einen gerade laufenden Zug im Zielchat. Scheitert sie nach einer Sendung, schreibt OpenClaw laut PR eine Warnung ins Log und sendet nicht erneut.

Eine Nachricht kann also im Kanal angekommen sein, obwohl ihre Zeile im Zielverlauf fehlt. Für die Fehlersuche heißt das: zuerst Kanal und Log prüfen. Erst danach einen Job oder Agenten erneut senden lassen. Sonst drohen doppelte Nachrichten. Mehr zu Wiederholungsversuchen: Agenten-Retries und Idempotenz.

Umgekehrt lese ich eine neue Verlaufszeile als Spur einer bestätigten Zustellung, nicht als Freigabe: Sie hält fest, was ein Chat angezeigt hat, und beantwortet nicht die Frage, wer dorthin senden darf. Dass der PR laut eigener Beschreibung weder Konfiguration noch Schema noch die gespeicherte Warteschlange ändert, reicht für eine Aussage über Berechtigungen nicht aus. Zum Thema Rechte in gemeinsamen Chats: OpenClaw-Gruppenchats sicher einrichten: Rechte, Erwähnungen und getrennte Sitzungen.

Was Plugin-Autoren beachten sollten

Für eigene Plugins nennt die PR-Beschreibung zwei Änderungen am Plugin SDK. Die bisherige Mirror-Eingabe wird noch bis zum nächsten SDK-Major akzeptiert, erzeugt aber eine Deprecation-Warnung und bestimmt nicht mehr, wohin der Verlauf geschrieben wird. Außerdem benennt session.key jetzt die Konversation, deren Zug die Sendung erzeugt hat. Ein Sender ohne erzeugenden Zug soll das Ziel als policyKey übergeben.

Der Wechsel hat eine Falle. Laut PR-Autor meldete eine automatisierte Review, dass SDK-Aufrufer stillschweigend Verlaufszeilen verlieren, wenn ihr session.key das Ziel benennt. Er reagierte darauf mit Migrationsleitfaden und Typdokumentation. Ich würde eigene Plugin-Aufrufe direkt an diesem Leitfaden abgleichen; die PR-Beschreibung fasst die Regeln nur zusammen.

Wie weit der Nachweis reicht

Den Nachweis beschreibt der Autor des PR selbst: In QA Lab startet ein echter Gateway, allerdings mit QA-Kanal und Mock-Modell und ohne Live-Zugangsdaten. Im neuen Szenario cross-conversation-send-history geht eine Message-Tool-Sendung von einem Raum in einen anderen. Nach seiner Darstellung erhält der empfangende Raum genau eine Verlaufszeile, der sendende keine. Auf Main ohne die Änderung scheitert dasselbe Szenario. Das ist ein begrenzter Testaufbau. Eine Live-Runde mit einem Drittkanal auf diesem Stand führt der PR ausdrücklich als nicht erledigt, und der Proof-Kommentar nennt einen Teststand, auf den bis zum Merge noch weitere Commits folgten.

Vor dem Merge warnte eine automatisierte Review, Gateway-gestützte Telegram-Sendungen könnten zwei Verlaufszeilen für eine einzige Zustellung anlegen. Laut einem späteren Kommentar des Autors überlässt der Gateway diesen Eintrag bei delegierten Message-Aktionen nun dem delegierenden Client. Diesen Pfad erreichen die QA-Szenarien nach seinen Angaben nicht; er ist mit Unit-Tests abgedeckt.

Offene Punkte führt auch die Dokumentation. Ein Eintrag muss dort in genau der Sitzung landen, die eine eingehende Antwort nutzt; für X verzeichnet sie dabei eine bekannte Abweichung. Umgesetzt sind die Schritte 1 und 2, die Migration der Job-Modi steht noch aus.

Main ist nicht dein installierter Stand

Belegt ist der Merge auf Main, laut GitHub als Commit 3fe7f1e. Bevor du dich im Zielchat auf den neuen Verlauf verlässt, prüfe, ob dein installierter Stand diesen Commit enthält.