OpenClaw: Multi-Account-Bug kann Telegram-Gruppenregeln aufspalten

Ein am 28. Juli veröffentlichter GitHub-Fehlerbericht beschreibt einen Fehler in OpenClaw bei Telegram-Setups mit mindestens zwei Konten. Kanalweite Gruppenregeln können dort auseinanderfallen: Die Erwähnungspflicht greift, die Senderfreigabe derselben Regel jedoch nicht zwingend.

Das ist keine harmlose Konfigurationskante. Nachrichten können ohne sichtbaren Hinweis verworfen werden; zugleich könnten Gruppen Nachrichten von Absendern annehmen, die eine zentrale Freigabeliste eigentlich ausschließen soll. Betroffen ist die Konstellation, in der mehrere Telegram-Konten eingerichtet sind, aber keines eine eigene Gruppen-Zuordnung mitbringt.

Zwei Auswerter lesen unterschiedliche Konfigurationen

Der Fehlerbericht beschreibt eine kanalweite Telegram-Gruppenregel und mehrere konfigurierte Konten. Fehlt bei den einzelnen Konten jeweils eine eigene groups-Zuordnung, übernimmt die eingehende Kontokonfiguration die kanalweite Gruppen-Map offenbar nicht. Nach Angaben des meldenden Contributors sucht der betroffene Multi-Account-Pfad ausschließlich am jeweiligen Konto.

Die Policy-Prüfung verfährt laut Bericht anders: Sie kann in derselben Konstellation auf die kanalweite Gruppenregel zurückfallen. Dadurch gilt möglicherweise requireMention, während allowFrom aus genau diesem Gruppeneintrag für die eingehende Nachricht nicht verfügbar ist.

Im Betrieb wirkt das wie eine zusammengehörige Schutzregel, technisch wird sie aber über zwei Pfade ausgewertet. Eine Gruppe kann also weiterhin eine Bot-Erwähnung verlangen und zugleich die erwartete Absenderliste nicht mehr zuverlässig prüfen. Besonders unerquicklich: Der Fehlerbericht ordnet abgelehnte Nachrichten vor der üblichen Inbound-Protokollierung, Deduplizierung und Antwortketten-Zuordnung ein.

Ein fehlender Eintrag im normalen Nachrichtenlog bedeutet damit nicht zwingend, dass Telegram nichts zugestellt hat. Die Nachricht kann bereits bei der Zugriffsprüfung aussortiert worden sein.

Das Fehlerbild verdient Aufmerksamkeit, weil es zwei entgegengesetzte Folgen haben kann. Bei einer zu restriktiven Auswertung geht eine legitime Nachricht verloren und der Bot wirkt einfach stumm. Fällt dagegen die Senderfreigabe weg, verschiebt sich eine Sicherheitsentscheidung unbemerkt: Eine Regel, die nur für bekannte Absender gedacht war, wird praktisch auf eine bloße Erwähnungspflicht reduziert. Der Bericht nennt beide Seiten nicht als theoretische Möglichkeit, sondern als Folge der getrennten Auflösung von Gruppenregel und Kontokonfiguration.

Der Workaround schützt nur mit Gegenprobe

Bis zu einer Entscheidung der Maintainer nennt der Bericht einen pragmatischen Umweg: Die kanalweite Gruppen-Map muss wortgleich in jedes einzelne Telegram-Konto kopiert werden. So erhält jedes Konto die Regel direkt, statt auf die uneinheitliche Übernahme aus der Kanal-Konfiguration angewiesen zu sein.

Das schließt die akute Lücke, erzeugt aber eine zweite Aufgabe: Mehrere Kopien einer Sicherheitsregel können auseinanderlaufen. Wird die Senderfreigabe später nur zentral geändert, bleibt ein Konto auf dem alten Stand. Bei wenigen Bots ist das lästig, bei getrennten Produkt- und Support-Konten wird es schnell schwer nachvollziehbar.

Ich würde den Workaround deshalb nicht ohne einen kleinen Matrix-Test ausrollen. Für jedes Konto und jede betroffene Gruppe sollten drei Fälle geprüft werden:

• Eine erlaubte Nachricht mit erforderlicher Erwähnung wird verarbeitet.
• Eine Nachricht eines nicht erlaubten Absenders wird abgewiesen.
• Eine erlaubte Nachricht ohne notwendige Erwähnung wird entsprechend der Regel behandelt.

Diese Gegenprobe testet die aufgelöste Regel je Konto statt nur den Happy Path eines einzelnen Bots.

Auch ein Blick auf die normale Inbound-Telemetrie gehört dazu. Der gemeldete Ablauf verwirft Nachrichten vor dem üblichen Logeintrag. Wer nur erfolgreiche Bot-Antworten zählt, übersieht daher sowohl den stillen Verlust als auch eine zu weit geöffnete Gruppe. Ein Testprotokoll mit Konto, Gruppe, Absenderklasse und Erwähnungsstatus macht die Prüfung später nachvollziehbar, ohne sich auf die zentrale Konfiguration als Wahrheit verlassen zu müssen.

Eine Abgrenzung mit Vorgeschichte

Der neue Bericht verweist auf GitHub-Issue #30673 vom 1. März. Dort bestand laut Issue die spiegelverkehrte Gefahr: Eine kanalweite Gruppen-Konfiguration wurde in Multi-Account-Setups still an alle Telegram-Konten vererbt. Das konnte Nachrichtenverlust verursachen, wenn Konten unterschiedliche Gruppenregeln benötigten; das Issue wurde am 2. März geschlossen.

Die aktuelle Meldung legt nahe, dass die stärkere Trennung der Konten nun einen anderen Teil der Konfiguration abschneidet. Bei Messaging-Runtimes ist das heikel, weil eine kurze Policy über Kontoauflösung, Gruppenregel und Nachrichteneingang verteilt ausgewertet wird.

Der offene Punkt ist damit nicht bloß, ob ein einzelnes Feld übernommen wird. Die zwei Pfade müssen dieselbe Regelbasis erhalten oder eine abweichende Konfiguration klar sichtbar machen. Solange das nicht geschieht, bleibt die kontoweise Hinterlegung ein Workaround, keine dauerhafte Vereinfachung. Besonders nach Versionswechseln müssen Plattformteams die Ablehnungsfälle ausdrücklich wiederholen.

Für produktive Telegram-Installationen bleibt damit eine klare Mindestregel: Bei mehreren Konten muss der Test die tatsächlich wirksame Gruppenregel pro Konto prüfen. Eine zentrale Konfiguration reicht nicht, wenn unterschiedliche Laufzeitpfade sie unterschiedlich lesen. Bis die Maintainer den Konflikt auflösen, ist die kontoweise Gruppen-Map eine vertretbare Absicherung — vorausgesetzt, unerlaubte Absender werden anschließend auch wirklich getestet und abgewiesen.