#17882: fix: drop WhatsApp pairing reply for unconfigured accounts
channel: whatsapp-web
size: XS
Cluster:
WhatsApp Pairing Enhancements
## Summary
- When WhatsApp pairing is not configured, the bot was replying to every unknown sender with pairing instructions (phone number, pairing code, CLI command). This leaks internal info and is noisy.
- Multiple of my friends were confused on getting a generic error msg while texting a friend.
```
OpenClaw: access not configured.
Your WhatsApp phone number: +xxxxx
Pairing code: xxxx
Ask the bot owner to approve with:
openclaw pairing approve whatsapp xxxx
```
- The pairing request is still recorded so the bot owner can see and approve pending requests via `openclaw pairing approve`.
- Removed the `sendMessage` call and unused `buildPairingReply` import from the WhatsApp access control path.
## Test plan
- [x] Unit tests pass (`pnpm vitest run src/web/inbound/access-control.test.ts` — 4/4)
- [ ] CI checks
AI-assisted (Claude). Lightly tested (unit tests pass).
🤖 Generated with [Claude Code](https://claude.com/claude-code)
<!-- greptile_comment -->
<h3>Greptile Summary</h3>
This PR removes the WhatsApp pairing reply message that was sent to unknown senders when pairing is not configured. Previously, the bot would reply with internal details (phone number, pairing code, CLI command) to every unauthorized sender, leaking information and confusing recipients. The pairing request is still silently recorded so the bot owner can approve it via `openclaw pairing approve`.
- Removed `sendMessage` call and `buildPairingReply` import from the WhatsApp access control path in `access-control.ts`
- Removed unused `code` destructuring from `upsertChannelPairingRequest` result
- Updated 4 test files to assert `sendMessage` is **not** called instead of being called with pairing text
- Minor cleanup opportunity: `sock` and `remoteJid` params are now unused in the function signature
<h3>Confidence Score: 5/5</h3>
- This PR is safe to merge — it removes outbound behavior (sending messages) without affecting inbound message processing or pairing request recording.
- The change is a straightforward removal of a `sendMessage` call and its associated import. The pairing request is still upserted and logged, so the approval workflow remains intact. Tests are updated consistently across all 4 files. No logic changes to the access control decision itself.
- No files require special attention.
<sub>Last reviewed commit: 743a883</sub>
<!-- greptile_other_comments_section -->
<!-- /greptile_comment -->
Most Similar PRs
#11249: fix(whatsapp): prevent pairing-mode auto-replies to unknown DMs
by liuxiaopai-ai · 2026-02-07
88.1%
#6265: feat(whatsapp): add pairing owner notification
by zote · 2026-02-01
81.5%
#6567: fix: include paired users in WhatsApp group sender allowlist
by giannisanni · 2026-02-01
80.9%
#14789: fix: per-account dmPolicy ignored in checkInboundAccessControl
by croll83 · 2026-02-12
80.2%
#13696: feat(cli): add --code option for WhatsApp pairing code login
by asklee-klawd · 2026-02-10
80.0%
#22636: fix(whatsapp): skip pairing store merge when dmPolicy is allowlist (#…
by anillBhoi · 2026-02-21
78.8%
#16655: fix(whatsapp): resolve reply-to sender E.164 for LID JIDs (have bot...
by mascarenhas · 2026-02-15
78.0%
#13285: feat(pairing): add pairingAnonymous option to hide platform branding
by thebtf · 2026-02-10
77.6%
#6588: feat(channels): add 'confirming' dmPolicy mode for owner-approved r...
by zote · 2026-02-01
77.0%
#11484: feat: add WhatsApp pairing code login as alternative to QR scanning
by BlackScript · 2026-02-07
76.9%