Introduction

Until 2026, OpenClaw was stubbornly single-player: one operator, one assistant, one context. Shared cloud sessions, introduced in OpenClaw 2.0, change that — a teammate can now join an ongoing agent session with the full context intact: the task, the history, what the agent has already tried, where it got stuck.

The feature came from the project's own pain: the core team kept needing to hand agent tasks to each other and resorted to copy-paste theater. If you've ever screenshotted your agent's progress to ask a colleague "why is it doing this?", this feature is for you. This guide covers what shared sessions are, three workflows they enable, setup, and — because you're now letting a second human into your agent's head — the security rules that matter.

Storage, credential, and trust-boundary details reviewed against the official documentation on October 2, 2026.

What Shared Sessions Actually Are

The unit of collaboration is the session — an ongoing conversation and its working context. The official Cloud Sessions guide describes remote execution: coding work runs on another machine, while the Gateway retains the transcript, last-reconciled workspace, and placement records. Choosing a cloud worker does not move the conversation into an independently hosted chat service.

The README's framing since 2.0: OpenClaw connects models, tools, channels, and apps through a single Gateway, usable by one person or a trusted team, with configuration as the only difference. Sessions themselves are durable SQLite state in 2.0 — which is precisely what makes clean handoff possible (and why the upgrade to 2.0 matters for teams still on 1.x).

Sharing access and choosing an execution host are separate decisions. In remote placements, model requests are proxied through the Gateway so provider credentials are not sent to the worker. That credential routing does not establish a security boundary between people using the same Gateway.

Three Workflows This Unlocks

1. Handoff. You brief the agent on a research or ops task in the morning; a teammate picks it up in the afternoon — the agent already knows the plan, the constraints, and the last twelve steps. No "let me get you up to speed" ritual, no context lost in translation.

2. Pair debugging. Your agent is misbehaving on a long task and you can't tell why. A colleague attaches to the live session, watches what the agent is actually doing, and spots the bad assumption in step four. This is the "why is it doing this?" killer.

3. A small team, one assistant. A trusted group can operate one deployment with a shared set of skills. Estimate hosting and model costs from that team's measured workload before choosing a VPS.

Setting Up a Shared Session

For collaborative work on one Gateway, follow the official team setup:

  1. Give teammates authenticated Gateway access, using Tailscale Serve or an identity-aware trusted proxy.
  2. Connect the team chat with room allowlists and mention gating.
  3. Sign each teammate into the Control UI and assign named roles that define session and agent access.
  4. Open the team session in the Control UI; use its context menu to assign ownership.
  5. Verify with two signed-in people, checking session visibility and presence, then run openclaw security audit on the host.

This is authenticated access to a team Gateway, rather than a public session invitation link.

Read-only sharing from a personal Gateway

The Session Share plugin is a different workflow:

  1. Enable session-share on the source and configure the exact session groups to publish. Move selected sessions into those groups in the source Control UI.
  2. On the receiver, run openclaw plugins enable session-share and openclaw devices join-code.
  3. Connect the source node using the private join URL and a restricted command allowlist:
openclaw connect <join-url> --service \
  --commands openclaw.sessions.list.v1,openclaw.sessions.read.v1
  1. Review and approve the source device on the receiver with openclaw devices list and openclaw devices approve <requestId>.

Both machines need OpenClaw and the plugin. Receiver viewers see user/assistant text only; tool calls and results are omitted. They cannot continue the source session. The catalog polls while the source node is connected. Moving a session out of a published group stops new reads but does not erase text already read. Follow the linked plugin guide for the full source configuration and viewer permissions.

What Gets Shared (and What Doesn't)

Before granting access, review the selected collaboration or read-only sharing workflow:

Working context: review conversation history, files, and tool output before giving a collaborator access. Those materials can contain private channel messages or credentials that were printed by a tool.

Credential location: provider credentials remain with the Gateway in remote placements. This does not guarantee that a collaborator cannot reach private data through the agent's tools. The official security model assumes one trusted operator or mutually trusted team per Gateway.

The practical test before sharing anything: scroll the session history and ask "would I paste this into an email to this person?" If the answer is no, use a fresh session and review its tool access. For people who do not share a trust boundary, use separate Gateways and credentials, ideally separate OS users or hosts. A VPS alone does not separate collaborators from private resources attached to its Gateway.

The Security Rules That Matter Now

Sharing an agent means sharing its context. Three rules keep that sane:

1. "Trusted team" is a technical term. Everyone in a shared session can see what's in it. Don't share a session whose context includes credentials, private messages from channel integrations, or anything you wouldn't put in a shared doc with those same people. If a session is about to involve something sensitive, keep it unshared.

2. Review cross-conversation tool access. Agents with message-tool access can send across conversations and providers by default. Configure the documented messaging restrictions when work must stay in one conversation or provider. Review sandboxed tool execution separately; sharing a session does not confine all tools to that session's data.

3. Watch the spend together. Agree who owns hosting, model, and tool-service bills. Configure the provider's available spending controls and usage alerts, then monitor actual team usage as described in the cost guide.

FAQ

Do teammates need their own OpenClaw install? Team Gateway users open its authenticated Control UI without a local install. Session Share between Gateways requires OpenClaw and the plugin on both machines.

Can I share a session with someone outside my organization? Use authenticated team access with deliberate roles, or the read-only Session Share workflow above. For mutually untrusted users or organizations, deploy separate Gateways rather than adding them to one shared trust boundary.

What happens to a shared session if the host goes offline? Durable storage does not keep an offline Gateway available to collaborators. If a paired execution device goes offline, its placement waits for reconnection; continuing on the Gateway uses the last synced workspace, and unsynced changes can be lost. A cleanly stopped or suspended cloud worker is reconciled first and can be provisioned again on the next message while the Gateway is available. See the Cloud Sessions durability details.

Is this like a group chat with a bot? No. A group-chat bot answers messages; a shared session is a persistent working context — files, history, tool state — that multiple humans steer collaboratively.