openclaw - 💡(How to fix) Fix [Bug]: WhatsApp dmPolicy allowlist bypassed during gateway reconnection [1 comments, 2 participants]

Official PRs (…)
ON THIS PAGE

Recommended Tools

×6

Utilities matched from this issue’s tags and category — try them while you read without losing context.

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

Helpful · Quick feedback

Loading…
GitHub stats
openclaw/openclaw#74218Fetched 2026-04-30 06:27:10
View on GitHub
Comments
1
Participants
2
Timeline
4
Reactions
2
Timeline (top)
closed ×1commented ×1cross-referenced ×1labeled ×1

WhatsApp dmPolicy allowlist is bypassed during gateway reconnection, allowing queued messages from non-allowed contacts to reach the agent.

Root Cause

WhatsApp dmPolicy allowlist is bypassed during gateway reconnection, allowing queued messages from non-allowed contacts to reach the agent.

RAW_BUFFERClick to expand / collapse

Bug type

Regression (worked before, now fails)

Beta release blocker

No

Summary

WhatsApp dmPolicy allowlist is bypassed during gateway reconnection, allowing queued messages from non-allowed contacts to reach the agent.

Steps to reproduce

  1. Configure channels.whatsapp.dmPolicy to "allowlist" with only owner's number in allowFrom (e.g., +447597219254)
  2. Have a non-allowed contact send a WhatsApp message to the linked number
  3. Trigger a WhatsApp gateway disconnection (status 408) — e.g., network blip
  4. When gateway reconnects, the queued message from the non-allowed contact is delivered to the agent despite not being in allowFrom

Expected behavior

Only numbers explicitly listed in allowFrom should be able to DM the agent. Queued messages during reconnection should still be subject to the same allowlist check and rejected if the sender is not in allowFrom.

Actual behavior

Messages from contacts not in allowFrom are delivered to the agent after a gateway reconnection (408 status), bypassing dmPolicy allowlist. The owner received an unwanted reply from a non-allowed contact (Robert Goldfinch, +447767057318) who was not in allowFrom.

OpenClaw version

2026.4.25

Operating system

Ubuntu 26.04

Install method

No response

Model

minimax-portal/MiniMax-M2.7

Provider / routing chain

openclaw -> WhatsApp gateway (Baileys) -> minimax

Additional provider/model setup details

No response

Logs, screenshots, and evidence

Impact and severity

Affected: WhatsApp channel users with dmPolicy=allowlist Severity: Medium-High (privacy violation — contacts not in allowlist can reach the agent) Frequency: Intermittent — only occurs during gateway reconnection (408) Consequence: Non-allowed contacts' messages reach the agent, exposing private info to unintended recipients

Additional information

No response

extent analysis

TL;DR

The WhatsApp dmPolicy allowlist is bypassed during gateway reconnection, suggesting a need to reapply the allowlist check after reconnection.

Guidance

  • Review the gateway reconnection logic to ensure the dmPolicy allowlist is reapplied after a successful reconnection.
  • Verify that the allowlist configuration is correctly persisted across gateway disconnections and reconnections.
  • Check the Baileys WhatsApp gateway implementation to see if it provides any hooks or callbacks for reapplying policy checks after a reconnection.
  • Consider implementing a temporary workaround to clear queued messages from non-allowed contacts during gateway reconnection.

Example

No code example is provided due to the lack of specific implementation details.

Notes

The root cause of the issue is likely related to the handling of queued messages during gateway reconnection, and the fix will depend on the specific implementation of the OpenClaw and Baileys WhatsApp gateway.

Recommendation

Apply a workaround to clear queued messages from non-allowed contacts during gateway reconnection, as the root cause is likely related to the reconnection logic and a full fix may require modifications to the underlying implementation.

Vote matrix · Quick signals

Works
Did the solution work? Tap to confirm.
Easy Fix
Was it a quick fix?
Time Saver
Did it save you time?
Blocking
Was it severely blocking?
Common Issue
Are others likely hitting this too?
Flaky / Intermittent
Is it intermittent?
Verified / Reproducible
Can you reproduce it reliably?
Loading…

FAQ

Expected behavior

Only numbers explicitly listed in allowFrom should be able to DM the agent. Queued messages during reconnection should still be subject to the same allowlist check and rejected if the sender is not in allowFrom.

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

Back to top recommendations

TRENDING

openclaw - 💡(How to fix) Fix [Bug]: WhatsApp dmPolicy allowlist bypassed during gateway reconnection [1 comments, 2 participants]