OpenClaw pairing

Pairing is the word behind most first-hour confusion with OpenClaw: the bot is running, the message was sent, and nothing comes back. The docs define it as the explicit access approval step, used in two places, for who may talk to the bot over direct messages and for which devices may join the Gateway as nodes. With the DM policy set to pairing, an unknown sender gets a short code and their message is not processed until someone approves it. Here is how the codes behave, the two approval paths and what each grants, the owner question that the CLI answers for you, and the sender groups that keep allowlists in one place.

With DM policy pairing, unknown senders get a short code and their message is not processed until you approve.

The codes

• Eight characters, uppercase, without the ambiguous ones, and they expire after one hour; the bot sends the pairing message only when a new request is created, roughly once per hour per sender.
• Pending requests are capped at three per channel account; further requests are ignored until one expires or is approved.
• An open DM policy is public only when the effective allowlist includes the wildcard; an open policy with concrete entries still admits only those senders, and pairing approvals never widen open access.

Two ways to approve

In the Control UI, the DM access requests queue under the channel settings combines pending requests from every account whose policy is pairing; filter by channel, review the sender id and metadata, approve. Approval grants direct-message access only, never group access, and the dialog can notify the requester and, when no command owner exists and the session has admin scope, make the sender the first command owner. Dismiss removes a request without blocking; the sender can ask again. From the CLI, list the channel’s requests and approve a code, with a notify flag and an account flag for multi-account channels.

The owner question

• Unlike the UI’s explicit checkbox, the CLI bootstraps the command owner automatically when none is configured, so a first-time setup has an explicit owner for privileged commands and exec approval prompts; later approvals only grant DM access.
• A manually allowlisted sender is not a command owner; owner-only commands reply with the exact config command an operator has to run.
• The channel wizard offers to set up an operator account separately from chat access when no owner exists; ownership lets someone update, restart, reconfigure and approve, and grants no chat access on its own. WhatsApp’s login QR links an account and is a separate flow from approving people who message it.

OpenClaw not responding is the ladder that starts with pairing when a bot is silent, and OpenClaw nodes and remote hands covers the other pairing, the device kind.

Sender groups and state

When the same trusted senders should apply to several channels, or to both DM and group allowlists, a top-level access group of message senders lists them once, with per-channel ids, and allowlists reference it by name. Pairing state for channels that use the pairing API lives in the shared SQLite database. OpenClaw sessions explains what happens to a sender’s messages after approval, and why DMs share one session by default.

On Diali

On Diali the approval queue is the dashboard: a new sender on any connected channel appears there with the code, and approving is one tap; the owner is you by construction, so the bootstrap question never comes up. Hosted OpenClaw on Diali is the assistant.

• An eight-character code, one hour, three pending per account.
• Approval grants DMs only; groups have their own allowlists.
• The CLI makes the first approved sender the owner; the UI asks.