← Back to PRs

#17882: fix: drop WhatsApp pairing reply for unconfigured accounts

by adit-negi open 2026-02-16 08:27 View on GitHub →
channel: whatsapp-web size: XS
## 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