OpenClaw-Gruppenchats sicher einrichten: Rechte, Erwähnungen und getrennte Sitzungen

Ein Gruppenchat wird nicht dadurch sicher, dass der Agent nur auf ausgewählte Personen reagiert. Raumfreigabe, Absenderfreigabe und Erwähnungs-Gate steuern, ob eine Nachricht einen Lauf auslösen darf. Zitate, Threads und abgerufener Verlauf bilden eine eigene Kontextfläche.

Laut OpenClaw-Dokumentation gelten die grundlegenden Gruppenregeln für alle gruppenfähigen Kanäle. Dieses Tutorial verwendet WhatsApp, weil dort Gruppen-JIDs, Absenderfreigaben und Mention-Gating konkret dokumentiert sind. Details anderer Adapter müssen anhand ihrer jeweiligen Kanaldokumentation geprüft werden.

Trigger und ergänzter Kontext sind getrennte Schutzflächen

Für Gruppen greifen groupPolicy, groups und groupAllowFrom. Sie entscheiden, welche Räume und Absender zugelassen sind. requireMention entscheidet anschließend, ob eine zugelassene Nachricht einen Agent-Lauf auslöst.

Daneben steuert der globale Pfad channels.defaults.contextVisibility, welcher ergänzte Zitat-, Thread- und Verlaufskontext übernommen wird. Das Schema kennt drei Werte: all behält diesen Kontext vollständig, allowlist beschränkt ihn auf zugelassene Absender und allowlist_quote behält zusätzlich ausdrücklich zitierte Nachrichten.

Die Einstellung ändert nicht die Raum- oder Absenderzulassung. Sie begrenzt ergänzten Kontext, der zu einer bereits zugelassenen Anfrage abgerufen wird. Eine erlaubte Person kann beispielsweise eine Nachricht eines nicht erlaubten Absenders zitieren. Deshalb müssen Admission und Kontextsichtbarkeit separat geprüft werden.

Voraussetzungen für einen prüfbaren Test

Verbinde den WhatsApp-Account wie im Tutorial Telegram und WhatsApp verbinden beschrieben. openclaw channels status --probe muss den Account als erreichbar melden, bevor du Gruppenregeln untersuchst.

Bereite zwei kontrollierte Gruppen vor. Gruppe A wird zugelassen, Gruppe B bleibt ungelistet. Ermittle ihre vollständigen WhatsApp-JIDs aus eingehenden Logs; eine Gruppen-JID endet typischerweise auf @g.us. Anzeigenamen reichen für die Konfiguration nicht aus.

Nutze außerdem zwei kontrollierte Absender. Person A wird mit ihrer WhatsApp-Absender-ID freigegeben, Person B bleibt ungelistet. Beide Personen müssen während des Tests eindeutig identifizierbar sein. Verwende keine fremden Gruppenmitglieder für Negativtests.

Öffne parallel die Gateway-Logs, etwa mit openclaw logs --follow, und die Sitzungsansicht der Control UI. Du brauchst Zugriff auf Admission-Hinweise, gestartete Agent-Läufe und Sitzungsschlüssel. Sichtbares Schweigen allein liefert keine eindeutige Diagnose.

Sichere vor der Änderung die bestehende Konfiguration:

cp ~/.openclaw/openclaw.json ~/.openclaw/openclaw.json.before-group-test

Prüfe, dass die Sicherungsdatei vorhanden und lesbar ist. Die folgenden Änderungen werden in die vorhandene openclaw.json übernommen; bestehende Account-, Agent- und Provider-Einstellungen bleiben erhalten. Eine ausführliche Einordnung der Datei bietet Gateway-Konfiguration: openclaw.json verständlich erklärt.

Vollständige Gruppenregeln konfigurieren

Das folgende zusammenhängende JSON5-Beispiel lässt genau eine WhatsApp-Gruppe und einen Absender zu. Ersetze die Beispiel-JID 120363012345678901@g.us durch die protokollierte JID von Gruppe A. Ersetze +491701234567 durch die protokollierte ID von Person A. Übernimm keine Beispiel-ID unverändert.

{
  channels: {
    defaults: {
      contextVisibility: "allowlist",
    },
    whatsapp: {
      groupPolicy: "allowlist",
      groupAllowFrom: ["+491701234567"],
      groups: {
        "120363012345678901@g.us": {
          requireMention: true,
        },
      },
    },
  },
  session: {
    groupScope: "per-group",
  },
  messages: {
    groupChat: {
      visibleReplies: "automatic",
    },
  },
}

groups begrenzt die angenommenen Räume. groupAllowFrom begrenzt innerhalb dieser Räume die auslösenden Absender. requireMention verlangt in Gruppe A einen Ping. visibleReplies: "automatic" stellt normale finale Antworten im Gruppenraum zu.

Bei visibleReplies: "message_tool" wird normale Modellausgabe nicht automatisch als Gruppenantwort veröffentlicht; der Agent muss dafür das Message-Tool verwenden. Dieser Zustellmodus ändert weder Admission noch Mention-Gating oder Kontextsichtbarkeit.

