After viral interest around OpenClaw peaked in March 2026, attention cooled — but over a recent weekend Peter Steinberger, OpenClaw’s creator, and the project’s co-developers released OpenClaw 2.0 (officially v2026.8.1). The update reframes the open-source harness that turns language models into autonomous, messageable agents toward a shared, enterprise-focused platform.
Key additions: rebuilt UI, shared cloud sessions, multiplayer collaboration
OpenClaw 2.0 provides a rebuilt browser-based Control UI that combines conversations, files, approvals, configuration and live agent activity into a single workspace. It introduces shared cloud sessions and multi-user collaboration, and expands the security model with stronger sandboxing, role-based permissions, approval controls, secrets handling and auditing.
The redesigned interface foregrounds conversations: threads appear in a sidebar while the active conversation fills the main workspace; files, approvals, settings and ongoing agent activity remain accessible around it. The goal is to move OpenClaw closer to the conversational interaction model users know from OpenAI’s ChatGPT, Anthropic’s Claude and Google’s Gemini, lowering a key adoption barrier for enterprise users.
Persistent, shareable sessions and collaborative workflows
A major shift in 2.0 is that agent sessions can become persistent workspaces that outlive a single terminal or employee. Sessions can be shared with colleagues, executed across other machines or cloud workers, and supervised through the browser. Multi-user Gateways can track who created a conversation and which prompts were submitted by identified participants; owners and administrators can set whether other users may read a session, suggest edits, work in draft mode or participate directly.
The interface adds session ownership, participant attribution, presence and typing indicators. For engineering teams, this produces a workflow closer to collaborative software development: one developer may start a task and let an agent run it remotely, another can inspect the resulting changes, and a senior engineer or administrator can approve privileged operations. Sessions can move execution to paired devices or cloud workers while keeping the broader workspace intact.
Colin Johnson, CEO of Solvely, described how the multiplayer WebUI changed his team’s workflow: rather than merely sharing access to a bot, developers can open the same live session, see the same history and artifacts, and add missing context directly, so the session itself becomes the handoff document.
Enterprise-oriented security controls and secret handling
OpenClaw 2.0 introduces much finer-grained controls. Approvals can be tied to a specific request, command, session and person; command permissions can be constrained to specific arguments and working directories; for script-backed execution, OpenClaw can verify that the script executed still matches the one originally reviewed. Sessions may run under permission levels such as read-only, guarded, workspace and full-access, with the highest level limited to administrators.
Organizations can define operator roles that require sandboxed execution for sessions created by particular identities. OpenClaw states these requirements cannot be bypassed by elevated execution or host overrides: if the required sandbox cannot be provisioned, execution fails rather than silently falling back to the host.
Credentials receive additional protections. The team-scoped Secret Store distinguishes protected secrets from ordinary environment data; for supported requests, a protected credential can be substituted into a Gateway-hosted HTTPS request without exposing the credential to the model. OpenClaw can reference external systems such as 1Password and Vault. Auditing has been expanded to include execution identity, approvals, session actions and outbound messages; plugin installation can trigger capability reviews for the specific artifact.
These controls address the typical enterprise questions: who initiated an action, which agent performed it, what resources could it access, who approved it, and how permissions transfer when work moves between people or machines.
How OpenClaw compares with NanoClaw
The comparison to NanoClaw and similar projects is now more nuanced. NanoClaw centers operating-system-level containment: agents run inside Docker containers, have explicitly mounted filesystems, run processes as unprivileged users, and can remain isolated rather than sharing files and history by default. Its credential architecture routes supported outbound requests through an Agent Vault so credentials are injected by a gateway rather than placed inside the agent container; it also offers an optional egress-lockdown mode.
OpenClaw 2.0 can reproduce many hardened elements: it supports Docker and Podman sandboxes, per-agent and per-session sandbox scopes, configurable read-only or read-write workspace access, role-enforced sandboxing, remote execution nodes and disposable cloud workers. The crucial difference is posture and defaults: OpenClaw’s documentation explicitly states sandboxing and execution approvals are off by default and that baseline configuration assumes a trusted single operator allowing host execution. NanoClaw treats isolation as more fundamental.
Thus, capability parity is closer than before, but default behavior and architectural philosophy remain different. Enterprises can configure OpenClaw into a hardened environment, but they must do so deliberately.
One Gateway is one trust domain
OpenClaw advises treating a Gateway as a single trust domain. The new multi-user permissions govern collaboration among trusted users but are not a substitute for hard isolation between mutually untrusted tenants. For stronger separation between business units, customers or other security domains, OpenClaw recommends separate Gateway instances called “cells,” each with separate state, credentials and workspaces; fleet tooling for managing those cells is still experimental.
This distinction matters for organizations that want a centrally operated service: role-based access inside one Gateway may suffice for a trusted engineering team, but it differs from a multi-tenant platform that must assume hostile tenants.
Control plane vs. minimal isolation: product tradeoffs
NanoClaw emphasizes a smaller codebase, container isolation and simplicity. OpenClaw 2.0 aims for a broader operational environment: its Control UI combines employee interaction, live execution, files, approvals, terminals, code review, model-provider configuration, devices and shared sessions. That breadth can be an advantage for enterprises that need not just secure agent execution but a usable control plane around it—deployment, authentication, model configuration, auditing and policy enforcement in addition to an interface employees will use.
Community, OpenAI and release context
OpenClaw reports that 933 contributors participated in the release, including 569 first-time contributors, and that the update includes more than 16,000 pull requests—about half of all pull requests ever merged into the project.
Although Peter Steinberger announced on February 14, 2026 that he had joined OpenAI, and OpenAI confirmed his move, OpenClaw was not absorbed into OpenAI. Steinberger said at the time OpenClaw would move to a foundation and remain "open and independent" while receiving OpenAI’s support. OpenClaw now says it is stewarded by the OpenClaw Foundation, an independent 501(c)(3), and lists OpenAI among a group of partners that also includes Microsoft, GitHub, NVIDIA, Atlassian and Tencent. Based on public information, OpenClaw 2.0 is an OpenClaw Foundation release, not an OpenAI product release.
Enterprise readiness depends on configuration
OpenClaw 2.0 does not remove all risks. The project’s documentation notes limitations: Secret Store values are not themselves encrypted at rest and rely on filesystem protections; protected credential substitution does not cover every possible execution path (some raw sockets, containers, remote nodes and provider-native harnesses may be excluded); and multi-user permissions are collaboration controls, not hostile-tenant isolation.
In short, OpenClaw 2.0 supplies many of the primitives—sandboxing, permissions, protected credentials, approvals, identity, auditing and isolated deployments—required to build an enterprise-grade, shared agent platform, and it provides a browser UI that non-engineering staff can use. But making OpenClaw enterprise-ready requires deliberate policies and configuration by the deploying organization. The project’s ambition is clear: to make agents a shared layer where people, models and compute collaborate on the same work rather than simply another personal assistant for every employee.
