OpenClaw access groups

When the same five people should reach an agent on Telegram, Discord and WhatsApp, three copies of one allowlist drift apart. OpenClaw’s access groups are named sender lists defined once under one key and referenced from channel allowlists with an access-group prefix, and the docs are careful about what they are not: a group grants nothing by itself and only matters where an allowlist field references it. Here are the static type and its channel keys, the reference examples, the paths and channels that support it, the dynamic Discord type, the diagnostics helper, and the security notes.

Static sender groups

• A static group has the message-senders type and a members map keyed by message-channel id, plus a wildcard key for entries shared by every channel that references the group; the docs’ example lists a global owner id under the wildcard and Discord, Telegram and WhatsApp ids under their channels.
• Entries are matched with the destination channel’s normal allow-from rules, and OpenClaw does not translate sender ids between channels: a person with a Telegram id and a Discord id is listed under both channel keys.
• Referencing works anywhere the message-channel path supports sender allowlists: a DM allowlist on Discord and Telegram pointing at an operators group, a group sender allowlist on WhatsApp and a per-space users list on Google Chat pointing at an on-call group, and groups mixed with direct entries in one list.
• Supported paths are DM sender allowlists, group sender allowlists, channel-specific per-room sender lists that use the same matching rules, and command authorisation paths that reuse those allowlists; support depends on a channel being wired through the shared sender-authorisation helpers, which today covers ClickClack, Discord, Feishu, Google Chat, iMessage, IRC, LINE, Mattermost, Microsoft Teams, Nextcloud Talk, Nostr, QQ Bot, Signal, Slack, SMS, Telegram, WhatsApp, Zalo and Zalo Personal.

A group grants nothing by itself. It only matters where an allowlist field references it.

The Discord audience type

Discord also supports a dynamic type, the channel audience: a group naming a guild id, a channel id and a membership rule that defaults to can-view-channel means allow Discord DM senders who can currently view that guild channel, resolved through Discord at authorisation time with its view-channel permission rules. It suits the case where a Discord channel is already the source of truth for a team, such as a maintainers or on-call channel. The bot needs access to the guild and channel and the server-members intent enabled in the developer portal, and the group fails closed when Discord returns a missing-access error, the sender cannot be resolved as a guild member, or the channel belongs to another guild.

Diagnostics and security

• Plugin authors can inspect structured access-group state without expanding it into a flat list: a resolver takes the groups, the allow-from list, the channel, account and sender and reports referenced, matched, missing, unsupported and failed groups, for diagnostics and conformance tests; the flat expansion helper is for compatibility paths only.
• Access groups are allowlist aliases, not roles: they create no owners, approve no pairing requests and grant no tool permissions. An open DM policy still requires the wildcard in the effective allowlist, so referencing a group is not public access, and a missing group name fails closed, authorising nobody.
• Keep channel ids stable and prefer numeric or user ids over display names; when a sender who should match is blocked, confirm the exact reference, the group type, the id under the matching channel key or the wildcard, the channel’s own allowlist syntax, and for Discord audiences the bot’s channel visibility and intent. Run the doctor after editing access-control config, since it catches invalid allowlist and policy combinations before runtime.

OpenClaw on Discord is the channel with the dynamic audience type, and OpenClaw multi-user setups the setup where one Gateway serves several people and shared lists earn their keep.

Where it sits

Access groups sit under the allowlists, not beside pairing: pairing remains the separate DM approval flow, and routing decides which agent answers after the allowlist has let the sender in. OpenClaw doctor validates the combination, and OpenClaw channel routing explains what happens to an allowed message next.

On Diali

On Diali the allowlists behind each connected channel are what the dashboard edits, and an access group is the same list written once for WhatsApp, Telegram, Discord and Slack together; the fail-closed rule for a missing name applies exactly as upstream. Hosted OpenClaw on Diali is the assistant and Diali security describes the boundary the allowlists sit inside.

• Define once, reference with a prefix, per channel key.
• An alias, not a role; a missing name authorises nobody.
• Discord audiences resolve live and fail closed.