session.groupScope: "per-group" legt für jeden Raum einen eigenen Sitzungsschlüssel an. Das ist eine Organisationsregel und keine Informationsflussgrenze: Laut Schema kann die Hauptsitzung diese Räume ambient beobachten. main führt Raumkontext direkt mit der Hauptsitzung zusammen und sollte nur für vollständig vertrauenswürdige Räume verwendet werden.

Konfiguration anwenden und verifizieren

Füge die gezeigten Felder in die vorhandenen gleichnamigen Objekte ein. Ersetze nicht die gesamte Datei, wenn sie weitere Channel-, Modell- oder Agent-Einstellungen enthält. Lass die Konfiguration vor dem Speichern durch den schemafähigen Konfigurationseditor prüfen, sofern du die Control UI verwendest.

Starte den Gateway nach dem Speichern über deinen üblichen Betriebsweg neu. Ist der Textbefehl in einem verbundenen Owner-Chat aktiviert, kannst du dort /restart senden. Warte anschließend, bis openclaw channels status --probe WhatsApp wieder als erreichbar meldet.

Lies danach die wirksamen Werte zurück:

openclaw config get channels.whatsapp.groups
openclaw config get channels.whatsapp.groupAllowFrom
openclaw config get channels.whatsapp.groupPolicy
openclaw config get channels.defaults.contextVisibility
openclaw config get session.groupScope
openclaw config get messages.groupChat.visibleReplies

Die Ausgabe muss die reale JID von Gruppe A, die ID von Person A, allowlist, per-group, automatic und contextVisibility: "allowlist" zeigen. Weicht ein Wert ab, beginne die Nachrichtentests noch nicht. Korrigiere den Merge oder einen überschreibenden Konfigurationsblock und starte den Gateway erneut.

Raumzulassung prüfen

Sende als Person A in Gruppe A einen harmlosen Kontroll-Ping wie @Agent antworte mit RAUM-OK. Verwende die echte WhatsApp-Erwähnung oder ein nachweislich passendes Mention-Muster. Erwartet werden eine sichtbare Antwort, ein gestarteter Agent-Lauf und ein Sitzungsschlüssel für Gruppe A.

Sende anschließend denselben Ping als Person A in Gruppe B. Eine sichtbare Antwort darf dort nicht erscheinen. Im Log muss die Nachricht als ungelistete WhatsApp-Gruppe beziehungsweise als vor dem Agent-Lauf verworfen erkennbar sein. Für Gruppe B darf kein neuer Agent-Turn entstehen.

Fehlt bereits die Antwort in Gruppe A, sagt der Negativtest nichts aus. Vergleiche die protokollierte Gruppen-JID mit dem Schlüssel unter channels.whatsapp.groups, prüfe den Verbindungsstatus und kontrolliere die Mention-Erkennung. Wiederhole danach den Kontroll-Ping.

Absenderzulassung prüfen

Sende in Gruppe A erneut den funktionierenden Kontroll-Ping als Person A. Damit bestätigst du, dass Raum, Mention-Erkennung und Zustellung weiterhin funktionieren.

Sende denselben Ping danach als Person B. Erwartet werden keine sichtbare Antwort und kein Agent-Lauf. Der Logpfad muss zeigen, dass die Nachricht an der Absenderzulassung endet, bevor das Modell ausgeführt wird.

Falls Person B einen Lauf auslöst, vergleiche ihre protokollierte Absender-ID mit groupAllowFrom und vorhandenen Freigaben. Prüfe auch, ob ein breiter Eintrag wie "*" oder eine geerbte Absenderfreigabe wirksam ist. Nach der Korrektur muss Person A weiterhin erfolgreich pingen können.

Mention-Gating prüfen

Sende als Person A in Gruppe A einen Kontroll-Ping mit Erwähnung. Erwartet werden eine sichtbare Antwort, ein Agent-Lauf und derselbe gruppenspezifische Sitzungsschlüssel wie zuvor.

Sende danach MENTION-MARKER-27 bitte antworten ohne Erwähnung, Zitat oder sonstigen dokumentierten Ping. Bei aktivem requireMention darf dadurch kein normaler Agent-Lauf entstehen. Die WhatsApp-Dokumentation beschreibt solche zugelassenen Nachrichten als Kontext, der für eine spätere Aktivierung vorgemerkt werden kann.

Prüfe im Log, ob die Nachricht das Mention-Gate verfehlt hat. Ein reines Ausbleiben der Antwort könnte ebenso auf eine falsche JID, einen Zustellfehler oder fehlende Modellausgabe zurückgehen.

Antwortet der Agent trotzdem, kontrolliere echte @-Mentions, konfigurierte mentionPatterns, die E.164-Ziffern des Bots im Nachrichtentext und zitierte Antworten auf Bot-Nachrichten. Außerdem kann /activation den Aktivierungsmodus gruppenspezifisch überschreiben. Setze den Gruppenmodus für den Test wieder auf Mention-Verhalten und wiederhole Kontroll- und Negativanfrage.

Zustellung von Admission unterscheiden

