OpenClaw sessions
How messages are routed, why DMs share one session by default, and the one setting multi-user setups must change
OpenClaw routes every inbound message to a session based on where it came from, and all session state is owned by the Gateway; the clients only ask for it. The docs’ default is built for one person: all direct messages share one rolling conversation, so the assistant remembers what you said on Telegram when you write on WhatsApp. That same default is the first thing a multi-user setup has to change. Here is the routing table, the DM isolation setting and its values, the way to merge one person’s identities, and how groups and rooms are scoped.
How messages are routed
- Direct messages: a shared session by default.
- Group chats: isolated per group by default.
- Rooms and channels: isolated per room by default.
- Cron jobs: a fresh session per run.
- Webhooks: isolated per hook. A global session scope still keeps each agent’s own conversation; the shared key never merges different agents.
If multiple people can message your agent, enable DM isolation.
DM isolation
By default all DMs share one session for continuity, which is fine for one user; the docs’ warning is that without isolation every user shares the same context, and one person’s private messages become visible to another. The DM scope setting has four values: main, the default, where all DMs share the main session; per peer, isolated by sender across channels; per channel and peer, isolated by channel plus sender, which the docs recommend; and per account, channel and peer. Slack’s agent and assistant views are the exception, each visible root getting its own thread session on top. If the same person reaches you from several channels, identity links map their identities to one canonical peer so they share a session, and the security audit command verifies the setup.
Groups, rooms, bindings
- The group scope keeps each group, room or channel in its own channel-scoped session by default, or routes them all into the agent’s main session.
- A route binding can override the global value for one place, for instance a named team room that should join the main conversation while every other room stays apart; the binding wins over the global setting, and it changes session-key selection only.
- Channel docking and manual cross-channel reply focus were removed; identity links and thread-bound sub-agent sessions are the two features that replaced the need, and neither restores manual docking.
OpenClaw memory explained explains what persists across sessions and what does not, and OpenClaw sub-agents the sessions that background runs create.
Why it matters
The session model is a privacy decision dressed as a routing table: the default assumes one owner, and the recommended isolation is one setting away. OpenClaw security best practices lists it with the other checks the audit command runs.
On Diali
On Diali each assistant is one person’s, or one team’s with the isolation set, and the Gateway that owns the sessions is ours to keep. Hosted OpenClaw on Diali is the assistant.
- DMs share, groups isolate, cron starts fresh.
- Per channel and peer is the multi-user setting.
- Identity links merge one person; bindings route one room.
Stop reading about it, build one
Set up an agent, pick a channel, and have it working inside the app you already keep open.
