How to Set Up OpenClaw DM Pairing Safely

DM pairing is OpenClaw’s front door for direct messages. When a channel uses dmPolicy pairing, unknown senders get a short code and their message is not processed until an owner approves it. That gives you a safe default for Telegram, WhatsApp, Slack, Discord, Signal, Matrix, and the other supported message channels.

30-second answer

Set the channel dmPolicy to pairing, let unknown senders receive a one-time code, review requests with openclaw pairing list , and approve trusted senders with openclaw pairing approve . Codes are eight characters, expire after one hour, and pending requests are capped per channel. Treat the allowlist files under credentials as sensitive.

When this pays off

This is the right setup when you want people to reach your bot without making it public. It is especially useful for founders, agencies, and support operators who need controlled onboarding: a client can request access, but the agent will not process their messages or expose tools until someone trusted approves the sender.

Operator runbook

1. Keep dmPolicy at pairing unless you have a reason to change it. pairing blocks unknown direct messages until approval. allowlist is stricter but requires you to pre-enter senders. open is public only with allowFrom: ["*"], and disabled ignores DMs entirely.
2. Understand the code lifecycle. Pairing codes are short, uppercase, avoid ambiguous characters, and expire after one hour. The bot only sends the pairing message when a new request is created, roughly once per hour per sender, so users are not spammed continuously.
3. Review pending requests from the operator side. Use openclaw pairing list and approve with openclaw pairing approve . For multi-account channels, account scoping matters, so approve in the same channel/account context that received the request.
4. Know the first-owner bootstrap behavior. If no command owner exists yet, approving a DM pairing code can bootstrap commands.ownerAllowFrom to that approved sender. After an owner exists, later approvals only grant DM access and do not add more privileged owners.
5. Separate DM and group trust. The pairing docs are explicit: approving a DM pairing code does not automatically allow group commands or group control. Group chats still follow groupPolicy, groupAllowFrom, groups, topics, and mention gates depending on the channel.
6. Protect pairing state. Pending and approved stores live under ~/.openclaw/credentials. They gate access to the assistant, so they belong in your secret-handling mental model along with tokens, channel credentials, and auth profiles.

Verification

Send a DM from an unknown account and confirm the bot sends a pairing code but does not process the message. Approve the code, send a second DM, and confirm it is processed. Then try a group message from the same sender and confirm group policy still behaves independently.

Common mistakes

Do not approve codes you cannot map to a real person. Do not assume deleting a chat removes allowlist state. Do not switch to open because pairing feels inconvenient during setup. And do not post pairing codes in shared channels; while short-lived, they are still part of an access workflow.

Turn it into a repeatable operating system

The Playbook turns DM pairing into an onboarding routine: how to identify the requester, when to approve, when to revoke, and which tool profile a newly paired channel should get. That keeps access growth intentional instead of accidental.

Before rollout

Before rollout, write the approval rule in plain language: who is allowed to request access, how you verify their identity, who can approve, and when to revoke. Pairing is simple technically, but most mistakes are human approval mistakes, not command syntax mistakes. Also document where allowlist files live so revocation is easy during an incident and stale access can be removed quickly.