mirror of
https://github.com/openclaw/openclaw.git
synced 2026-02-19 18:39:20 -05:00
9c4eab69cc
* feat: Make BlueBubbles the primary iMessage integration - Remove old imsg skill (skills/imsg/SKILL.md) - Create new BlueBubbles skill (skills/bluebubbles/SKILL.md) with message tool examples - Add keep-alive script documentation for VM/headless setups to docs/channels/bluebubbles.md - AppleScript that pokes Messages.app every 5 minutes - LaunchAgent configuration for automatic execution - Prevents Messages.app from going idle in VM environments - Update all documentation to prioritize BlueBubbles over legacy imsg: - Mark imsg channel as legacy throughout docs - Update README.md channel lists - Update wizard, hubs, pairing, and index docs - Update FAQ to recommend BlueBubbles for iMessage - Update RPC docs to note imsg as legacy pattern - Update Chinese documentation (zh-CN) - Replace imsg examples with generic macOS skill examples where appropriate BlueBubbles is now the recommended first-class iMessage integration, with the legacy imsg integration marked for potential future removal. * refactor: Update import paths and improve code formatting - Adjusted import paths in session-status-tool.ts, whatsapp-heartbeat.ts, and heartbeat-runner.ts for consistency. - Reformatted code for better readability by aligning and grouping related imports and function parameters. - Enhanced error messages and conditional checks for clarity in heartbeat-runner.ts. * skills: restore imsg skill and align bluebubbles skill * docs: update FAQ for clarity and formatting - Adjusted the formatting of the FAQ section to ensure consistent bullet point alignment. - No content changes were made, only formatting improvements for better readability. * style: oxfmt touched files * fix: preserve BlueBubbles developer reference (#8415) (thanks @tyler6204)
2.6 KiB
2.6 KiB
summary, read_when, title
| summary | read_when | title | |||
|---|---|---|---|---|---|
| Pairing overview: approve who can DM you + which nodes can join |
|
Pairing |
Pairing
“Pairing” is OpenClaw’s explicit owner approval step. It is used in two places:
- DM pairing (who is allowed to talk to the bot)
- Node pairing (which devices/nodes are allowed to join the gateway network)
Security context: Security
1) DM pairing (inbound chat access)
When a channel is configured with DM policy pairing, unknown senders get a short code and their message is not processed until you approve.
Default DM policies are documented in: Security
Pairing codes:
- 8 characters, uppercase, no ambiguous chars (
0O1I). - Expire after 1 hour. The bot only sends the pairing message when a new request is created (roughly once per hour per sender).
- Pending DM pairing requests are capped at 3 per channel by default; additional requests are ignored until one expires or is approved.
Approve a sender
openclaw pairing list telegram
openclaw pairing approve telegram <CODE>
Supported channels: telegram, whatsapp, signal, imessage, discord, slack.
Where the state lives
Stored under ~/.openclaw/credentials/:
- Pending requests:
<channel>-pairing.json - Approved allowlist store:
<channel>-allowFrom.json
Treat these as sensitive (they gate access to your assistant).
2) Node device pairing (iOS/Android/macOS/headless nodes)
Nodes connect to the Gateway as devices with role: node. The Gateway
creates a device pairing request that must be approved.
Approve a node device
openclaw devices list
openclaw devices approve <requestId>
openclaw devices reject <requestId>
Where the state lives
Stored under ~/.openclaw/devices/:
pending.json(short-lived; pending requests expire)paired.json(paired devices + tokens)
Notes
- The legacy
node.pair.*API (CLI:openclaw nodes pending/approve) is a separate gateway-owned pairing store. WS nodes still require device pairing.