What can a stranger do if they message your OpenClaw bot before you approve them?

Under OpenClaw’s default DM policy, a stranger’s message is not processed. They do not get an agent reply, a tool call, or a command. The bot can send them a pairing code when a new request is created, about once an hour, and then it ignores them until you approve that request from the Control UI or the CLI. The code does not let them approve themselves. Approval is an action on the Gateway you run, and it grants direct-message access only.

That is pairing, the default called pairing on every DM-capable channel that implements OpenClaw’s pairing API. Allowlist mode is stricter: unknown senders are blocked and there is no handshake. Open mode is the opposite, and it is off unless you put * on the allowlist on purpose. Disabled mode drops inbound DMs entirely. If you have not changed dmPolicy, you are on pairing. The rest of this piece is what that default actually allows a person you have never approved.

What does the stranger receive?

A short code, and only when their message creates a new pending request. The pairing docs describe the code as eight characters, uppercase, with ambiguous characters left out so 0 and O, 1 and I cannot be confused. It expires after one hour. The bot sends that pairing message when a new request is created, roughly once per hour per sender. Repeated texts in that window do not mint a fresh code and do not get a fresh reply.

Pending requests are capped at three per channel account. A fourth stranger, or a fourth attempt while three are still waiting, is ignored until one request expires or you approve or dismiss one. They cannot fill your disk with an infinite queue of DMs that each wake the model. The message that created the request is not handed to the agent. “Not processed” is the phrase in the pairing doc, and it is the whole security property. The model does not see that DM as a turn. Skills, shell, browser tools, and channel replies that an agent would normally send do not run for that sender.

The stranger can read the code if the bot delivered it in the chat. That feels like a secret, and it is not a login. You approve from Settings, then Channels, then DM access requests in the Control UI, where the queue shows pending requests from every configured channel account still on pairing. You can filter by channel or account, read the sender ID and metadata, and choose Approve. From the host, openclaw pairing list and openclaw pairing approve take the channel and the code. The stranger does not have that UI or that CLI unless they already have operator access to your Gateway, which is a different break-in than sending a Telegram DM.

What does Approve actually hand them?

Direct messages. The approval dialog is explicit that this does not grant group access. They can DM the bot after you approve. They cannot, from that act alone, drive the bot inside a group, become the command owner, or widen anyone else’s policy.

Two optional choices sit on that dialog when the product supports them. One notifies the requester on the same channel after you approve. The other, shown only when no command owner exists yet and your Control UI session has operator.admin, can make this sender the first command owner. That second box is the dangerous one, and it is opt-in on the UI. Do not tick it for a stranger. Command ownership is who may run owner-level commands, including updates and exec approvals. DM access is who may chat. They are separate on purpose.

The CLI is less chatty about that split. Unlike the checkbox, openclaw pairing approve bootstraps commands.ownerAllowFrom automatically when no command owner is configured, using an entry for that sender. After an owner exists, later approvals only grant DM access. If this Gateway has never had an owner, approve yourself from a setup path you control before you approve anyone else, or use the channel wizard’s separate “set up my operator account” step. That wizard asks for your personal user ID and does not promote chat allowlists on its own. Skip-for-now leaves ownership unchanged. An owner can still be blocked from chat by channel rules. Ownership is not a back door into the inbox, and an inbox approval is not ownership, except for that first CLI bootstrap when the owner field is empty.

Dismiss removes a pending request without approving it. It is not a permanent ban. The same sender can request again later. If you need a stranger to stay out even when they ask, pairing is the wrong end state. Allowlist mode never offers them the handshake. Disabled mode never hears the DM. Pairing is for “I want to see who knocked.” It is a poor lock for “this person must never knock again,” because a dismiss expires the request rather than writing a block.

Which channels does this cover?

The pairing page names Discord, Feishu, Google Chat, iMessage, IRC, LINE, Matrix, Mattermost, Microsoft Teams, Nextcloud Talk, Nostr, Signal, Slack, SMS, Synology Chat, Telegram, Twitch, WhatsApp, Zalo, and Zalo personal. An external plugin can join that list if it implements the pairing API. WebChat and the desktop Control UI are not a stranger’s DM. Those are operator clients. A person who can open your Control UI is already past the problem this article is about.

WhatsApp’s QR login is a different door. The QR links a WhatsApp account to OpenClaw. DM access requests approve people who message that account. Scanning the QR does not approve your contacts. Approving a contact does not link a second WhatsApp account. If a stranger messages the linked account before you approve them, they are in the pairing queue, same as Telegram, assuming the DM policy is still pairing.

