OpenClaw Shared Cloud Sessions: Team Setup Guide

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.

What Shared Sessions Actually Are

The unit of sharing is the session — one ongoing conversation with its accumulated context, tool state, and history. With shared cloud sessions, that session lives in the cloud rather than only on your machine, and a trusted teammate can attach to it from their own device and watch or participate, context intact.

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).

What it is not: a shared account. Your teammate doesn't get your credentials, your channel pairings, or your provider keys. They get the session you invited them into.

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. Instead of every teammate running their own instance (and their own costs, quirks, and skill lists), a trusted group operates one deployment — one VPS, one set of vetted skills, one agent that accumulates institutional knowledge. For a two-to-five-person team this is usually cheaper and better than everyone solo.

Setting Up a Shared Session

The exact UI lives in the 2.0 browser app and follows this flow:

1. Update to 2.0+ — shared sessions don't exist on 1.x, and the SQLite session layer they build on requires the 2.0 upgrade
2. Start the session you want to share — a normal working session with whatever task you have in progress
3. Share from the session — use the share/invite control in the browser app to generate a join link for the session
4. Teammate joins with context intact — they open the link, attach to the session, and see history plus live activity; their messages participate in the same conversation
5. End the share when done — revoke the link so the session is private again

Team-mode configuration (who may join what, across many sessions) is documented in the official docs' team deployment section — the principle is that team mode is a configuration of the same Gateway, not a separate product.

What Gets Shared (and What Doesn't)

Before you click invite, know exactly what your teammate sees:

Shared: the session's conversation history, the task context, files the agent has been working with in that session, tool activity while they're attached, and the agent's responses from the moment they join (and, depending on how far back the share goes, before).

Not shared: your channel pairings (your teammate's WhatsApp/Telegram accounts are not suddenly talking to your agent), your provider API keys, your other sessions, and your OpenClaw configuration. Joining a session grants access to that working context — not to your deployment.

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 — because it contains credentials, private channel messages, or someone else's data — start a fresh, clean session for the collaborative work and keep the sensitive thread private. This is also the cleanest argument for running shared sessions on a dedicated VPS deployment rather than your personal machine: the shared surface stays separate from everything private by construction.

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. Shared sessions widen prompt-injection surface. Your teammate's messages are still just messages — but so is everything the session consumes, and now more people act on its output. Sandboxed tool execution and the usual hardening checklist stop being optional the day you go multiplayer.

3. Watch the spend together. A shared agent burns tokens for the whole team, so put the spending caps and usage alerts from the cost guide on the shared deployment, and agree who owns the bill. (A $6–12 VPS serving a whole small team is one of the best cost/quality trades in self-hosting — see the VPS comparison.)

FAQ

Do teammates need their own OpenClaw install? They need a way to open the shared session — the 2.0 browser app is the intended surface. A full local install isn't required just to join a session.

Can I share a session with someone outside my organization? Technically yes via a join link; practically, treat it as handing them the context of everything in that session. Time-box and revoke.

What happens to a shared session if the host goes offline? Sessions are durable state on the Gateway (SQLite in 2.0), not an in-memory chat — the session survives the host's laptop closing, which is most of the point of handoff workflows.

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.

Related Articles

• OpenClaw 2.0: What's New and Why It Matters
• OpenClaw 2.0 Upgrade Guide: Backup, Migrate, Roll Back
• Best VPS for OpenClaw Self-Hosting
• How Much Does OpenClaw Cost? Real 2026 Budget Breakdown