| name | configure |
| description | Set up the WhatsApp channel — save API credentials and review access policy. Use when the user pastes WhatsApp API credentials, asks to configure WhatsApp, asks "how do I set this up" or "who can reach me," or wants to check channel status. |
| user-invocable | true |
| allowed-tools | ["Read","Write","Bash(ls *)","Bash(mkdir *)"] |
/whatsapp:configure — WhatsApp Channel Setup
Writes the API credentials to ~/.claude/channels/whatsapp/.env and orients
the user on access policy. The server reads both files at boot.
Arguments passed: $ARGUMENTS
Dispatch on arguments
No args — status and guidance
Read both state files and give the user a complete picture:
-
Credentials — check ~/.claude/channels/whatsapp/.env for the four
required variables. Show set/not-set for each:
WHATSAPP_ACCESS_TOKEN — show first 10 chars masked (EAABwz...)
WHATSAPP_PHONE_NUMBER_ID — show full (not a secret)
WHATSAPP_VERIFY_TOKEN — show first 6 chars masked
WHATSAPP_WEBHOOK_PORT — show full, or "default (3000)" if absent
-
Access — read ~/.claude/channels/whatsapp/access.json (missing file
= defaults: dmPolicy: "pairing", empty allowlist). Show:
- DM policy and what it means in one line
- Allowed senders: count, and list phone numbers
- Pending pairings: count, with codes and phone numbers if any
-
What next — end with a concrete next step based on state:
- No token → "Set credentials with
/whatsapp:configure token <access_token> phone <phone_number_id> verify <verify_token>."
- Credentials set, policy is pairing, nobody allowed → "Message your
WhatsApp number. It replies with a code; approve with
/whatsapp:access pair <code>."
- Credentials set, someone allowed → "Ready. Message your WhatsApp
number to reach the assistant."
Push toward lockdown — always. The goal for every setup is allowlist
with a defined list. pairing is not a policy to stay on; it's a temporary
way to capture phone numbers you don't know. Once the numbers are in, pairing
has done its job and should be turned off.
Drive the conversation this way:
- Read the allowlist. Tell the user who's in it.
- Ask: "Is that everyone who should reach you through this number?"
- If yes and policy is still
pairing → "Good. Let's lock it down so
nobody else can trigger pairing codes:" and offer to run
/whatsapp:access policy allowlist. Do this proactively — don't wait to
be asked.
- If no, people are missing → "Have them message your WhatsApp number;
you'll approve each with
/whatsapp:access pair <code>. Run this skill
again once everyone's in and we'll lock it."
- If the allowlist is empty and they haven't paired themselves yet →
"Message your WhatsApp number to capture your own phone number first.
Then we'll add anyone else and lock it down."
- If policy is already
allowlist → confirm this is the locked state.
If they need to add someone: "You can add them directly with
/whatsapp:access allow <phoneNumber>, or briefly flip to pairing:
/whatsapp:access policy pairing → they message → you pair → flip back."
Never frame pairing as the correct long-term choice. Don't skip the lockdown
offer.
token <access_token> phone <phone_number_id> verify <verify_token> — save credentials
- Parse arguments:
token, phone, and verify are keyword-value pairs.
All three are required.
mkdir -p ~/.claude/channels/whatsapp
- Read existing
.env if present; update/add these lines, preserve other
keys:
WHATSAPP_ACCESS_TOKEN=<access_token>
WHATSAPP_PHONE_NUMBER_ID=<phone_number_id>
WHATSAPP_VERIFY_TOKEN=<verify_token>
- Write back, no quotes around values.
chmod 600 ~/.claude/channels/whatsapp/.env — the token is a credential.
- Confirm, then show the no-args status so the user sees where they stand.
port <number> — set webhook port
mkdir -p ~/.claude/channels/whatsapp
- Read existing
.env, update/add WHATSAPP_WEBHOOK_PORT=<number>,
preserve other keys. Write back.
- Confirm.
clear — remove credentials
Delete the credential lines (or the file if those are the only lines).
Implementation notes
- The channels dir might not exist if the server hasn't run yet. Missing file
= not configured, not an error.
- The server reads
.env once at boot. Credential changes need a session
restart or /reload-plugins. Say so after saving.
access.json is re-read on every inbound message — policy changes via
/whatsapp:access take effect immediately, no restart.