OpenClaw iMessage access control and routing

iMessage has no native mentions, no server-side allowlists and a chat database that sometimes reports a group as a DM, so OpenClaw's access layer does more work here than on most channels. Here are the DM and group policies, the two group gates that trip most silent setups, mention gating built from the agent's identity, per-group prompts, sessions, ACP bindings, and config writes.

DM and group policies

• The DM policy takes pairing, the default, allowlist, which needs at least one entry, open, which needs the wildcard, and disabled; allowlist entries must identify senders, handles or static sender access groups, while chat targets by chat ID, GUID or identifier belong in the group sender list and numeric chat IDs in the groups registry.
• The group policy takes allowlist, the default, open and disabled, the group sender list can also reference static access groups, an unset group sender list falls back to the DM allowlist while an explicitly empty one blocks every group sender under allowlist, and a completely missing channel block makes the runtime fall back to an allowlist group policy with a warning even when the channel defaults say otherwise.
• Under the allowlist policy group routing runs two gates back to back: the sender allowlist by handle, access group, chat GUID, identifier or ID, where an empty effective list blocks every group sender, and the group registry, enforced once the map has entries, where the chat must match an explicit chat ID entry or a wildcard entry and an empty map leaves the sender list to decide alone.
• Each gate has its own warning naming a different fix: a one-time startup warning per account when the effective sender list is empty, fixed by setting the group sender list or the DM allowlist because adding registry entries alone leaves the first gate blocking, and a one-time per-chat runtime warning when a sender passed the first gate but the chat is missing from a populated registry, fixed by adding that chat ID or the wildcard; the recommended group config sets the allowlist policy, a sender list with the operator's number and a wildcard registry entry requiring a mention.

Replies route back to iMessage using originating channel/target metadata.

Mentions and per-group prompts

iMessage has no native mention metadata, so mention detection uses the agent's configured mention patterns, then the global patterns, and when neither is set derives patterns from the routed agent's identity name and emoji; groups require a mention by default even without explicit patterns, so an allowlisted sender's message can be skipped unless it contains the agent's name or emoji, an explicit empty pattern list at the agent or global level suppresses the identity-derived patterns and leaves iMessage unable to enforce gating, and control commands from authorised senders bypass gating. To process every message from allowed senders in one group you set that chat's mention requirement to false in the map that already supplies the account's group policy, the root map or the account map when it overrides the root, using the numeric chat ID from the imsg chats listing; an empty account map inherits the root only with at most one account configured, account maps replace the whole inherited map so an intentional override must first copy every wildcard and per-group policy, a fresh wildcard entry preserves admission to other groups with their default mention requirement, a restricted map stays restricted, and the sender list still controls access. A skipped unmentioned message logs a warning with the chat ID and the fix, suppressed for repeats by a bounded cache. Each registry entry also accepts a system prompt injected into the agent's system prompt on every turn in that group, resolved like WhatsApp groups: the group's own prompt when the entry exists and defines the key, with an empty string suppressing the wildcard, otherwise the wildcard's prompt, and never for direct messages.

Sessions, bindings, config writes

• DMs use direct routing and groups group routing, DMs collapse into the agent's main session under the default main scope, group sessions are isolated per chat ID, replies route back through the originating channel and target metadata, and a multi-participant thread that arrives flagged as non-group is treated as group traffic, with group gating and isolation, when its chat ID is explicitly configured under the groups registry.
• iMessage chats can be bound to ACP sessions: the spawn command with the bind-here flag inside a DM or allowed group routes future messages in that conversation to the spawned session, the new and reset commands reset the bound session in place, and the close command ends it and removes the binding; persistent bindings are top-level typed entries matching the iMessage channel with a peer ID that is a normalised DM handle, a chat ID, recommended for stable group bindings, a chat GUID or a chat identifier.
• Channel-initiated config writes through the config set and unset commands are allowed by default when the config command is enabled, and the config-writes key set to false disables them.

OpenClaw on iMessage is the channel post these rules belong to, and OpenClaw iMessage setup the pairing flow that admits the first DM.

Two gates, two warnings

Most silent iMessage groups are the first gate: someone lists the chat under groups and never sets a sender list, so every group message is dropped before the registry is consulted, which is why the docs give each gate its own warning text and its own fix. OpenClaw access groups covers the shared access-group entries both lists accept, and OpenClaw Telegram access control the same two-control model on Telegram.

On Diali

iMessage is not among the channels Diali connects today: WhatsApp, Telegram, Discord, Slack, Mattermost, Matrix, SMS and voice. Hosted OpenClaw on Diali is the assistant and Diali security describes the boundary that applies to each connected channel.

• Senders in the allowlists, chat IDs in the registry.
• No mention metadata: the agent's name and emoji are the mention.
• Copy the whole map before overriding it per account.