OpenClaw Slack access control

Slack has more surfaces than most channels, public channels, private channels, DMs, group DMs and threads, and the access rules follow that shape: a DM policy, a channel policy keyed by channel ID, mention gating with five sources, and action gates for what the bot may do once admitted. Here is each layer, the live-change rules, and the group-DM limitation that no config key can work around.

Actions, gates and live changes

• Slack actions are grouped under the actions block as messages, reactions, pins, member info and emoji list, all enabled by default; the message actions include send, conversation-open, upload-file, download-file, read, edit, delete, pin, unpin, list-pins, member-info and emoji-list, and download-file accepts the file IDs shown in inbound placeholders, returning image previews for images and local file metadata for other types.
• Emoji-list discovers workspace custom emoji and aliases sorted by shortcode with a limit that defaults to and cannot exceed 100, each entry's identifier can be used directly as the react emoji with the colons optional, discovery is gated separately from reactions, and the app needs the emoji read scope.
• DM access, allowlists, group policy, mention rules and existing channel policy fields apply to new messages, commands and system events without reconnecting Slack; each admitted turn keeps one resolved policy snapshot, workspace name resolution runs once per new snapshot and never appends identities from an older policy, and presence targets learned under an older snapshot retire before another background wake.
• Transport credentials, account enablement, adding or removing accounts or channel entries, the name-matching mode, presence settings and native command or approval registration still restart the Slack monitor while the gateway keeps running.

There is no OpenClaw config setting that makes the app see a group DM it never joined.

DM policy and channel policy

The DM policy takes pairing, the default, allowlist, open, which requires the canonical allowlist to include the wildcard, and disabled, with DM flags for enabling DMs, the legacy DM allowlist, group DMs off by default and an optional group-DM channel allowlist; those two group-DM flags only filter group DMs Slack already delivers to the app and cannot make it see one it never joined. Across accounts, an omitted account DM or group policy inherits the channel root and an explicit account policy wins, the user-token read-only flag inherits the same way, the default account's own allowlist applies only to it, named accounts inherit the channel allowlist when theirs is unset and never the default account's, and the legacy DM policy keys are still read, with the doctor fix migrating them when it can do so without changing access; DM pairing is approved from the CLI with the pairing approve command. The channel policy takes open, allowlist and disabled, and the channel allowlist under the channels map must use stable Slack channel IDs as keys, with Enterprise Grid org installs requiring team-prefixed keys so policies cannot cross workspace boundaries. When invited into an allowed channel the bot posts one short introduction grounded in the channel name, purpose or topic and available recent messages, disabled with the join-intro key or overridden per account, never bypassing channel policy and never in DMs. Without a Slack block the gateway does not auto-start Slack from the environment variables, and the ambient-channels flag opts into env-only auto-configuration under an allowlist policy with a logged warning. Allowlist entries are resolved at startup and when a new snapshot is first used, unresolved channel names are kept but ignored for routing, authorisation and routing are ID-first, and direct username or slug matching needs the dangerous name-matching switch; under an allowlist policy an unresolved name is denied, which is why the docs tell you to copy the channel link and use the ID at the end of the URL as the key.

Mentions, per-channel controls, bots

• Channel messages are mention-gated by default, and a mention can be an explicit app mention, a Slack user-group mention when the bot is a member of that group with the user-groups read scope, a configured mention pattern, a reply to the bot's own message, or a follow-up in a thread the bot took part in, the last two being the implicit-mention flags.
• Per-channel controls cover the mention requirement, ignoring messages that mention someone else, a reply mode that overrides the account and chat-type modes, a user allowlist, bot acceptance, skills, a system prompt and tool policies including per-sender policies keyed by channel, id, e164, username, name or the wildcard; the ignore-other-mentions filter drops channel messages that mention another user or group but not this bot, leaves DMs and group DMs alone, and fails open when the bot user ID cannot be resolved from the auth test, as with a user-token-only identity.
• Bot-authored room messages are accepted only when the sending bot is explicitly listed in that room's user allowlist or when at least one explicit owner ID from the channel allowlist is currently a room member, wildcards and display-name owners do not count, owner presence is read from the conversation members with the matching read scope for public or private channels, a failed lookup drops the message, and accepted bot messages fall under the shared bot loop protection with default, channel and per-room budgets.

OpenClaw on Slack is the channel post these rules belong to, and OpenClaw Slack threads and sessions where an admitted message lands once it is through.

Group DMs, and what mentions cannot do

Typing the bot's name in an existing group DM adds nothing: the bot token cannot see the conversation, the API calls fail with access or not-found errors and no event is delivered. The two Slack-supported paths are converting the group DM to a private channel and inviting the app, or asking the app to open a conversation with the human recipients through the conversation-open action, which calls the open endpoint with the configured write identity, needs the group-DM write scope for bots, takes one to eight member IDs and returns a routable target for a following send. OpenClaw bot loop protection covers the guard on accepted bot messages, and OpenClaw Telegram access control the same access layers on a channel with a very different shape.

On Diali

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

• Channel keys are stable IDs; names need a lookup or a dangerous switch.
• Group-DM flags filter what Slack delivers; they never grant membership.
• Bot messages need a listed bot or a present owner.