openclaw - ✅(Solved) Fix [Bug]: 26982 is back in version 2026.4.5 dmPolicy 'allowlist' still sends pairing codes to unknown senders (personal WhatsApp) #26982 [1 pull requests, 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#63366Fetched 2026-04-09 07:54:42
View on GitHub
Comments
1
Participants
2
Timeline
4
Reactions
0
Author
Participants
Timeline (top)
labeled ×2commented ×1cross-referenced ×1

Same WhatsApp bug as reported on closed issue 26982, pairing code messages are being sent to contacts not in the dm allow list.

Root Cause

Same WhatsApp bug as reported on closed issue 26982, pairing code messages are being sent to contacts not in the dm allow list.

Fix Action

Fixed

PR fix notes

PR #63466: fix(whatsapp): inherit channel dmPolicy when account omits dmPolicy (#63366)

Description (problem / solution / changelog)

Summary

  • Problem: With channels.whatsapp.dmPolicy="allowlist" and a multi-account setup, an accounts.* entry that only set allowFrom (and omitted dmPolicy) still received Zod’s channel default dmPolicy: "pairing" on parse. resolveMergedAccountConfig shallow-merges account over channel, so that injected value overrode the channel allowlist and unknown senders could get pairing challenges.
  • Why it matters: Operators expect allowlist mode to block or silently ignore unknown senders, not send pairing codes (regression described in #63366).
  • What changed: WhatsAppAccountSchema overrides dmPolicy with DmPolicySchema.optional() (no default), so omitted account-level dmPolicy stays unset and merge preserves the channel policy.
  • What did NOT change: Channel-level defaults, explicit per-account dmPolicy, or WhatsApp inbound access logic (only config parse/merge behavior).

Change Type

  • Bug fix

Scope

  • Integrations

Linked Issue/PR

  • Closes #63366
  • Related #63366
  • This PR fixes a bug or regression

Root Cause

  • Root cause: Zod .default("pairing") on the shared WhatsApp shape was applied to nested accounts.* objects. Parsed account objects then overwrote channel dmPolicy during merge.
  • Missing detection / guardrail: Unit tests for access control used raw mocked config and did not exercise parsed config defaults.
  • Contributing context (if known): N/A

Regression Test Plan

  • Coverage level that should have caught this:
    • Unit test
  • Target test or file: src/config/zod-schema.providers-whatsapp.test.ts
  • Scenario the test should lock in: Validated config must not set accounts.*.dmPolicy to pairing when the account block omits dmPolicy and the channel sets allowlist.
  • Why this is the smallest reliable guardrail: Asserts the exact parse output that previously corrupted merge.
  • Existing test that already covers this (if any): Inbound tests mock loadConfig without Zod.
  • If no new test is added, why not: N/A (tests added).

User-visible / Behavior Changes

  • Multi-account WhatsApp configs with channel dmPolicy=allowlist and account entries that omit dmPolicy now inherit the channel policy after merge; pairing challenges are no longer sent to unknown senders in that configuration.

Diagram

N/A

Security Impact

  • New permissions/capabilities? (No)
  • Secrets/tokens handling changed? (No)
  • New/changed network calls? (No)
  • Command/tool execution surface changed? (No)
  • Data access scope changed? (No)

Repro + Verification

Environment

  • OS: macOS (dev)
  • Validation: pnpm check, pnpm test src/config/zod-schema.providers-whatsapp.test.ts, pnpm config:docs:check

Steps

  1. Configure channels.whatsapp.dmPolicy: "allowlist" with allowFrom and an accounts.work entry that only lists allowFrom (no dmPolicy).
  2. Load merged account config / run gateway with that config.

Expected

  • Effective dmPolicy for the account remains allowlist; unknown senders do not get pairing replies.

Actual (before fix)

  • Parsed account carried dmPolicy: "pairing", overriding channel allowlist.

Evidence

  • Failing test/log before + passing after (new unit test documents expected parse shape)

Human Verification

  • Verified scenarios: pnpm check, targeted Vitest for new file, pnpm config:docs:check.
  • Edge cases checked: Explicit accounts.*.dmPolicy: "pairing" still parses.
  • What I did not verify: End-to-end WhatsApp gateway against a live account (config-level fix only).

Review Conversations

  • I replied to or resolved every bot review conversation I addressed in this PR.
  • I left unresolved only the conversations that still need reviewer or maintainer judgment.

Compatibility / Migration

  • Backward compatible? (Yes)
  • Config/env changes? (No)
  • Migration needed? (No)

Risks and Mitigations

  • None: Omitted account dmPolicy now follows channel merge semantics; explicit account dmPolicy is unchanged.

Made with Cursor

Changed files

  • CHANGELOG.md (modified, +1/-0)
  • src/channels/plugins/account-helpers.test.ts (modified, +43/-0)
  • src/channels/plugins/account-helpers.ts (modified, +16/-2)
  • src/config/zod-schema.providers-whatsapp.test.ts (added, +63/-0)
  • src/config/zod-schema.providers-whatsapp.ts (modified, +6/-0)
RAW_BUFFERClick to expand / collapse

Bug type

Regression (worked before, now fails)

Beta release blocker

No

Summary

Same WhatsApp bug as reported on closed issue 26982, pairing code messages are being sent to contacts not in the dm allow list.

Steps to reproduce

When channels.whatsapp.dmPolicy is set to "allowlist" with a specific allowFrom list, unknown senders who message the

Expected behavior

Messages from non-allowlisted senders should be silently dropped.

Actual behavior

WhatsApp number still receive an auto-reply with a pairing code.

OpenClaw: access not configured. Your WhatsApp phone number: +58424XXXXXXX Pairing code: XXXXXXXX Ask the bot owner to approve with: openclaw pairing approve whatsapp XXXXXXXX

OpenClaw version

2026.4.5

Operating system

Ubuntu 24.04.4 LTS

Install method

Curl

Model

Kimi2.5

Provider / routing chain

Openclaw/aws

Additional provider/model setup details

No response

Logs, screenshots, and evidence

Impact and severity

No response

Additional information

No response

extent analysis

TL;DR

The issue can be fixed by ensuring the channels.whatsapp.dmPolicy is correctly configured to silently drop messages from non-allowlisted senders.

Guidance

  • Verify that the allowFrom list in the channels.whatsapp.dmPolicy configuration is correctly set to only include the desired contacts.
  • Check the OpenClaw documentation to ensure that the dmPolicy configuration is properly formatted and applied.
  • Investigate if there are any other configurations or settings that may be overriding the dmPolicy setting.
  • Test the configuration with a known non-allowlisted sender to verify that messages are being silently dropped as expected.

Example

No code snippet is provided as the issue does not contain sufficient information about the configuration files or code.

Notes

The issue may be related to a misconfiguration of the dmPolicy setting or an override by another setting. Further investigation is needed to determine the root cause.

Recommendation

Apply workaround: Verify and correct the channels.whatsapp.dmPolicy configuration to ensure it is properly set to silently drop messages from non-allowlisted senders. This is recommended as the issue is likely related to a configuration error rather than a version issue.

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

Messages from non-allowlisted senders should be silently dropped.

Still need to ship something?

×6

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

Back to top recommendations

TRENDING