← Back to PRs

#6265: feat(whatsapp): add pairing owner notification

by zote open 2026-02-01 13:30 View on GitHub →
channel: whatsapp-web
## Summary When `dmPolicy` is `pairing`, owners can now be notified when someone requests to pair with the bot. This allows owners to be aware of incoming requests without having to manually check the CLI. ## Configuration ```json { "channels": { "whatsapp": { "dmPolicy": "pairing", "pairing": { "notifyOwner": true, "ownerChat": "554788703000@s.whatsapp.net", "includeMessage": true } } } } ``` ## Notification Format ``` 📩 *New pairing request* From: João (+5547999999999) Code: `ABC123` 📝 Message: "Oi, quanto custa a consultoria?" To approve: `openclaw pairing approve whatsapp ABC123` ``` ## Changes - Added `WhatsAppPairingConfig` type with `notifyOwner`, `ownerChat`, and `includeMessage` options - Added Zod schema validation (ownerChat required when notifyOwner is true) - Modified `checkInboundAccessControl` to send notifications when pairing requests are created - Added `messageBody` parameter to include original message in notifications ## Testing - Existing access-control tests pass - TypeScript compiles without errors Fixes #6261 <!-- greptile_comment --> <h2>Greptile Overview</h2> <h3>Greptile Summary</h3> This PR adds a WhatsApp pairing owner-notification feature gated by new `channels.whatsapp.pairing` config (and per-account overrides), validates it via Zod, threads message text into inbound access control, and sends a formatted notification to an owner chat when a new pairing request is created. The changes integrate into the existing WhatsApp web inbound pipeline by extracting the inbound text early in `monitorWebInbox()` and passing it into `checkInboundAccessControl()`, which already creates pairing requests and replies to the requester when `dmPolicy` is `pairing`. <h3>Confidence Score: 3/5</h3> - Reasonably safe to merge, but has a functional config bug affecting multi-account dmPolicy behavior. - The feature is self-contained and guarded by config, and notification send failures are handled. However, `checkInboundAccessControl` currently ignores per-account dmPolicy despite resolving it, which can lead to incorrect access behavior in multi-account setups (and makes the new per-account pairing config feel inconsistent). - src/web/inbound/access-control.ts <!-- greptile_other_comments_section --> <sub>(3/5) Reply to the agent's comments like "Can you suggest a fix for this @greptileai?" or ask follow-up questions!</sub> **Context used:** - Context from `dashboard` - CLAUDE.md ([source](https://app.greptile.com/review/custom-context?memory=fd949e91-5c3a-4ab5-90a1-cbe184fd6ce8)) - Context from `dashboard` - AGENTS.md ([source](https://app.greptile.com/review/custom-context?memory=0d0c8278-ef8e-4d6c-ab21-f5527e322f13)) <!-- /greptile_comment -->

Most Similar PRs