OpenClaw group chats

OpenClaw lives on your own messaging accounts: there is no separate WhatsApp bot user, so if you are in a group, OpenClaw can see that group and respond there. That makes group rules the most important safety surface in the product, and the docs apply the same model across every group-capable channel. Here are the defaults and the two controls behind them, how replies become visible, what context the model is allowed to see, the session shapes, the DM-versus-group sandbox pattern, the policy evaluation order, mention gating, per-group tools, activation, and the fields a group turn carries.

Defaults and controls

• By default groups are restricted with the allowlist policy so senders are blocked until allowlisted, replies require a mention unless mention gating is disabled for a group, and the final reply text posts to the room automatically; in one line, allowlisted senders can trigger OpenClaw by mentioning it.
• Three separate controls: DM access through the allow-from lists, group access through the group policy plus the group and group-allow-from lists, and reply triggering through mention gating with the mention requirement and the activation command. A group message flows policy, then group allowlist, then mention check, with unmentioned messages stored for context only.
• Visible replies default to automatic, the final text posted to the room; a message-tool mode lets the agent decide when to speak by calling the message tool, keeps substantive final text private if the model misses the tool, and falls back to automatic when the tool is unavailable under the active policy, which the doctor warns about. Command turns always reply visibly, typing indicators still fire for direct group requests, and unmentioned always-on chatter can be submitted as quiet room events instead of user requests.
• Context visibility is a separate control from trigger authorisation: allowlists decide who can trigger, not what quoted or historical snippets the model sees, and a context-visibility setting of all, allowlist or allowlist-plus-quote filters reply, thread, quote and forwarded context per channel, per account or globally, failing closed on unknown combinations; tool policy still follows the originating requester, not every sender in the prompt.

Allowlisting a group or sender does not disable mention gating; set that group’s requireMention to false when all messages should trigger.

Sessions and the sandbox pattern

Group sessions use per-channel group keys, rooms use channel keys, Telegram forum topics add a topic suffix, direct chats use the main session, and heartbeats run only in the heartbeat session, never in groups. A binding’s group scope set to main lets a trusted room share the agent’s main conversation without changing admission, gating or routing. The docs’ recommended single-agent pattern puts personal traffic in DMs and public traffic in groups: DMs land in the main session while groups use non-main keys, so a sandbox in non-main mode with session scope and no workspace access runs every group in its own container with a restricted tool set while the DM session stays on the host with full tools, and an allowlisted folder can be bind-mounted read-only when groups should see one directory. The warning is that a room merged into main is a main session and is not covered by that sandbox boundary, so untrusted rooms must not be merged when the sandbox is the boundary you rely on. Group policy per channel is open, which bypasses allowlists but keeps mention gating, disabled, or allowlist, with per-channel allowlist shapes: sender lists for WhatsApp, Telegram, Signal, iMessage, Teams and Zalo, guild channels on Discord, channel maps on Slack, room ids or aliases on Matrix; Telegram sender lists take numeric ids only, and when a provider block is missing entirely the policy fails closed to allowlist and logs it once per account.

Mentions, tools, activation

• Mention gating defaults per subsystem under the wildcard group; implicit mention facts are channel-specific, a reply to the bot on Discord, Teams, QQ Bot, Slack and Telegram, a quote of the bot on LINE, WhatsApp and Zalo, and a joined thread on Mattermost, Slack and Tlon, with an implicit-mentions flag honoured only by some producers. Configured mention patterns are safe case-insensitive regex fallbacks, agent-level patterns beat the global ones and both fall back to the agent’s identity name and emoji, native platform mentions always trigger, and patterns can be scoped per channel with allow or deny modes and room lists, account policy taking precedence.
• Per-group tool restrictions add allow, also-allow and deny lists for a whole room and per-sender overrides keyed by channel-and-sender, id, phone, username, display name or wildcard, resolved most specific first and applied on top of global and agent policy with deny winning; the group history limit sets how many pending or recent room messages wrap a turn, zero disabling it.
• Group owners, meaning senders matching the owner allow-from list, toggle activation per group with the mention or always modes, which override the group’s mention requirement on the channels that consult it; group payloads carry the chat type, subject, members and whether the bot was mentioned, Telegram topics add thread and forum fields, and the first turn of a group session injects an intro that asks the model to answer like a human, keep chat spacing and avoid literal newline sequences, with channel-sourced names rendered as untrusted metadata.

OpenClaw channel routing decides which agent and session a group message reaches, and OpenClaw access groups is the way to share one sender list across channels.

The common intents

Allow all groups but only answer on mentions with a wildcard group requiring a mention; disable all group replies with the disabled policy; allow only specific groups by listing them without a wildcard; let only yourself trigger with the allowlist policy and your own id; and reuse one trusted set with an access group. DM pairing approval is not group authorisation: the pairing store unlocks DMs only. OpenClaw sandboxing explained is the boundary the DM-versus-group pattern relies on, and OpenClaw in WhatsApp groups the WhatsApp-specific behaviour layered on this model.

On Diali

On Diali the group defaults are the upstream ones for every connected channel: groups restricted until a sender is allowlisted, a mention required, and the final text posted to the room, with the allowlists set from the dashboard. Hosted OpenClaw on Diali is the assistant and OpenClaw on Telegram the channel whose forum topics get their own sessions.

• Policy, allowlist, mention: three gates in that order.
• Allowlists decide who triggers, not what the model sees.
• DMs on the host, groups in a sandbox, never merge untrusted rooms into main.