Node pairing is the other use of the word, and a DM does not do it. Phones and other devices connect with role: node and a setup code you create from Settings, then Devices, or from a /pair flow if you installed the device-pair plugin. Official iOS and Android apps approve when the setup-code metadata matches. A stranger texting the bot does not receive a node token, a bootstrap token, or operator scopes. Treat a setup code like a password while it is valid, and do not paste one into a chat with someone you have not approved. That caution is about device pairing, not about the eight-character DM code.

What if the stranger is in a group, not a DM?

DM pairing does not decide the room. Group authorization is a separate store of rules: groupPolicy, group allowlists, mention gates, and per-group settings such as requireMention. Approving a DM code does not let that sender run the bot in a group. Being able to type in a group does not approve their DM.

The access-control docs draw a practical line. A private room whose members you trust, a team or a family, is a normal place for groupPolicy: "open", meaning any member of that room can trigger the bot. Rooms where strangers can join or post should keep a sender allowlist or mention gating. Replying to the bot, which some channels treat as an implicit mention, does not bypass groupAllowFrom. Check order is group policy and allowlists first, then mention or reply activation.

There is a second, quieter exposure, and it is not the stranger triggering the agent. Trigger authorization and context visibility are different. Who may start a turn is the policy above. What extra text the model can see on a turn someone else started is contextVisibility. The default is all, which keeps supplemental context as received: reply bodies, quotes, thread history, forwarded metadata. If a trusted person mentions the bot in a room where strangers can also post, those strangers’ words can sit in that context. That is not approval, and it is not a reason to paste experiments into a public channel to see what sticks. If the room is mixed, set context visibility to allowlist, or allowlist_quote if you still want one explicit quoted reply. Leave mention gating on. Do not set the DM policy to open because a group chat felt fine.

Slash commands and directives are honored only for authorized senders. Command authorization follows channel allowlists and pairing state unless you set a separate commands.allowFrom list. If an allowlist is empty or contains *, commands are effectively open on that channel. A stranger who has not been approved is not an authorized sender under pairing, so they do not get /exec or owner commands by typing them. /exec is documented as a session convenience for authorized operators. It is not a prize hidden in the pairing message.

Where does the request sit, and who else can read it?

For channels on the pairing API, state is in the shared SQLite database at ~/.openclaw/state/openclaw.sqlite. Pending requests are in channel_pairing_requests. Approved senders are in channel_pairing_allow_entries. Each row is keyed by channel and account. Those rows are the lock. Treat the database as sensitive for the same reason you treat an authorized-keys file as sensitive. Anyone who can edit it on the host can change who the bot will talk to. That person is not a stranger in Telegram. They are someone on the machine.

Older gateways wrote pairing JSON and allow-from JSON under ~/.openclaw/credentials/. openclaw doctor --fix imports those into SQLite and removes each source after a successful import. Ordinary startup leaves the legacy files in place. If both seem to exist, do not hand-edit the JSON and assume the live policy moved. Run doctor, then trust the SQLite rows. The access-control page still describes allow-from files as part of the pairing write path. The pairing page says channels on the pairing API read the canonical SQLite rows and do not merge the legacy files. When those two pages disagree, I follow the pairing page for where the decision lives, and I run doctor rather than reconciling them by hand.

Manually allowlisted senders are not automatically command owners. If someone is allowed to chat and is not an owner, owner-only commands reply with the exact openclaw config set commands.ownerAllowFrom line for the operator to run. They do not run it themselves. That reply is another thing to avoid creating for a stranger: do not approve them, and do not put their ID in the owner list because a command failed.

What should you leave human?

Leave the approval click human. The queue exists so a person looks at the sender ID before the agent does. Notify-after-approval can be on for someone you recognize. The first-owner option stays off for everyone except you, and only when no owner exists. Leave group mention gates on in any room you do not personally vet. Leave dmPolicy on pairing or allowlist. Open is a public bot, and the docs call it a deliberate opt-in that also requires * in the allowlist. If old state says open but the allowlist is a concrete list of people, runtime still admits only those senders. Pairing-store approvals do not widen open access. Do not “clean that up” into a wildcard to make a test pass.

If more than one human will be approved, stop sharing one session. The default session.dmScope is main: every DM shares the agent’s main session. That is reasonable for one person on several devices. It is a bad default once a second approved sender exists, because their turn and yours can share a transcript. Set per-channel-peer before the second approval, not after. openclaw security audit recommends that isolation when it sees multi-user DM traffic. The docs are also plain that this is a messaging boundary, not a host boundary. People who do not trust each other should not share one Gateway. Run separate gateways per trust boundary. Pairing cannot split a machine.

A stranger who messages before you approve them can create one pending request, receive one code about once an hour, and occupy one of three slots. They cannot make the agent act, and they cannot complete the approval. You can dismiss them and they can ask again later. The thing that changes their power is your Approve, and the thing that makes that Approve too large is an empty owner list or an open group policy you set on a different afternoon.