#11249: fix(whatsapp): prevent pairing-mode auto-replies to unknown DMs
channel: whatsapp-web
stale
Cluster:
WhatsApp Pairing Enhancements
## Summary
Fix WhatsApp pairing-mode behavior that replies with a pairing code to *every* unknown DM.
On WhatsApp this is especially problematic because unknown senders are often real-world contacts (friends/family). Auto-replying with pairing codes is:
- **Embarrassing** (looks like the bot is mass-messaging the owner's contacts)
- **A social-engineering risk** (recipients can forward codes to trick the owner into approving)
## Root Cause
would, under , automatically send a pairing reply to any DM sender not in .
## Fix
For WhatsApp pairing mode:
- Still **records** a pairing request via (so the owner can review/approve via CLI)
- **Stops auto-replying** with pairing codes to unknown senders
This keeps secure defaults while preserving the owner-driven approval flow.
## Tests
Updated to assert:
- Pairing requests are recorded
- No pairing auto-reply is sent ( not called)
Closes #834
<!-- greptile_comment -->
<h2>Greptile Overview</h2>
<h3>Greptile Summary</h3>
This PR changes WhatsApp inbound DM access control in pairing mode to stop auto-replying pairing codes to unknown senders. Instead, it always records a pairing request in the pairing store and logs the event, including for historical messages where replies were already suppressed. Tests were updated to assert that pairing requests are recorded and that `sock.sendMessage` is not called for unknown DMs.
<h3>Confidence Score: 4/5</h3>
- This PR is close to safe to merge; the behavior change is straightforward but needs a small correctness fix around pairing-store capacity handling.
- Main logic change removes proactive WhatsApp pairing replies and updates tests accordingly. The remaining concern is that the code now unconditionally logs/assumes a pairing request was recorded, but `upsertChannelPairingRequest` can return `{code:"", created:false}` when the store is at capacity, meaning no new request is recorded and the owner-driven approval flow may break silently.
- src/web/inbound/access-control.ts
<!-- greptile_other_comments_section -->
<sub>(4/5) You can add custom instructions or style guidelines for the agent [here](https://app.greptile.com/review/github)!</sub>
<!-- /greptile_comment -->
Most Similar PRs
#17882: fix: drop WhatsApp pairing reply for unconfigured accounts
by adit-negi · 2026-02-16
88.1%
#6265: feat(whatsapp): add pairing owner notification
by zote · 2026-02-01
84.3%
#14789: fix: per-account dmPolicy ignored in checkInboundAccessControl
by croll83 · 2026-02-12
83.8%
#22636: fix(whatsapp): skip pairing store merge when dmPolicy is allowlist (#…
by anillBhoi · 2026-02-21
82.9%
#6567: fix: include paired users in WhatsApp group sender allowlist
by giannisanni · 2026-02-01
80.8%
#7911: Unapproved users receive pairing codes on every /start message befo...
by crazypeace · 2026-02-03
80.5%
#13696: feat(cli): add --code option for WhatsApp pairing code login
by asklee-klawd · 2026-02-10
79.4%
#21889: fix(whatsapp): include outbound DMs in agent context for allowed co...
by mactsk · 2026-02-20
79.3%
#8985: fix(telegram): preserve forum topic context for pairing auto-replies
by lailoo · 2026-02-04
77.6%
#22106: fix(whatsapp): honor selfChatMode override for group mentions
by sportclaw · 2026-02-20
77.5%