Bug type

Behavior bug (incorrect output/state without crash)

Summary

With groupPolicy: "allowlist" and zero groups in the allowlist, the agent processed a group message and sent a reply ("D'accord, je vous laisse avancer tranquillement ! 👋") directly into a private WhatsApp family group ([email protected] ⁠). The group was never allowlisted. Text replies in DM sessions work correctly — only group gating is broken.

Steps to reproduce

1. Configure OpenClaw 2026.3.13 with WhatsApp channel:

   {
     "channels": {
       "whatsapp": {
         "enabled": true,
         "dmPolicy": "allowlist",
         "selfChatMode": true,
         "allowFrom": ["+33XXXXX", "+3367XXXX", "+336XXXXXXX"],
         "groupPolicy": "allowlist",
         "debounceMs": 0,
         "mediaMaxMb": 50
       }
     }
   }

   Note: No groupsAllowFrom or equivalent field is set. No groups are allowlisted.

2. Have multiple messages arrive in a WhatsApp group (e.g., family group chat) where the owner's number is a participant.

3. Observe the gateway logs: applyGroupGating processes the messages with wasMentioned: false, logging them as "group mention debug".

4. After several messages arrive in quick succession, one message is forwarded to the agent as an inbound message: "Inbound message [email protected] ⁠-> +336XXXXXX (group, 622 chars)".

5. The agent processes the message and sends a reply TO the group: "to": "[email protected] ⁠".

Expected behavior

With groupPolicy: "allowlist" and no groups in the allowlist, ALL group messages should be silently dropped. No inbound processing, no agent turn, and no outbound reply should ever be sent to any group chat. This is the behavior implied by the config — an empty allowlist means "block everything."

Actual behavior

1. The applyGroupGating function logged group messages as "group mention debug" with wasMentioned: false (correctly identifying them as group messages).
2. Despite this, after multiple messages arrived, one was forwarded to the agent as an inbound message (622 chars — possibly batched/accumulated).
3. The agent processed it and sent a reply directly into the group chat.

Gateway log confirming the outbound message to the group:

{
  "correlationId": "3A056369862E1B4BFBC2",
  "to": "[email protected] ⁠",
  "from": "+3368XXXX",
  "text": "D'accord, je vous laisse avancer tranquillement ! 👋",
  "durationMs": 689
}

Log entry: "auto-reply sent (text)" at 2026-03-22T15:23:20.113Z via deliverWebReply.

OpenClaw version

2026.3.13 (61d171a)

Operating system

Linux 6.8.0-106-generic (x64) — Ubuntu 24.04

Install method

npm global

Model

anthropic/claude-opus-4-6

Provider / routing chain

openclaw -> anthropic (direct, token auth)

Additional provider/model setup details

Standard Anthropic token auth via auth.profiles.anthropic:default. No routing proxies. selfChatMode: true is enabled — the owner chats with the agent in their own WhatsApp self-chat. The group where the leak occurred contains numbers that are in the DM allowFrom list (+33XXXXXXX), which may be relevant to the bypass.

Logs, screenshots, and evidence

**Group messages correctly gated (debug log):**

"group mention debug" {
  "conversationId": "[email protected] ⁠",
  "wasMentioned": false,
  "body": "Je suis au lounge de Marseille"
}

Multiple messages went through this debug path: "Ok cool bon trajet", "vous êtes en route?", "Non pas encore", "mais ??".

**Message forwarded to agent despite gating:**

"Inbound message [email protected] -> +33687XXXXX (group, 622 chars)"


**Reply sent TO the group (the bug):**

{
  "module": "web-auto-reply",
  "correlationId": "3A056369862E1B4BFBC2",
  "to": "[email protected] ⁠",
  "from": "+336XXXXX",
  "text": "D'accord, je vous laisse avancer tranquillement ! 👋",
  "mediaUrl": null,
  "durationMs": 689
}

Timestamp: `2026-03-22T15:23:20.113Z`

Impact and severity

• Affected: Any WhatsApp group where the owner is a participant, even with groupPolicy: "allowlist" and no groups allowlisted
• Severity: High — privacy breach. The agent spoke in a private family group that was never authorized. Agent responses could leak context from the owner's private DM session into group chats.
• Frequency: Observed once, triggered after multiple group messages arrived in quick succession (~5 messages over 40 minutes). May be timing-dependent or related to message batching.
• Consequence: Unauthorized message sent to a private group. Loss of trust in the group gating mechanism.

Additional information

Possible contributing factors:

1. selfChatMode: true may interact with group messages in unexpected ways — the group contains +3363XXXXX which is in the DM allowFrom list.
2. Message accumulation: The first 4 group messages were correctly gated (debug only). The 5th triggered a 622-char inbound message. This may indicate a race condition or batching issue in applyGroupGating.
3. Missing outbound guard: Even if a group message passes inbound gating, the outbound delivery path (deliverWebReply) should independently verify the target is not a non-allowlisted group before sending.

Suggested fix: Add a double-check on the outbound path — deliverWebReply should refuse to send to group IDs (*@g.us) that are not in the allowlist, regardless of how the inbound message was classified.