OpenClaw dropped v2026.8.1 on August 30, and the project says it contains more than 16,000 pull requests - roughly half its entire lifetime total. The headline feature is shared cloud sessions: a colleague can join an ongoing agent task without losing the context it has built up. Teams are calling it "multiplayer coding." What most of the coverage skips is the sentence OpenClaw put in its own documentation: those controls are not tenant isolation and not a security boundary.
That gap is worth understanding before you hand a shared Gateway the keys to your codebase, credentials, and messaging channels.
What OpenClaw actually is, and what 2.0 adds
OpenClaw is an open-source autonomous AI agent framework that connects large language model inference to real-world execution surfaces: shell command execution, file system access, browser automation, Docker container management, and a wide array of third-party messaging platforms.
Released in November 2025 under the name Clawdbot, it accumulated over 100,000 GitHub stars within weeks, and its architecture organizes around seven interacting components: a Channel System, a central Gateway, a Plugins & Skills System, an Agent Runtime, a Memory & Knowledge System, an LLM Provider, and a Local Execution environment.
Strip away the hype and OpenClaw is a single process that owns your messaging connections and lets an LLM call tools on your behalf. The central component is a long-lived Gateway process - a daemon that stays connected to your messaging channels and exposes a typed WebSocket API to clients.
OpenClaw 2.0 seeks to transform what began largely as a personal agent harness into something designed for teams, shared infrastructure, and enterprise workflows. It introduces a rebuilt browser interface that brings conversations, files, approvals, configuration, and live agent activity into a common workspace, and adds shared cloud sessions and multi-user collaboration.
Shared sessions let owners and administrators decide whether another participant may read, suggest changes, work in a draft, or contribute directly. The handoff keeps the existing context, so a colleague can enter work already in progress instead of starting a separate conversation.
The release follows an unusually long development period: OpenClaw previously shipped 106 releases over 230 days, but development of this update lasted nearly seven weeks as changes originally focused on installation and the browser interface expanded into a broader restructuring of the project.
Beagle in action#eng, mid-sprint handoffThe security model has not changed
Here is the part the launch posts mostly buried. OpenClaw's default security model is one trusted operator boundary per Gateway, not hostile multi-tenant isolation inside one shared Gateway. Hosting users or organizations that do not share a trust boundary therefore means running a separate complete OpenClaw instance for each tenant.
OpenClaw can run tool execution inside a sandbox backend to reduce blast radius. Sandboxing is off by default and controlled by agents.defaults.sandbox (global), agents.entries.*.sandbox (per-agent), or a required creator-role sandbox policy.
OpenClaw's documentation explicitly says sandboxing and execution approvals are off by default. Its baseline configuration assumes a trusted single operator and permits host execution unless administrators configure stronger restrictions.
The practical consequence: if two people who do not fully trust each other share a Gateway, they share a trust domain. Those settings govern collaboration inside one OpenClaw Gateway. They do not separate hostile customers. One Gateway is one trust domain, and tenants need separate Gateways. Sandboxing is off by default, leaving hardened deployments dependent on configuration outside the new multiplayer controls.
Exec approvals are guardrails for operator intent, not hostile multi-tenant isolation. OpenClaw's product default for trusted single-operator setups is that host exec on gateway/node is allowed without approval prompts. That default is intentional UX, not a vulnerability by itself. The problem is not that OpenClaw is dishonest about this - the docs are clear. The problem is that "multiplayer" framing makes teams reach for a shared Gateway when the project's own architecture calls for separate ones.
What the ecosystem risk looks like
The 2.0 release lands in a project that already has a documented security track record. Prior analyses by Cisco Talos and Kaspersky Labs assessed 36% of ClawHub marketplace skills as containing prompt injections, and Cyera disclosed CVE-2026-65105 in NemoClaw's local Ollama server.
OpenClaw supports a modular skill ecosystem in which third-party skills extend agent functionality. Skills can register lifecycle hooks that intercept internal agent events. In particular, the agent:bootstrap hook allows a skill to modify the agent's initialization context by injecting guidance files.
In a shared session, one user's installed skills inject into the same initialization context that every collaborator's prompts run against.
A new protected credentials feature has been added that allows users to share credentials with agents in shared environments without exposing them in chat. That is a real improvement. It does not address the broader question of what an agent can do with those credentials once it has them, across a shared session, without sandboxing enabled.
The legitimate use case for shared sessions is a team of engineers who already trust each other completely and are working on the same codebase - something OpenClaw's own team validated by eating its own cooking. Peter Steinberger said the team had spent two months trying to "build OpenClaw with OpenClaw" and had shifted from individual local coding harnesses toward team.openclaw.ai, a shared agent environment. A group of trusted collaborators sharing a Gateway is exactly what the architecture is designed for.
What to configure before sharing a session
If you are deploying OpenClaw 2.0 for a team, the actual checklist is short but non-negotiable:
Enable sandboxing explicitly. Set
agents.defaults.sandbox.modetoall. The Gateway process always stays on the host; only tool execution moves into the sandbox when enabled.One Gateway per trust boundary. Hosting users or organizations that do not share a trust boundary means running a separate complete instance for each. Fleet calls each isolated instance a "cell" - a full Gateway in a hardened container with its own state, credentials, workspace, and loopback-only host port.
Deny high-risk tools by default. Tools like
exec,browser,web_fetch,gateway,nodes, andcronshould be denied unless explicitly required.Audit your ClawHub skills. A third-party skill with a bootstrap hook can modify initialization context before any shared collaborator sends a prompt.
Protect credentials at the session level. The new protected credentials feature keeps secrets out of chat logs but not out of the agent runtime's reach.
The Gateway stays on the host; tool execution runs in an isolated sandbox when enabled. This is not a perfect security boundary, but it materially limits filesystem and process access when the model does something dumb. That honest caveat from the official docs is a useful frame: sandboxing shrinks the blast radius, it does not eliminate it.
The net read on OpenClaw 2.0 is genuinely positive for the right team in the right posture. Shared context across collaborators solves a real problem. But "multiplayer" is not the same as "multi-tenant," and the gap between those two things is exactly where teams get burned.
OpenClaw shared cloud sessions: common questions
What are OpenClaw shared cloud sessions?
Shared cloud sessions let multiple users join a single OpenClaw agent instance mid-task, with the full conversation history and tool call context intact. Owners can grant read, suggest, draft, or direct participation rights. The feature is new in v2026.8.1 and gives OpenClaw rough feature parity with enterprise collaboration in frontier-lab harnesses.
Are OpenClaw shared sessions safe for teams with different trust levels?
No. OpenClaw's own documentation states that shared session controls are not tenant isolation and not a security boundary. One Gateway equals one trust domain. Teams with different trust levels - different departments, external contractors - need separate Gateway instances, not separate sessions inside one.
Is sandboxing enabled by default in OpenClaw 2.0?
No. Sandboxing is opt-in in OpenClaw 2.0. You must explicitly set agents.defaults.sandbox.mode to enable it. Without sandboxing, the agent can execute shell commands, read and write files, and manage Docker containers directly on the host machine.
How do you run multiple tenants on OpenClaw?
OpenClaw's fleet tooling creates isolated "cells" - separate Gateway instances, each with its own credentials, state, workspace, and loopback port. For truly hostile tenants, the project's own documentation recommends separate OS users or physical hosts. Session-level permissions inside a shared Gateway do not substitute for this.
What changed in OpenClaw 2.0 beyond shared sessions?
The release also rebuilds the browser interface around a unified workspace, simplifies onboarding by detecting existing API keys and subscriptions, consolidates model provider administration, adds a protected credentials store for shared environments, and ships support for GPT-6 Astra as a model option. Session state storage moved from in-memory to SQLite.