OpenClaw 2.0 · Multiuser mode
Multiuser mode turns a single OpenClaw gateway into a service that many people can use at once. Each person gets their own agent, their own conversation, their own memory — while the operator keeps the keys.
The idea
By default, OpenClaw runs one agent for one operator. You connect your channels, talk to the agent, and it holds your continuity: your conversation history, your notes, your memory snapshots.
Multiuser mode relaxes that single-identity assumption. A single running gateway accepts messages from many people, and each person is treated as a separate principal with their own agent instance, their own thread, their own memory, and their own permissions and budget. The gateway becomes a shared service — the operator becomes an administrator of a fleet rather than the only pilot.
Architecture
One connector per service (WhatsApp, Telegram, Discord, Signal, Slack, the terminal REPL, and others). Each adapter turns a raw inbound event into a normalized message and, crucially, stamps it with a stable sender identity — usually a phone number or platform user id.
A single always-on process that binds every adapter together. It resolves senders to users, enforces access and quotas, manages concurrency, routes outbound replies, and writes the audit log. Multiuser mode lives here.
A mapping from channel contact → internal user key. First contact triggers provisioning: the user is created, assigned a role, and asked to be granted access before they can drive an agent.
A user's agent is created on demand from their own context and torn down when idle. Each turn is scoped to that instance, so one user's running task never bleeds into another's.
Histories, notes, and memory snapshots are stored under a per-user key (for example memory/u/<user>). What one user teaches the agent is invisible to every other user.
Capabilities are attached per user, filtered by role. A user whose role allows it may invoke skills and Model Context Protocol tools; a restricted user sees only the safe subset.
Message flow
A person writes to one of the connected channels — a WhatsApp text, a Telegram DM, a chat message, or a line in the terminal.
The channel adapter receives the event and attaches the sender and chat identifiers. These are the only thing the rest of the system trusts as "who is this?"
The gateway normalizes the identifiers into a stable user key and looks it up in its user table. If this is a first contact, it is provisioned on the spot.
The gateway confirms the user's role allows the request and that they are under their token and concurrency budget. If not, the turn is refused with a clear reason.
The agent instance is revived (or created) and given this user's conversation history, memory notes, snapshots, and permitted tools and skills.
The model reasons, then may call skills, tools, or MCP servers and read memory. Tool results feed back into the loop until the agent settles on an answer.
The agent's output is routed by the gateway back onto the same channel, addressed to the same user — never broadcast to other users.
The conversation is appended, memory snapshots are updated, and token usage is recorded against that user's budget. The audit log captures what happened.
Isolation
Users share the runtime but never the state. Everything that could leak one person's data is partitioned behind the user key.
alicememory/u/alice/historymemory/u/alice/notesuser · read-only toolsbobmemory/u/bob/historymemory/u/bob/notesoperator · write & exec toolsWhat they cannot see: Alice cannot read Bob's notes, history, or running tasks — and Bob cannot read Alice's. Only the operator (the superuser) has visibility across every user's namespace, because the operator owns the underlying data.
Access control
| Role | Typical person | What they can do | Tools / skills |
|---|---|---|---|
user |
A guest or team member | Chat with their own agent, use their own memory | Safe subset only |
operator |
A trusted collaborator | The above, plus write and execution tools | Write, execute, browse |
superuser |
You, the operator of the instance | Manage users, roles, quotas, and the whole gateway | Everything, including admin |
Multiuser mode is designed around default-deny: new contacts are blocked until an operator grants them a role. This is the single most important setting to get right.
Configure
Multiuser mode is enabled in your OpenClaw configuration. You switch it on, choose a default policy for unknown senders, and then grant roles to the people you know.
Preferred flow in practice:
deny so strangers cannot use your agent.Illustrative excerpt — schema is defined by your OpenClaw version.
{
"multiuser": {
"enabled": true,
"defaultAccess": "deny",
"users": {
"telegram:123456789": {
"role": "user",
"model": "openclaw",
"quota": { "tokensPerDay": 20000 }
},
"whatsapp:+15550001234": {
"role": "operator",
"quota": { "tokensPerDay": 100000 }
}
}
},
"channels": { "whatsapp": true, "telegram": true }
}Security & operations
Only grant access to people you trust. A stranger using your agent spends your tokens and, with the right tools, reaches your machine.
Set token and concurrency quotas per user. Every concurrent agent consumes model calls and compute; unbounded sharing is how a gateway gets burned.
Execution and write tools are effectively privileges. Give read-only users read-only capabilities; reserve execution for operators you trust.
Per-user namespace isolates users from each other, but not from the operator. Treat the instance as storing the personal data of everyone using it.
API keys, session tokens, and credentials belong in a private env file, never in the repo or in a channel message. Rotate channel sessions regularly.
Keep the audit log on. It is how you learn who used the agent, for what, and at what cost — and it is your first stop when something looks wrong.
Honest limits
Sharing an agent is not always an improvement. If the work is just for you, single-user mode keeps things simpler and more private by construction.
Multiuser mode pays off when you genuinely want many independent principals on one managed runtime — a small team, a shared concierge, a community agent. It costs you operator overhead: granting roles, sizing quotas, watching logs, and sometimes queueing when several agents want the model at once.