Ein zugelassener Ping kann einen Agent-Lauf erzeugen, ohne dass eine Nachricht sichtbar ankommt. Prüfe deshalb nach jedem Kontroll-Ping sowohl die Sitzung als auch den ausgehenden Zustellpfad.

Existiert ein Agent-Turn, aber keine Gruppenantwort, sind Raum- und Absenderzulassung bereits passiert. Prüfe dann messages.groupChat.visibleReplies, ausgehende WhatsApp-Logs und den Channel-Status. In diesem Tutorial muss der Readback automatic zeigen.

Existiert kein Agent-Turn, liegt der Fehler früher im Ablauf. Prüfe Gruppen-JID, Absender-ID, groupPolicy, Gruppenliste und Mention-Erkennung. Diese Trennung verhindert, dass ein Zustellproblem irrtümlich als funktionierende Zugriffskontrolle gilt.

Sitzungen und Informationsfluss getrennt beobachten

Öffne nach einem erfolgreichen Gruppen-Ping den zugehörigen Sitzungseintrag. Bei per-group muss der Raum einen gruppenspezifischen Schlüssel nach dem dokumentierten Muster agent:<agentId>:whatsapp:group:<jid> verwenden. Vergleiche ihn mit der persönlichen Hauptsitzung.

Unterschiedliche Schlüssel zeigen, dass OpenClaw die Unterhaltungen als getrennte Sitzungen organisiert. Sie sagen nicht aus, dass Gruppeninhalt die Hauptsitzung niemals erreicht. Die Hauptsitzung kann Räume bei per-group ambient beobachten. Bei main wird Raumkontext direkt mit ihr zusammengeführt.

Prüfe Ambient-Watching deshalb separat in der Hauptsitzung und anhand des tatsächlich ergänzten Eingabekontexts. Ein späterer Antwortsatz des Modells reicht dafür nicht aus: Das Modell kann Inhalte aus anderen Quellen wiedergeben oder vorhandenen Kontext nicht erwähnen.

Ergänzten Zitat- und Verlaufskontext prüfen

Lass Person B in Gruppe A die harmlose Nachricht ZITAT-MARKER-41 schreiben. Diese Nachricht darf keinen Agent-Lauf auslösen. Danach zitiert Person A genau diese Nachricht und ergänzt eine gültige Erwähnung mit der Frage Welcher Zusatzkontext wurde dieser Anfrage beigefügt?.

Prüfe den protokollierten oder in der Sitzungsansicht dargestellten Modelleingang. Bei channels.defaults.contextVisibility: "allowlist" darf der abgerufene Zitatinhalt von Person B nicht als erlaubter ergänzter Kontext enthalten sein. Die Anfrage von Person A und ihre eigenen zulässigen Inhalte können weiterhin erscheinen.

Kann deine Beobachtungsoberfläche den Modelleingang nicht zeigen, ist diese Kontextprobe dort nicht auswertbar. Eine sichtbare Antwort ohne Marker bestätigt die Filterung nicht. Ebenso widerlegt eine zufällige Marker-Ausgabe allein keine bestimmte Kontrollstufe; ordne den dokumentierten Transportweg und den tatsächlich inspizierten Eingabekontext zu.

Nutze ausschließlich künstliche Marker ohne Personenbezug oder Geheimnisse. Wiederhole den Ablauf bei Bedarf in zwei aufeinanderfolgenden Läufen und protokolliere nur das beobachtete Verhalten. Daraus lässt sich keine feste Lebensdauer, Leerung oder Nichtwiederholung eines internen Kontextpuffers ableiten.

Rollback

Wenn die Tests scheitern oder du den Versuch beenden möchtest, stelle die gesicherte Datei wieder her:

cp ~/.openclaw/openclaw.json.before-group-test ~/.openclaw/openclaw.json

Starte den Gateway anschließend über denselben Betriebsweg neu. Prüfe mit openclaw channels status --probe, dass WhatsApp wieder verbunden ist, und lies die betroffenen Konfigurationspfade erneut aus. Bewahre die Sicherung auf, bis die vorherige Funktion vollständig geprüft ist.

Kernpunkte

Eine belastbare Gruppenfreigabe benötigt eine funktionierende Kontrollanfrage vor jedem Negativtest. Raum, Absender und Mention-Gate werden anhand von Logs und Agent-Läufen geprüft; sichtbares Schweigen reicht nicht aus.

per-group trennt Sitzungsschlüssel, schafft aber keine Informationsflussgrenze. Die Hauptsitzung kann Gruppen ambient beobachten. main führt Raumkontext direkt zusammen und eignet sich daher nur für vollständig vertrauenswürdige Räume.

channels.defaults.contextVisibility begrenzt ergänzten Zitat-, Thread- und Verlaufskontext unabhängig von der Auslöseberechtigung. Sitzungsschlüssel, Trigger, Modelleingang und sichtbare Ausgabe müssen getrennt beobachtet werden. Kein einzelner Marker-Treffer oder -Nichttreffer kann diese Ebenen gemeinsam nachweisen.