#6265: feat(whatsapp): add pairing owner notification
channel: whatsapp-web
Cluster:
WhatsApp Pairing Enhancements
## 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
#11249: fix(whatsapp): prevent pairing-mode auto-replies to unknown DMs
by liuxiaopai-ai · 2026-02-07
84.3%
#6588: feat(channels): add 'confirming' dmPolicy mode for owner-approved r...
by zote · 2026-02-01
82.1%
#6567: fix: include paired users in WhatsApp group sender allowlist
by giannisanni · 2026-02-01
81.6%
#17882: fix: drop WhatsApp pairing reply for unconfigured accounts
by adit-negi · 2026-02-16
81.5%
#14789: fix: per-account dmPolicy ignored in checkInboundAccessControl
by croll83 · 2026-02-12
79.4%
#7911: Unapproved users receive pairing codes on every /start message befo...
by crazypeace · 2026-02-03
77.3%
#11611: feat: separate group-level allowlist from sender-level command auth...
by thisnick · 2026-02-08
76.1%
#13696: feat(cli): add --code option for WhatsApp pairing code login
by asklee-klawd · 2026-02-10
75.9%
#21889: fix(whatsapp): include outbound DMs in agent context for allowed co...
by mactsk · 2026-02-20
75.1%
#13285: feat(pairing): add pairingAnonymous option to hide platform branding
by thebtf · 2026-02-10
75.0%