Can multiple people share one OpenClaw agent?

Technically yes, but there is no data boundary between them. Conversation history, connected credentials, model spend, and workspace files are all shared. Owner profiles let a shared Gateway tell people apart, but they do not make one person’s activity private from another.

Does OpenClaw support multi-user AI coding?

Not as a tenancy feature. The word multi-user does not appear in the 2026.9.x release notes. Those builds added owner profiles, personal skill libraries, personal connected accounts, and cross-agent session access — useful for a small trusting group, but not per-user isolation.

What is the right setup for a team?

One agent per person is the honest answer for most teams: separate containers, credentials, history and model keys. Share a git remote rather than sharing an agent. If the users are your customers rather than colleagues, use a reseller storefront, where each customer’s instance is scoped by API key.

Do Hermes profiles separate users?

No. Hermes profiles separate configurations — different models, prompts and toolsets you switch between — and they all belong to the single owner. They are not an authentication or privacy boundary.

What does cross-agent session access do?

It makes session tools default to all-session visibility and enables ordinary agent-to-agent access. It widens what agents can see of each other, which helps collaboration between your own agents and is also an exposure surface in a shared setup.

← Home

Guide

Multi-User OpenClaw and Hermes

“Multi-user AI coding” became a breakout search term in September 2026, usually attached to a version number that does not exist. The underlying question is real though: can several people share one agent, and what happens to their data if they do? Here is what the current builds actually support, what they do not, and the three setups that hold up in practice.

The Short Answer

Both OpenClaw and Hermes Agent are built around one agent belonging to one owner. That is the grain of the software. Recent releases have softened it — a shared Gateway can now tell people apart rather than treating every connection as the same anonymous user — but neither project has a tenancy model with per-user permissions, quotas, or data boundaries.

Rule of thumb: if two people would be upset to read each other's chat history, do not put them on one agent. Identity features make a shared Gateway more pleasant; they do not make it private.

What v2026.9.x Actually Added

OpenClaw's September 2026 line introduced the features that the “multi-user coding” posts are loosely describing. They are worth understanding precisely, because each one is narrower than the headline suggests.

Owner profiles. A single-user Gateway connection now carries a durable owner identity with its own preferences, rather than being anonymous. This is about the agent remembering who you are, not about admitting more people.
Personal skill libraries. On a shared Gateway, an individual can keep their own set of skills alongside the workspace-wide ones, so one person's tools do not clutter everyone else's agent.
Personal connected accounts. Likewise for provider accounts — a person can attach their own rather than falling back to the shared default.
Cross-agent session access. Session tools now default to all-session visibility, and ordinary agent-to-agent access is enabled. Read that carefully: this widens visibility between agents. It is a collaboration feature, and in a shared setup it is also an exposure surface.

Taken together these make a shared Gateway usable by a small, mutually-trusting group. None of them adds authentication boundaries, per-user rate limits, or an admin who can see and revoke what others are doing.

Where a Shared Agent Still Leaks

If you put a team on one instance, assume all of the following are common property. This is not a list of bugs; it is how a single-owner agent is designed to work.

Conversation history. Memory and session tools are what make the agent useful across time, and they do not partition by person.
Credentials. A connected Gmail, Slack or GitHub account is connected for the agent, which means for everyone talking to it.
Model spend. Unless each person has attached their own provider account, everyone draws on the shared default key — one bill, no per-person accounting, and a colleague running a long agentic job spends your budget. Personal connected accounts fix the billing question for the people who set one up; they do not fix anything else on this list.
Files and workspace. Anything written to the workspace is readable by the next person who asks for it.
Channel identity. On Telegram or Discord, pairing is per-agent. Once someone is paired, the agent answers them with its full toolset.

Three Patterns That Work

Pattern	Isolation	Best for	Cost shape
One shared agent	None — shared memory, history and credentials	A household, or 2-3 people who already trust each other completely	One instance
One agent per person	Full — separate containers, credentials and history	Teams where each person has their own work and own API keys	One instance per person
Reseller storefront	Full, and scoped by API key so customers never see each other	Selling agents on to your own customers under your brand	One instance per customer, billed to you

1. One shared agent

Fine for a household bot, a family calendar assistant, or two co-founders who share everything anyway. Use owner profiles so the agent addresses people correctly, and use personal skill libraries to stop one person's tools leaking into everyone else's prompts. Do not connect a mailbox you would not forward wholesale.

2. One agent per person

The honest answer for most teams. Each person gets their own instance, own credentials, own history and own model key. It costs more than a shared box and it is the only setup where “can my colleague read this?” has a clean answer. Deploying takes about 30 seconds per person from the dashboard, and agents can still talk to each other where you want them to — see the agent-to-agent guide.

3. Reseller storefront

If the “users” are your customers rather than your colleagues, the tenancy belongs one level up. OpenClaw Launch's reseller setup gives each customer their own instance, scoped by API key so that one customer's credential can never list or reach another's bot. You brand the storefront, we run the containers, and billing rolls up to you.

Hermes Agent

Hermes has the same single-owner shape and the same practical answer. Its profiles system separates configurations — different models, prompts and toolsets you can switch between — which is genuinely useful but is not a user boundary; the profiles all belong to the one owner. See Hermes profiles.

Where Hermes differs usefully is in messaging platforms: because it connects natively to group chats, a common team pattern is one Hermes agent in a shared channel handling genuinely shared work (standups, lookups, on-call), with personal agents kept separate. That splits the difference without pretending the shared bot is private. See Hermes setup and Hermes + Slack.

What About Multi-User Coding Specifically?

For coding work the isolation question is sharper, because a coding agent has a shell. On OpenClaw Launch, coding workspaces are deliberately single-tenant: a workspace belongs to its owner, and API access to it is scoped to keys that were explicitly minted for that product. A general-purpose key does not silently inherit shell and delete authority over someone's dev boxes.

So the shape that works for a team of developers is one workspace per developer, sharing a git remote rather than sharing an agent. That is also how you keep a review trail: commits carry an author, a shared agent's chat history does not.

Related Guides

Is there an OpenClaw 2.0? — where the “2.0 multi-user” claim came from
Resell AI agents — per-customer isolation
Coding workspaces
Agent-to-agent
Hermes profiles
AI team assistant use case