OpenClaw Discord access control

A Discord bot lives in servers, channels, threads and DMs at once, so OpenClaw's access model has a layer for each: a DM policy, a guild allowlist with per-channel entries, mention gating, command auth and action gates. Here is each layer, the channel-map rule that surprises the most people, how policy changes apply live, and how roles can route to different agents.

DMs and access groups

• The DM policy takes pairing, the default, allowlist, which needs at least one sender, open, which needs the wildcard in the canonical allowlist, and disabled, and when it is not open unknown users are blocked or prompted to pair; across accounts, an omitted account policy inherits the channel root and an explicit one wins, the default account's own allowlist applies only to it, the canonical allowlist beats the legacy DM allowlist, named accounts inherit the channel allowlist when theirs is unset and never the default account's, and the doctor fix migrates the legacy keys when access does not change.
• DM delivery targets are the user prefix with an ID or a mention, and bare numeric IDs normally resolve as channel IDs when a channel default is active, except that IDs listed in the effective DM allowlist are treated as user targets for compatibility.
• The allowlist accepts dynamic access-group entries shared across message channels: a message-senders group lists members in each channel's normal syntax, while a channel-audience group defines membership as being a member of the configured guild with effective view permission on the configured channel after role and channel overwrites, so anyone who can see a maintainers channel can DM the bot while DMs stay closed to everyone else, and dynamic and static entries can be mixed.
• Audience lookups fail closed: a missing-access error, a failed member lookup or a channel from a different guild makes the sender unauthorised, and because DMs carry no guild member state OpenClaw resolves the member through the Discord REST API at authorisation time, which needs the Server Members intent enabled in the developer portal.

Adding even one channel entry turns the map into an allowlist: any channel not matched by an entry is denied, not merely left at guild defaults.

Guilds, channels and mentions

Guild handling takes open, allowlist and disabled, with allowlist as the secure baseline whenever the Discord block exists. Under allowlist the guild must match the guilds map by ID, with slugs accepted, optional user and role allowlists admit a sender who matches either, direct name and tag matching is off unless the dangerous name-matching switch is enabled as break-glass compatibility, names are supported for users but IDs are safer and the security audit warns about name entries, and a guild with a channels map denies non-listed channels while a guild without one allows every channel it can see. Without a Discord block the gateway does not auto-start Discord from the token variable, which stays the default-account fallback once the block exists, and the ambient-channels flag opts into env-only auto-configuration under allowlist with a logged warning. Guild messages are mention-gated by default, a mention being an explicit bot mention, a configured mention pattern or the implicit reply-to-bot behaviour where supported; outbound mentions use the canonical user, channel and role syntax and never the legacy nickname form; the mention requirement is set per guild or channel, the ignore-other-mentions filter drops messages addressed to another user, role or non-webhook bot while an explicit mention of this bot still wins, and group DMs are ignored by default with an optional allowlist of channel IDs or slugs. The channel-map rule matters most: a guild entry with no channels map lets the bot work in every channel it can see, but adding even one channel entry turns the map into an allowlist, which is how people who add one channel for special settings find the bot silent everywhere else; the wildcard entry keeps the rest of the guild reachable, channel entries override guild values so a channel with a wildcard user list opens that one room even under a narrow guild list, entries match by ID, name or slug, and a thread falls back to its parent channel's entry.

Live changes, routing, commands, gates

• For running accounts, policy-only changes saved in the Control UI apply through the gateway's validated runtime config publication without restarting the connection or waiting for active turns, covering the group and DM policies, the allowlist, the DM block, the guilds map, bot acceptance and name matching at the channel and per account; new messages use the published policy, name entries are resolved and cached per policy revision before admission, a name lookup that cannot finish within an interaction's budget shows an ephemeral policy-updating message and returns no autocomplete choices, and token, application ID, proxy, intents, command registration, voice and enablement still take the restart path as one deferred transaction.
• Role-based routing uses the roles field on a binding's match to send guild members to different agents by role ID, evaluated after peer bindings and before guild-only bindings, with every configured match field required when a binding also names a peer or guild; native commands default to auto and are enabled for Discord, a per-channel override exists, turning them off skips registration and cleanup so old commands may linger until removed from the app, command auth uses the same allowlists as messages, unauthorised users may still see a command but get a not-authorised reply, and slash replies are ephemeral by default.
• Message actions cover messaging, channel administration, moderation, presence and metadata, the emoji-list action lists a server's custom emoji sorted by name with a limit that defaults to and cannot exceed 100 and identifiers that pass straight to react in Unicode, name-and-ID or bracketed forms, the event-create action takes an optional cover image, and the gates default to enabled for reactions, messages, threads, pins, polls, search, member, role and channel info, channels, voice status, events, stickers, emoji and sticker uploads and permissions, and to disabled for roles, moderation and presence.

OpenClaw on Discord is the channel post these rules belong to, and OpenClaw access groups the shared access-group model the channel-audience type extends.

The channel-map rule

Most Discord silences after a config change come from that one rule: a channels map is an allowlist, so the first entry you add for a special room switches every other room off until a wildcard entry brings them back. OpenClaw channel routing explains the binding model that role-based routing plugs into, and OpenClaw Slack access control the same access layers on Slack, where channel keys must be IDs.

On Diali

Discord is one of the channels Diali connects from the dashboard, with the runtime config generated and replaced at each release, so these policies are the vocabulary behind that screen rather than a file to hand-edit. Discord on Diali describes the channel on Diali and Diali security the boundary every connected channel shares.

• A channels map with one entry is an allowlist; add the wildcard.
• Audience groups fail closed and need the Server Members intent.
• Roles, moderation and presence actions are off until gated on.