Anyone can create a pending pairing request just by messaging your number, so "approve the pending one" is exactly what a prompt-injected request would look like — approving always requires the specific code, typed by you, outside the message channel. Two practical constraints: only one client can hold the WhatsApp link at a time, and replies arrive from your personal number, so use a dedicated number if you want a distinct identity.
An MCP server that connects to WhatsApp as a linked device through Baileys — the same protocol WhatsApp Web uses — and exposes the conversation to Claude Code as a channel. Incoming messages reach your session, and Claude replies from your own number, so recipients see a normal chat. Messages travel directly between WhatsApp and your machine; there is no third-party server in between. Once paired it keeps working with your phone off.
- Two-way messaging with long replies chunked to WhatsApp's limits, or sent as a document attachment past a threshold you configure — `reply`, `react`, `edit_message`, `status`
- Media in both directions: photos, voice notes, video, documents and stickers, with attachments downloadable into the session — `download_attachment`
- Access control that gates every inbound message: pairing codes, allowlists and per-group policies, so strangers never reach your session — managed from a terminal, deliberately not as an MCP tool, because anyone can create a pending pairing just by messaging you
- Context recovery after a restart: recent two-way conversation per chat, unreplied counts and open tasks replayed so a fresh session resumes mid-flight work — `catch_up`, `unreplied`, `list_groups`
- A poll-based path for non-Claude-Code clients — `wait_for_messages` parks for up to 40 seconds waiting for the next message, and every tool result carries an unreplied count
- Per-group personalities, each group carrying its own config file with a personality and conversation memory, and a cron section for recurring server-side tasks
- Permission relay: approve or deny Claude's tool requests from WhatsApp with a 👍 or 👎 reaction
- Local voice transcription of incoming voice notes through mlx-whisper; without the script they arrive as plain attachments
- A single-connection guard — a second server stays up and serves one `whatsapp_unavailable` tool naming the process that holds the link, rather than fighting for it
A regular WhatsApp account — no Business API, no Meta developer account, no API key. Install through the Claude Code plugin marketplace, then pair with a code entered under WhatsApp > Settings > Linked Devices > Link with phone number instead. The `--dangerously-load-development-channels` flag is what registers it as a channel so an inbound message wakes the session; without it the tools load but nothing wakes anything. Other clients run the same stdio server with Bun — `bun run --cwd /absolute/path/to/whatsapp-channel start` — and need generous timeouts, since `wait_for_messages` parks for up to 40 seconds; the README suggests a 30-second startup timeout and a 120-second tool timeout for Codex CLI. Runtime state — auth, allowlists, group configs, inbox — lives under `~/.whatsapp-channel/`. Only one client at a time can hold the connection, because WhatsApp allows one linked-device session per account. Voice transcription is optional and needs ffmpeg plus mlx-whisper on Apple Silicon. The package is `claude-channel-whatsapp` 0.1.0.
One command — claude plugin marketplace add Rich627/whatsapp-claude-plugin