mirror of
https://github.com/openclaw/openclaw.git
synced 2026-08-17 08:02:12 -06:00
cd0a1235a3
* feat(gateway): add identity preferences and project recents * feat(ui): sync new-session identity state * docs: explain identity-scoped session state * test: track preference temp directories * fix(gateway): preserve identity preference boundaries * chore(protocol): refresh identity preference bindings * test: refresh historical schema hashes * style(gateway): format method order assertion * fix(protocol): emit project recent Swift models * test(gateway): track preference RPC release train * fix(gateway): harden identity preference state * fix(state): keep preference errors internal * chore: refresh split plugin SDK baseline * fix(gateway): use core session store loader * refactor(state): fold additive migration checks * chore: regenerate plugin SDK baseline * chore: regenerate plugin SDK baseline * chore: regenerate plugin SDK baseline * chore: regenerate plugin SDK baseline * chore: regenerate plugin SDK baseline * chore: regenerate plugin SDK baseline * chore: regenerate plugin SDK baseline * test(ui): relocate identity recents e2e * chore: regenerate plugin SDK baseline * chore: regenerate plugin SDK baseline * chore: regenerate plugin SDK baseline * chore: regenerate plugin SDK baseline * chore: regenerate plugin SDK baseline
52 lines
3.2 KiB
Markdown
52 lines
3.2 KiB
Markdown
---
|
|
summary: "How session ownership and presence work when several people operate one agent"
|
|
read_when:
|
|
- You share one OpenClaw agent with other operators
|
|
- You need to understand session owner and presence indicators
|
|
- You are deciding whether one shared agent provides enough isolation
|
|
title: "Multi-user mode"
|
|
---
|
|
|
|
Multi-user mode lets several trusted people operate the same OpenClaw agent. It adds session ownership, live presence, and creator filtering so a team can tell who started work and who is currently watching it.
|
|
|
|
## Trust boundary
|
|
|
|
Everyone who can operate an agent can make it do anything that agent can do. Session ownership, visibility in the sidebar, and presence indicators are usability features, not security boundaries.
|
|
|
|
If people must not access each other's sessions, tools, credentials, or files, give them separate agents or separate gateway/host trust boundaries. Do not rely on owner avatars or filters for isolation.
|
|
|
|
## Ownership and presence
|
|
|
|
New sessions record a write-once `createdActor` when the creation path can prove who caused it. Authenticated people use their durable Gateway profile id; requesting agents and system paths use the same actor field. Sessions created without a proven actor remain unattributed.
|
|
|
|
Human display names are resolved from the current Gateway profile when session rows are returned. OpenClaw does not store labels on session entries, so changing a profile name updates the ownership UI without rewriting session history.
|
|
|
|
The web app keeps ownership and presence visually distinct:
|
|
|
|
- A solid owner avatar is permanent for the lifetime of that session.
|
|
- Ringed or translucent presence avatars show people who are currently connected or watching.
|
|
- The sidebar's person filter shows sessions created by one identity while preserving the existing custom groups.
|
|
|
|
When fewer than two distinct creators appear in the loaded session list, OpenClaw hides all ownership and person-filter chrome. A single-user gateway therefore looks unchanged.
|
|
|
|
## Identity-scoped convenience state
|
|
|
|
When a connection has a durable Gateway profile, new-session preferences and picker recents follow that person across browsers. Preferences remain per agent, while recents are derived only from sessions that person created. Connections without a durable identity keep browser-local preferences and derive recents from the loaded session roster.
|
|
|
|
This state improves continuity; it is not an authorization or isolation boundary. Operator scopes still control actions, and a shared Gateway remains one trust domain for sessions, tools, credentials, and files.
|
|
|
|
## Drafts
|
|
|
|
Start a session as a draft to keep work in progress out of teammates' sidebars until you publish it. Drafts are never hidden from admins, who see other people's drafts with a faded ghost marker. This is a coordination feature, not a security boundary.
|
|
|
|
## Turn attribution
|
|
|
|
Turn sender attribution is best-effort. Steering can merge input into an active turn, so the transcript cannot always represent each person's contribution as a separate turn.
|
|
|
|
## Related
|
|
|
|
- [The main session](/concepts/main-session)
|
|
- [Session management](/concepts/session)
|
|
- [Presence](/concepts/presence)
|
|
- [Gateway security](/gateway/security)
|