OpenClaw's Telegram pairing message, decoded (and how to approve it)
A first message to a fresh bot gets a pairing code and instructions written for the wrong reader. What the template means, the one command that approves it, and the one-hour expiry.
That message is OpenClaw’s pairing gate working as designed: by default, nobody can talk to your agent until the gateway’s owner approves them. The bot replies to an unknown sender with an “access not configured” note and a short pairing code, and the fix is one command on the machine running OpenClaw:
openclaw pairing approve telegram <CODE>Codes expire after one hour, so approve while it’s fresh. If you’re the owner reading that message, messaging your own new bot for the first time, the instructions still apply to you: run the approve command on your server, send another message, and you’re in.
Why the message reads like it’s for someone else
The template is written to the sender, telling them to pass the code to “the bot owner,” the person with terminal access to the gateway. That makes perfect sense when a stranger DMs your agent. It reads strangely in the far more common first-run case: you just connected Telegram, you message your own bot, and the bot appears to tell you to go ask yourself for permission. We watched a first-time user hit exactly this on a fresh setup: the bot answered their hello with the raw pairing template and its openclaw pairing approve… instruction, and the natural reaction was “did I break it?” You didn’t. The agent isn’t offline and the connection isn’t broken; the door is just closed until the machine’s operator opens it. As of the 2026.7.x releases the docs expose no setting to reword that template, so every fresh OpenClaw Telegram setup greets its first sender this way.
Approving someone, start to finish
On the machine (or in the container) running the gateway, list what’s pending, then approve the code the sender gave you:
openclaw pairing list telegram
openclaw pairing approve telegram A1B2C3D4The sender’s next message goes through to the agent. Two mechanics worth knowing: the code identifies the sender, not the message (once approved, they’re approved until you remove them), and codes are single-use and time-boxed (“pairing codes expire after 1 hour,” per the docs), so a code from yesterday needs the sender to message again and generate a fresh one.
Pairing grants DMs: groups are a separate door
The docs are explicit on a distinction that catches people: “DM pairing approval does not mean ‘this sender is authorized everywhere.’ Pairing grants DM access only.” Letting the same person reach the agent inside a group chat is configured separately: the group has to be allowlisted under channels.telegram.groups, and group-sender rules come from groupAllowFrom. If your agent answers you in DMs but ignores you in a group, that’s not a bug either: it’s the second door.
The dial behind the behavior
Pairing is just the default position of dmPolicy, which has four settings: "pairing" (unknown senders get codes), "allowlist" (only IDs you’ve listed, no code flow), "open" (anyone, which requires explicitly setting allowFrom: ["*"], and deserves the hesitation it causes), and "disabled" (no DMs at all). If you know exactly who should reach the agent, an allowlist removes the pairing beat entirely: add your own Telegram ID and first contact just works. The full model, including how these gates compose with channel config, is in our pairing and allowlists guide. And if what you’re seeing isn’t this message but a “pairing required” error about device scopes in the dashboard, that’s a different gate with its own guide.