How to Configure OpenClaw Channel Access Control

Channel access control is where OpenClaw stops being a demo bot and starts being a real assistant. A Slack workspace, Telegram group, WhatsApp DM, or Discord server can contain many people and a lot of quoted context. You need to decide who can trigger the agent, what groups are allowed, whether mentions are required, and what context the model is allowed to see.

30-second answer

Use per-channel dmPolicy for direct messages and groupPolicy, groups, groupAllowFrom, and mention rules for shared rooms. Keep pairing or allowlist as the default. Use open only when the required wildcard allowFrom is deliberate. Use contextVisibility when quoted or thread history from non-allowlisted people should be filtered before entering the model input.

When this pays off

This matters for any buyer who wants OpenClaw in a real team channel. Without access control, one enthusiastic teammate can turn a private operator agent into a public toy. With the right policy, the bot can live in useful places, respond only when invited, and avoid reading more context than it should.

Operator runbook

1. Set the DM policy first. pairing is the default pattern for unknown senders, allowlist admits only known senders, open requires allowFrom: ["*"], and disabled ignores inbound DMs. For most production agents, pairing or allowlist is the right starting point.
2. Configure group policy separately. Group allowlists are not the same as DM approvals. A sender who can DM the bot does not automatically get group command rights. Keep groupPolicy allowlist unless the room is intentionally open and you have mention gates plus narrow tools.
3. Use mention gating in shared rooms. The configuration docs describe group chat mention patterns and visible reply behavior. Requiring a mention prevents every casual room message from becoming an agent run, which protects cost, context quality, and team trust.
4. Control supplemental context. contextVisibility decides whether quoted replies, thread roots, fetched history, and forwarded metadata are included as received or filtered through allowlists. Use allowlist or allowlist_quote when non-allowed users may appear in a thread but should not influence the model.
5. Use access groups for repeated sender sets. The pairing docs describe top-level accessGroups of type message.senders. They are useful when the same operator group should apply across Telegram, Discord, WhatsApp, or multiple channel allowlists without duplicating every sender id.
6. Pair policy with tool policy. A broad channel with powerful tools is risky. If a group is open or semi-open, keep the agent’s tools narrow. If an agent has runtime, filesystem, browser, or node access, keep the channel private and owner-controlled.

Verification

Test four cases: allowed DM, unknown DM, allowed group mention, and group message without a mention. Then test quoted/thread context if your channel uses it. Logs should show blocked, pairing, allowlist, or mention-required decisions clearly enough that you can explain why the bot did or did not answer.

Common mistakes

Do not set open without understanding the wildcard requirement. Do not assume DM pairing grants group authority. Do not let visible replies be automatic in rooms where you expect all sends to go through the message tool. And do not ignore context visibility if quoted text from non-allowed senders could contain prompt injection or private data.

Turn it into a repeatable operating system

The OpenClaw Playbook gives channel recipes by trust level: private founder DM, trusted team channel, shared support inbox, public community room, and emergency rescue bot. The right answer is not one config; it is a repeatable way to match channel risk to agent power.

Before rollout

Before rollout, ask one trusted teammate to try the paths you expect to fail: unknown DM, unmentioned group message, non-allowlisted sender, and quoted context from someone outside the allowlist. Access control is only real after the blocked cases are proven.