The viral fervor we saw earlier this year around OpenClaw, the open source AI harness that turns powerful language models into autonomous workers the user can message via their favorite channels (Telegram, iMessage, WhatsApp, Discord etc), has cooled off substantially from its peak in March 2026.
But over the weekend, OpenClaw’s creator Peter Steinberger and current team of co-developers gave the world — especially enterprises — a reason to look at it again, announcing OpenClaw 2.0, billed as the most significant update to the harness and surrounding platform yet.
OpenClaw 2.0 seeks to transform what began largely as a personal agent harness into something increasingly designed for teams, shared infrastructure and enterprise workflows.
OpenClaw 2.0 introduces a rebuilt browser interface that brings conversations, files, approvals, configuration and live agent activity into a common workspace. It adds shared cloud sessions and multi-user collaboration. And it expands the security model with stronger sandboxing, role-based permissions, approval controls, secrets handling and auditing.
Together, those additions move OpenClaw closer to being infrastructure that an organization could deploy for employees rather than simply a powerful agent an individual developer runs locally.
They also sharpen a competitive question surrounding the project: whether OpenClaw has addressed the security and isolation concerns that helped inspire newer alternatives such as NanoClaw.
The answer is increasingly yes at the capability level — but not necessarily by default.
OpenClaw wants to become the shared agent layer
Released under the official name of v2026.8.1, the update spans installation, messaging, memory, skills, models, automations, browser and native applications, plugins and security.
Steinberger described the development of OpenClaw 2.0 as an exercise in using the product to build itself.
“Two months ago, we started the mission to ‘build OpenClaw with OpenClaw,’” Steinberger wrote on X early on August 31.
Over that period, he said, OpenClaw gradually moved its team away from individual local coding harnesses and toward team.openclaw.ai, a shared agent environment aware of what team members are working on.
“Multiplayer coding + infinite compute with nodes and cloud sessions has been a game changer for how we build,” Steinberger wrote, adding that local harnesses now “feel like relics of the past.”
That claim points toward one of the more important changes in OpenClaw’s enterprise proposition.
The dominant model for AI coding agents has generally been individual: a developer runs an agent in a terminal, IDE or desktop application, gives it access to a repository and lets it execute work within that environment.
OpenClaw 2.0 is pushing toward something different. Agent sessions can become persistent workspaces that outlive a single terminal or employee. They can be shared with colleagues, executed across other machines or cloud workers, and supervised through a browser.
For enterprises, that potentially turns the agent from an employee-level productivity application into a shared operational layer.
A new UI could broaden OpenClaw beyond developers
The redesigned Control UI is central to that strategy.
OpenClaw has shifted away from an Overview-first web application and made conversations the primary interface. Threads sit in a sidebar, while the active conversation occupies the main workspace. Files, approvals, settings and ongoing agent activity remain accessible around it.
The design deliberately brings OpenClaw closer to the interaction model employees already know from OpenAI’s ChatGPT, Anthropic’s Claude, Google’s Gemini and other conversational AI products.
That lowers an important barrier to enterprise adoption. Open-source agent frameworks are often powerful precisely because they expose low-level configuration, terminals, tools and runtime controls. Those same characteristics can make them difficult to deploy beyond engineering organizations.
OpenClaw 2.0 attempts to preserve the underlying control while putting a conversational interface on top of it. An employee can ask an agent to perform work without treating the terminal as the primary product interface. But OpenClaw does not hide what is happening underneath. The Control UI can surface session files, terminal activity, Git-backed changes, pull-request state, browser activity and interactive dashboards.
The release also places more emphasis on observability during agent execution. Tool calls and results are paired more clearly, file changes can appear as focused diffs, command activity is easier to inspect, and long-running background tasks can remain visible alongside the conversation. That combination matters for enterprise use.
Employees get a simpler interface for delegating work. Technical users retain access to the artifacts and execution state behind the conversation. Administrators gain a centralized place to configure and supervise the system.
The redesigned Settings workspace now encompasses agents, memory, plugins, MCP servers, devices, communication channels and device pairing. OpenClaw also consolidates model-provider administration, including credential status and, where providers expose it, model availability, quota, account balance, budget and spending information.
Limited-access browser users can request administrator privileges rather than automatically receiving them, with another administrator required to approve the escalation.
These are not especially flashy agent features. For companies deploying AI systems to dozens or hundreds of employees, they may be among the most important additions in the release.
Multiplayer sessions turn agent context into shared context
OpenClaw 2.0 also expands the agent from a personal workspace into a collaborative one.
Shared cloud sessions allow another employee to enter work already in progress without discarding the context accumulated by the agent.
Multi-user Gateways — the service that connects users and agents to tools, files, credentials and other resources — can track who created a conversation and which prompts were submitted by identified participants.
Owners and administrators can determine whether another user can read a session, suggest changes, work in draft mode or participate directly.
The interface adds session ownership, participant attribution, presence and even typing indicators. For coding teams, that introduces a workflow closer to collaborative software development than traditional AI chat.
A developer could initiate a task and allow an agent to work on it remotely. Another engineer could inspect the resulting changes. A senior engineer or administrator could approve an operation requiring additional privileges. The work does not have to remain attached to the laptop or terminal where it started.
Sessions can also move execution to paired devices or cloud workers while maintaining the broader workspace.
For enterprises experimenting with long-running agents, that is significant. Persistent agents need mechanisms for shift changes, escalation, supervision and ownership transfer. Otherwise, organizations simply create fleets of personal agents whose state disappears into individual user environments.
OpenClaw is attempting to turn that state into collaborative infrastructure. Already, some teams outside the developers of the open source project are adopting it.
Colin Johnson, CEO of marketing metrics software firm Solvely, described a similar shift in his own development workflow in a post on X.
His team had already been using OpenClaw agents through Discord, where developers could assign tasks, run commands and interact with their development environment. But he said that model still felt like “messaging a bot”: developers could share access to an agent without actually sharing the agent’s working context.
The new multiplayer WebUI changed that, he wrote, because two developers could open the same live session, see the same history and artifacts, and add information without first exporting or reconstructing what the agent had already done. “We were working inside the same context,” Colin wrote.
In one example, another developer was taking over a project he had been working on; instead of preparing a traditional handoff document, Colin joined the developer’s existing agent thread and added the missing project context directly. “The session itself became the handoff document,” he wrote.
For enterprise teams, that is a useful illustration of why persistent multiplayer sessions may matter beyond convenience: agent context can become a shared work artifact rather than information trapped inside one employee’s private conversation.
Colin’s deployment also illustrates both the enterprise potential and the remaining security boundary. His team runs its OpenClaw Gateway on a development server reachable through GitHub authentication, Cloudflare Access and a Cloudflare Tunnel, with the Gateway itself listening only on the server’s loopback interface rather than an exposed public port.
But he explicitly cautioned that this does not make the shared Gateway a multitenant environment. The developers already trust one another with the repositories, tools and agent capabilities behind it. As he put it, Cloudflare controls who can enter the workspace, while OpenClaw tracks who created, owns or contributed to the work; stronger separation still requires separate infrastructure.
Security becomes much more enterprise-oriented
That shift creates a corresponding security problem: a shared agent can potentially act with broader organizational authority than one running on a developer laptop.
OpenClaw 2.0 responds with considerably more granular controls.
Approvals can now 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 being executed still matches what was originally reviewed.
Sessions can operate under different permission levels, including read-only, guarded, workspace and full-access modes, with the highest level restricted to administrators.
Organizations can also define operator roles that require sandboxed execution for sessions created by specific identities. OpenClaw says those requirements cannot be bypassed using 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 protection.
OpenClaw’s team-scoped Secret Store distinguishes protected secrets from ordinary environment data available to the agent. For supported requests, a protected credential can be substituted into a Gateway-hosted HTTPS request without exposing that credential directly to the model.
OpenClaw can also reference external systems including 1Password and Vault.
Auditing has expanded around execution identity, approvals, session actions and outbound messages. Plugin installation can trigger capability reviews associated with the specific artifact being installed.
Those controls address questions enterprises inevitably face when deploying agents: Who initiated an action? Which agent performed it? What resources could it access? Who approved the operation? And what happens to those permissions when work moves between people or machines?
NanoClaw still takes a different approach to security
OpenClaw’s changes also make the comparison with open source, enterprise-friendly rival NanoClaw more nuanced.
NanoClaw is one of several subsequent projects to emerge around the idea that AI agents need stronger isolation and simpler security boundaries. Its architecture places operating-system-level containment at the center of the design.
NanoClaw runs agents inside Docker containers, limits those containers to explicitly mounted filesystems and runs their processes as an unprivileged user. Sessions and agent groups can remain isolated rather than automatically sharing files and conversation history.
Its credential architecture follows the same principle. Supported outbound requests can pass through OneCLI’s Agent Vault, allowing credentials to be injected by a gateway rather than placed inside the agent container itself. NanoClaw also provides an optional egress-lockdown mode that puts agents on an internal Docker network and routes supported external traffic through the gateway.
OpenClaw 2.0 can now reproduce many elements of that hardened model. 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 key difference is the starting posture. 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. NanoClaw makes isolation more fundamental to how agent execution is structured.
So does OpenClaw 2.0 have security parity with NanoClaw?
In terms of available controls, it is much closer than before. In terms of defaults and architectural philosophy, no. An enterprise can configure OpenClaw into a substantially hardened environment, but it has to make that decision deliberately.
One Gateway is still one trust domain
Another limitation is particularly important for larger organizations. OpenClaw says a Gateway should be treated as a single trust domain.
Its new multi-user permissions are designed to govern collaboration among trusted users. They should not be treated as hard isolation between mutually untrusted tenants.
For organizations requiring stronger separation — between business units, customers or other security domains, for example — OpenClaw recommends separate Gateway instances, described as “cells,” with separate state, credentials and workspaces.
Fleet tooling for managing those cells remains experimental.
That distinction could matter significantly for enterprises considering OpenClaw as a centrally operated service.
Role-based access inside one Gateway may be sufficient for a trusted engineering department or internal team. It is a different proposition from a multi-tenant platform intended to isolate customers or users who should be assumed hostile to one another.
NanoClaw has its own configuration requirements and limitations, and even its stronger outbound-network lockdown remains optional. But its smaller architecture and container-centric execution model may appeal to organizations that want a narrower security boundary that is easier to reason about.
OpenClaw is optimizing for a broader problem.
OpenClaw’s biggest advantage may be the control plane
The tradeoff is product breadth.
NanoClaw emphasizes a relatively small codebase, container isolation and customization through code and skills. Its second-generation architecture supports owner, administrator and member roles, and a separate monitoring dashboard can provide visibility into deployments.
OpenClaw 2.0 is trying to build a much broader operational environment.
Its Control UI combines employee interaction, live execution, files, approvals, terminals, code review, model-provider configuration, devices and shared sessions.
That gives OpenClaw a potential advantage for enterprises that need not only secure agent execution but a usable control plane around it.
Security teams care about isolation. Platform teams also need deployment, authentication, model configuration, auditing and policy enforcement. Employees need an interface they can actually use. Managers need a way to understand what is running. Developers need access to the underlying files and tools when something goes wrong.
OpenClaw 2.0 increasingly tries to serve all of those constituencies through one system.
What is OpenAI’s role?
OpenClaw says 933 contributors, including 569 first-time contributors, participated in the release, which includes more than 16,000 pull requests — roughly half of all pull requests ever merged into the project.
Interestingly, the release was not shared by Steinberger’s employer, OpenAI. Recall that the Austrian developer announced on Feb. 14, 2026 that he was joining OpenAI to work on bringing agents to a broader audience, a move OpenAI CEO Sam Altman publicly confirmed the following day.
But OpenClaw was not folded into OpenAI. Steinberger said at the time that OpenClaw would move to a foundation and “stay open and independent,” while OpenAI would support the project. OpenClaw now says it is stewarded by the OpenClaw Foundation, an independent 501(c)(3), with OpenAI listed alongside Microsoft, GitHub, NVIDIA, Atlassian, Tencent and other organizations as partners.
Based on the available public information, OpenClaw 2.0 should therefore be understood as an OpenClaw Foundation release, not an OpenAI product or OpenAI software release, despite Steinberger’s employment at OpenAI and OpenAI’s financial and organizational support for the project.
Enterprise readiness now depends on configuration
OpenClaw 2.0 does not eliminate the security risks associated with autonomous agents, and its own documentation identifies limitations.
Secret Store values, for example, are not themselves encrypted at rest and rely on filesystem protections. Protected credential substitution does not cover every possible execution path, including some raw sockets, containers, remote nodes and provider-native harnessesIts multi-user permissions are collaboration controls, not hostile-tenant isolation.
Those caveats should prevent enterprises from interpreting OpenClaw 2.0 as secure-by-default agent infrastructure.But they also illustrate how much the conversation around the project has changed. The relevant comparison is increasingly not simply OpenClaw versus NanoClaw. It is a container-first, constrained system such as NanoClaw versus a deliberately hardened OpenClaw deployment that provides a substantially broader employee and administrator experience.
NanoClaw retains a strong proposition for organizations prioritizing a small attack surface, container-first execution and architectural simplicity.
OpenClaw is making another bet: that enterprises ultimately need an agent platform to function as both runtime and workplace.
OpenClaw 2.0 provides many of the primitives needed to build that environment — sandboxing, permissions, protected credentials, approvals, identity, auditing and isolated deployments — alongside a browser interface designed to make the system accessible to employees who will never configure an agent from a terminal.
The remaining caveat is important: enterprises have to turn those primitives into policy. OpenClaw 2.0 doesn’t automatically make OpenClaw enterprise-ready, but it does make an enterprise-grade OpenClaw deployment far easier out-of-the-box.
And as Steinberger’s description of OpenClaw’s own development process suggests, the long-term ambition may be larger still. Rather than giving every employee another AI assistant, OpenClaw is positioning the agent itself as shared infrastructure — a persistent layer where people, models and compute collaborate on the same work.
The viral fervor we saw earlier this year around OpenClaw, the open source AI harness that turns powerful language models into autonomous workers the user can message via their favorite channels (Telegram, iMessage, WhatsApp, Discord etc), has cooled off substantially from its peak in March 2026.
But over the weekend, OpenClaw’s creator Peter Steinberger and current team of co-developers gave the world — especially enterprises — a reason to look at it again, announcing OpenClaw 2.0, billed as the most significant update to the harness and surrounding platform yet.
OpenClaw 2.0 seeks to transform what began largely as a personal agent harness into something increasingly designed for teams, shared infrastructure and enterprise workflows.
OpenClaw 2.0 introduces a rebuilt browser interface that brings conversations, files, approvals, configuration and live agent activity into a common workspace. It adds shared cloud sessions and multi-user collaboration. And it expands the security model with stronger sandboxing, role-based permissions, approval controls, secrets handling and auditing.
Together, those additions move OpenClaw closer to being infrastructure that an organization could deploy for employees rather than simply a powerful agent an individual developer runs locally.
They also sharpen a competitive question surrounding the project: whether OpenClaw has addressed the security and isolation concerns that helped inspire newer alternatives such as NanoClaw.
The answer is increasingly yes at the capability level — but not necessarily by default.
OpenClaw wants to become the shared agent layer
Released under the official name of v2026.8.1, the update spans installation, messaging, memory, skills, models, automations, browser and native applications, plugins and security.
Steinberger described the development of OpenClaw 2.0 as an exercise in using the product to build itself.
“Two months ago, we started the mission to ‘build OpenClaw with OpenClaw,’” Steinberger wrote on X early on August 31.
Over that period, he said, OpenClaw gradually moved its team away from individual local coding harnesses and toward team.openclaw.ai, a shared agent environment aware of what team members are working on.
“Multiplayer coding + infinite compute with nodes and cloud sessions has been a game changer for how we build,” Steinberger wrote, adding that local harnesses now “feel like relics of the past.”
That claim points toward one of the more important changes in OpenClaw’s enterprise proposition.
The dominant model for AI coding agents has generally been individual: a developer runs an agent in a terminal, IDE or desktop application, gives it access to a repository and lets it execute work within that environment.
OpenClaw 2.0 is pushing toward something different. Agent sessions can become persistent workspaces that outlive a single terminal or employee. They can be shared with colleagues, executed across other machines or cloud workers, and supervised through a browser.
For enterprises, that potentially turns the agent from an employee-level productivity application into a shared operational layer.
A new UI could broaden OpenClaw beyond developers
The redesigned Control UI is central to that strategy.
OpenClaw has shifted away from an Overview-first web application and made conversations the primary interface. Threads sit in a sidebar, while the active conversation occupies the main workspace. Files, approvals, settings and ongoing agent activity remain accessible around it.
The design deliberately brings OpenClaw closer to the interaction model employees already know from OpenAI’s ChatGPT, Anthropic’s Claude, Google’s Gemini and other conversational AI products.
That lowers an important barrier to enterprise adoption. Open-source agent frameworks are often powerful precisely because they expose low-level configuration, terminals, tools and runtime controls. Those same characteristics can make them difficult to deploy beyond engineering organizations.
OpenClaw 2.0 attempts to preserve the underlying control while putting a conversational interface on top of it. An employee can ask an agent to perform work without treating the terminal as the primary product interface. But OpenClaw does not hide what is happening underneath. The Control UI can surface session files, terminal activity, Git-backed changes, pull-request state, browser activity and interactive dashboards.
The release also places more emphasis on observability during agent execution. Tool calls and results are paired more clearly, file changes can appear as focused diffs, command activity is easier to inspect, and long-running background tasks can remain visible alongside the conversation. That combination matters for enterprise use.
Employees get a simpler interface for delegating work. Technical users retain access to the artifacts and execution state behind the conversation. Administrators gain a centralized place to configure and supervise the system.
The redesigned Settings workspace now encompasses agents, memory, plugins, MCP servers, devices, communication channels and device pairing. OpenClaw also consolidates model-provider administration, including credential status and, where providers expose it, model availability, quota, account balance, budget and spending information.
Limited-access browser users can request administrator privileges rather than automatically receiving them, with another administrator required to approve the escalation.
These are not especially flashy agent features. For companies deploying AI systems to dozens or hundreds of employees, they may be among the most important additions in the release.
Multiplayer sessions turn agent context into shared context
OpenClaw 2.0 also expands the agent from a personal workspace into a collaborative one.
Shared cloud sessions allow another employee to enter work already in progress without discarding the context accumulated by the agent.
Multi-user Gateways — the service that connects users and agents to tools, files, credentials and other resources — can track who created a conversation and which prompts were submitted by identified participants.
Owners and administrators can determine whether another user can read a session, suggest changes, work in draft mode or participate directly.
The interface adds session ownership, participant attribution, presence and even typing indicators. For coding teams, that introduces a workflow closer to collaborative software development than traditional AI chat.
A developer could initiate a task and allow an agent to work on it remotely. Another engineer could inspect the resulting changes. A senior engineer or administrator could approve an operation requiring additional privileges. The work does not have to remain attached to the laptop or terminal where it started.
Sessions can also move execution to paired devices or cloud workers while maintaining the broader workspace.
For enterprises experimenting with long-running agents, that is significant. Persistent agents need mechanisms for shift changes, escalation, supervision and ownership transfer. Otherwise, organizations simply create fleets of personal agents whose state disappears into individual user environments.
OpenClaw is attempting to turn that state into collaborative infrastructure. Already, some teams outside the developers of the open source project are adopting it.
Colin Johnson, CEO of marketing metrics software firm Solvely, described a similar shift in his own development workflow in a post on X.
His team had already been using OpenClaw agents through Discord, where developers could assign tasks, run commands and interact with their development environment. But he said that model still felt like “messaging a bot”: developers could share access to an agent without actually sharing the agent’s working context.
The new multiplayer WebUI changed that, he wrote, because two developers could open the same live session, see the same history and artifacts, and add information without first exporting or reconstructing what the agent had already done. “We were working inside the same context,” Colin wrote.
In one example, another developer was taking over a project he had been working on; instead of preparing a traditional handoff document, Colin joined the developer’s existing agent thread and added the missing project context directly. “The session itself became the handoff document,” he wrote.
For enterprise teams, that is a useful illustration of why persistent multiplayer sessions may matter beyond convenience: agent context can become a shared work artifact rather than information trapped inside one employee’s private conversation.
Colin’s deployment also illustrates both the enterprise potential and the remaining security boundary. His team runs its OpenClaw Gateway on a development server reachable through GitHub authentication, Cloudflare Access and a Cloudflare Tunnel, with the Gateway itself listening only on the server’s loopback interface rather than an exposed public port.
But he explicitly cautioned that this does not make the shared Gateway a multitenant environment. The developers already trust one another with the repositories, tools and agent capabilities behind it. As he put it, Cloudflare controls who can enter the workspace, while OpenClaw tracks who created, owns or contributed to the work; stronger separation still requires separate infrastructure.
Security becomes much more enterprise-oriented
That shift creates a corresponding security problem: a shared agent can potentially act with broader organizational authority than one running on a developer laptop.
OpenClaw 2.0 responds with considerably more granular controls.
Approvals can now 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 being executed still matches what was originally reviewed.
Sessions can operate under different permission levels, including read-only, guarded, workspace and full-access modes, with the highest level restricted to administrators.
Organizations can also define operator roles that require sandboxed execution for sessions created by specific identities. OpenClaw says those requirements cannot be bypassed using 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 protection.
OpenClaw’s team-scoped Secret Store distinguishes protected secrets from ordinary environment data available to the agent. For supported requests, a protected credential can be substituted into a Gateway-hosted HTTPS request without exposing that credential directly to the model.
OpenClaw can also reference external systems including 1Password and Vault.
Auditing has expanded around execution identity, approvals, session actions and outbound messages. Plugin installation can trigger capability reviews associated with the specific artifact being installed.
Those controls address questions enterprises inevitably face when deploying agents: Who initiated an action? Which agent performed it? What resources could it access? Who approved the operation? And what happens to those permissions when work moves between people or machines?
NanoClaw still takes a different approach to security
OpenClaw’s changes also make the comparison with open source, enterprise-friendly rival NanoClaw more nuanced.
NanoClaw is one of several subsequent projects to emerge around the idea that AI agents need stronger isolation and simpler security boundaries. Its architecture places operating-system-level containment at the center of the design.
NanoClaw runs agents inside Docker containers, limits those containers to explicitly mounted filesystems and runs their processes as an unprivileged user. Sessions and agent groups can remain isolated rather than automatically sharing files and conversation history.
Its credential architecture follows the same principle. Supported outbound requests can pass through OneCLI’s Agent Vault, allowing credentials to be injected by a gateway rather than placed inside the agent container itself. NanoClaw also provides an optional egress-lockdown mode that puts agents on an internal Docker network and routes supported external traffic through the gateway.
OpenClaw 2.0 can now reproduce many elements of that hardened model. 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 key difference is the starting posture. 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. NanoClaw makes isolation more fundamental to how agent execution is structured.
So does OpenClaw 2.0 have security parity with NanoClaw?
In terms of available controls, it is much closer than before. In terms of defaults and architectural philosophy, no. An enterprise can configure OpenClaw into a substantially hardened environment, but it has to make that decision deliberately.
One Gateway is still one trust domain
Another limitation is particularly important for larger organizations. OpenClaw says a Gateway should be treated as a single trust domain.
Its new multi-user permissions are designed to govern collaboration among trusted users. They should not be treated as hard isolation between mutually untrusted tenants.
For organizations requiring stronger separation — between business units, customers or other security domains, for example — OpenClaw recommends separate Gateway instances, described as “cells,” with separate state, credentials and workspaces.
Fleet tooling for managing those cells remains experimental.
That distinction could matter significantly for enterprises considering OpenClaw as a centrally operated service.
Role-based access inside one Gateway may be sufficient for a trusted engineering department or internal team. It is a different proposition from a multi-tenant platform intended to isolate customers or users who should be assumed hostile to one another.
NanoClaw has its own configuration requirements and limitations, and even its stronger outbound-network lockdown remains optional. But its smaller architecture and container-centric execution model may appeal to organizations that want a narrower security boundary that is easier to reason about.
OpenClaw is optimizing for a broader problem.
OpenClaw’s biggest advantage may be the control plane
The tradeoff is product breadth.
NanoClaw emphasizes a relatively small codebase, container isolation and customization through code and skills. Its second-generation architecture supports owner, administrator and member roles, and a separate monitoring dashboard can provide visibility into deployments.
OpenClaw 2.0 is trying to build a much broader operational environment.
Its Control UI combines employee interaction, live execution, files, approvals, terminals, code review, model-provider configuration, devices and shared sessions.
That gives OpenClaw a potential advantage for enterprises that need not only secure agent execution but a usable control plane around it.
Security teams care about isolation. Platform teams also need deployment, authentication, model configuration, auditing and policy enforcement. Employees need an interface they can actually use. Managers need a way to understand what is running. Developers need access to the underlying files and tools when something goes wrong.
OpenClaw 2.0 increasingly tries to serve all of those constituencies through one system.
What is OpenAI’s role?
OpenClaw says 933 contributors, including 569 first-time contributors, participated in the release, which includes more than 16,000 pull requests — roughly half of all pull requests ever merged into the project.
Interestingly, the release was not shared by Steinberger’s employer, OpenAI. Recall that the Austrian developer announced on Feb. 14, 2026 that he was joining OpenAI to work on bringing agents to a broader audience, a move OpenAI CEO Sam Altman publicly confirmed the following day.
But OpenClaw was not folded into OpenAI. Steinberger said at the time that OpenClaw would move to a foundation and “stay open and independent,” while OpenAI would support the project. OpenClaw now says it is stewarded by the OpenClaw Foundation, an independent 501(c)(3), with OpenAI listed alongside Microsoft, GitHub, NVIDIA, Atlassian, Tencent and other organizations as partners.
Based on the available public information, OpenClaw 2.0 should therefore be understood as an OpenClaw Foundation release, not an OpenAI product or OpenAI software release, despite Steinberger’s employment at OpenAI and OpenAI’s financial and organizational support for the project.
Enterprise readiness now depends on configuration
OpenClaw 2.0 does not eliminate the security risks associated with autonomous agents, and its own documentation identifies limitations.
Secret Store values, for example, are not themselves encrypted at rest and rely on filesystem protections. Protected credential substitution does not cover every possible execution path, including some raw sockets, containers, remote nodes and provider-native harnessesIts multi-user permissions are collaboration controls, not hostile-tenant isolation.
Those caveats should prevent enterprises from interpreting OpenClaw 2.0 as secure-by-default agent infrastructure.But they also illustrate how much the conversation around the project has changed. The relevant comparison is increasingly not simply OpenClaw versus NanoClaw. It is a container-first, constrained system such as NanoClaw versus a deliberately hardened OpenClaw deployment that provides a substantially broader employee and administrator experience.
NanoClaw retains a strong proposition for organizations prioritizing a small attack surface, container-first execution and architectural simplicity.
OpenClaw is making another bet: that enterprises ultimately need an agent platform to function as both runtime and workplace.
OpenClaw 2.0 provides many of the primitives needed to build that environment — sandboxing, permissions, protected credentials, approvals, identity, auditing and isolated deployments — alongside a browser interface designed to make the system accessible to employees who will never configure an agent from a terminal.
The remaining caveat is important: enterprises have to turn those primitives into policy. OpenClaw 2.0 doesn’t automatically make OpenClaw enterprise-ready, but it does make an enterprise-grade OpenClaw deployment far easier out-of-the-box.
And as Steinberger’s description of OpenClaw’s own development process suggests, the long-term ambition may be larger still. Rather than giving every employee another AI assistant, OpenClaw is positioning the agent itself as shared infrastructure — a persistent layer where people, models and compute collaborate on the same work.
The viral fervor we saw earlier this year around OpenClaw, the open source AI harness that turns powerful language models into autonomous workers the user can message via their favorite channels (Telegram, iMessage, WhatsApp, Discord etc), has cooled off substantially from its peak in March 2026.
But over the weekend, OpenClaw’s creator Peter Steinberger and current team of co-developers gave the world — especially enterprises — a reason to look at it again, announcing OpenClaw 2.0, billed as the most significant update to the harness and surrounding platform yet.
OpenClaw 2.0 seeks to transform what began largely as a personal agent harness into something increasingly designed for teams, shared infrastructure and enterprise workflows.
OpenClaw 2.0 introduces a rebuilt browser interface that brings conversations, files, approvals, configuration and live agent activity into a common workspace. It adds shared cloud sessions and multi-user collaboration. And it expands the security model with stronger sandboxing, role-based permissions, approval controls, secrets handling and auditing.
Together, those additions move OpenClaw closer to being infrastructure that an organization could deploy for employees rather than simply a powerful agent an individual developer runs locally.
They also sharpen a competitive question surrounding the project: whether OpenClaw has addressed the security and isolation concerns that helped inspire newer alternatives such as NanoClaw.
The answer is increasingly yes at the capability level — but not necessarily by default.
OpenClaw wants to become the shared agent layer
Released under the official name of v2026.8.1, the update spans installation, messaging, memory, skills, models, automations, browser and native applications, plugins and security.
Steinberger described the development of OpenClaw 2.0 as an exercise in using the product to build itself.
“Two months ago, we started the mission to ‘build OpenClaw with OpenClaw,’” Steinberger wrote on X early on August 31.
Over that period, he said, OpenClaw gradually moved its team away from individual local coding harnesses and toward team.openclaw.ai, a shared agent environment aware of what team members are working on.
“Multiplayer coding + infinite compute with nodes and cloud sessions has been a game changer for how we build,” Steinberger wrote, adding that local harnesses now “feel like relics of the past.”
That claim points toward one of the more important changes in OpenClaw’s enterprise proposition.
The dominant model for AI coding agents has generally been individual: a developer runs an agent in a terminal, IDE or desktop application, gives it access to a repository and lets it execute work within that environment.
OpenClaw 2.0 is pushing toward something different. Agent sessions can become persistent workspaces that outlive a single terminal or employee. They can be shared with colleagues, executed across other machines or cloud workers, and supervised through a browser.
For enterprises, that potentially turns the agent from an employee-level productivity application into a shared operational layer.
A new UI could broaden OpenClaw beyond developers
The redesigned Control UI is central to that strategy.
OpenClaw has shifted away from an Overview-first web application and made conversations the primary interface. Threads sit in a sidebar, while the active conversation occupies the main workspace. Files, approvals, settings and ongoing agent activity remain accessible around it.
The design deliberately brings OpenClaw closer to the interaction model employees already know from OpenAI’s ChatGPT, Anthropic’s Claude, Google’s Gemini and other conversational AI products.
That lowers an important barrier to enterprise adoption. Open-source agent frameworks are often powerful precisely because they expose low-level configuration, terminals, tools and runtime controls. Those same characteristics can make them difficult to deploy beyond engineering organizations.
OpenClaw 2.0 attempts to preserve the underlying control while putting a conversational interface on top of it. An employee can ask an agent to perform work without treating the terminal as the primary product interface. But OpenClaw does not hide what is happening underneath. The Control UI can surface session files, terminal activity, Git-backed changes, pull-request state, browser activity and interactive dashboards.
The release also places more emphasis on observability during agent execution. Tool calls and results are paired more clearly, file changes can appear as focused diffs, command activity is easier to inspect, and long-running background tasks can remain visible alongside the conversation. That combination matters for enterprise use.
Employees get a simpler interface for delegating work. Technical users retain access to the artifacts and execution state behind the conversation. Administrators gain a centralized place to configure and supervise the system.
The redesigned Settings workspace now encompasses agents, memory, plugins, MCP servers, devices, communication channels and device pairing. OpenClaw also consolidates model-provider administration, including credential status and, where providers expose it, model availability, quota, account balance, budget and spending information.
Limited-access browser users can request administrator privileges rather than automatically receiving them, with another administrator required to approve the escalation.
These are not especially flashy agent features. For companies deploying AI systems to dozens or hundreds of employees, they may be among the most important additions in the release.
Multiplayer sessions turn agent context into shared context
OpenClaw 2.0 also expands the agent from a personal workspace into a collaborative one.
Shared cloud sessions allow another employee to enter work already in progress without discarding the context accumulated by the agent.
Multi-user Gateways — the service that connects users and agents to tools, files, credentials and other resources — can track who created a conversation and which prompts were submitted by identified participants.
Owners and administrators can determine whether another user can read a session, suggest changes, work in draft mode or participate directly.
The interface adds session ownership, participant attribution, presence and even typing indicators. For coding teams, that introduces a workflow closer to collaborative software development than traditional AI chat.
A developer could initiate a task and allow an agent to work on it remotely. Another engineer could inspect the resulting changes. A senior engineer or administrator could approve an operation requiring additional privileges. The work does not have to remain attached to the laptop or terminal where it started.
Sessions can also move execution to paired devices or cloud workers while maintaining the broader workspace.
For enterprises experimenting with long-running agents, that is significant. Persistent agents need mechanisms for shift changes, escalation, supervision and ownership transfer. Otherwise, organizations simply create fleets of personal agents whose state disappears into individual user environments.
OpenClaw is attempting to turn that state into collaborative infrastructure. Already, some teams outside the developers of the open source project are adopting it.
Colin Johnson, CEO of marketing metrics software firm Solvely, described a similar shift in his own development workflow in a post on X.
His team had already been using OpenClaw agents through Discord, where developers could assign tasks, run commands and interact with their development environment. But he said that model still felt like “messaging a bot”: developers could share access to an agent without actually sharing the agent’s working context.
The new multiplayer WebUI changed that, he wrote, because two developers could open the same live session, see the same history and artifacts, and add information without first exporting or reconstructing what the agent had already done. “We were working inside the same context,” Colin wrote.
In one example, another developer was taking over a project he had been working on; instead of preparing a traditional handoff document, Colin joined the developer’s existing agent thread and added the missing project context directly. “The session itself became the handoff document,” he wrote.
For enterprise teams, that is a useful illustration of why persistent multiplayer sessions may matter beyond convenience: agent context can become a shared work artifact rather than information trapped inside one employee’s private conversation.
Colin’s deployment also illustrates both the enterprise potential and the remaining security boundary. His team runs its OpenClaw Gateway on a development server reachable through GitHub authentication, Cloudflare Access and a Cloudflare Tunnel, with the Gateway itself listening only on the server’s loopback interface rather than an exposed public port.
But he explicitly cautioned that this does not make the shared Gateway a multitenant environment. The developers already trust one another with the repositories, tools and agent capabilities behind it. As he put it, Cloudflare controls who can enter the workspace, while OpenClaw tracks who created, owns or contributed to the work; stronger separation still requires separate infrastructure.
Security becomes much more enterprise-oriented
That shift creates a corresponding security problem: a shared agent can potentially act with broader organizational authority than one running on a developer laptop.
OpenClaw 2.0 responds with considerably more granular controls.
Approvals can now 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 being executed still matches what was originally reviewed.
Sessions can operate under different permission levels, including read-only, guarded, workspace and full-access modes, with the highest level restricted to administrators.
Organizations can also define operator roles that require sandboxed execution for sessions created by specific identities. OpenClaw says those requirements cannot be bypassed using 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 protection.
OpenClaw’s team-scoped Secret Store distinguishes protected secrets from ordinary environment data available to the agent. For supported requests, a protected credential can be substituted into a Gateway-hosted HTTPS request without exposing that credential directly to the model.
OpenClaw can also reference external systems including 1Password and Vault.
Auditing has expanded around execution identity, approvals, session actions and outbound messages. Plugin installation can trigger capability reviews associated with the specific artifact being installed.
Those controls address questions enterprises inevitably face when deploying agents: Who initiated an action? Which agent performed it? What resources could it access? Who approved the operation? And what happens to those permissions when work moves between people or machines?
NanoClaw still takes a different approach to security
OpenClaw’s changes also make the comparison with open source, enterprise-friendly rival NanoClaw more nuanced.
NanoClaw is one of several subsequent projects to emerge around the idea that AI agents need stronger isolation and simpler security boundaries. Its architecture places operating-system-level containment at the center of the design.
NanoClaw runs agents inside Docker containers, limits those containers to explicitly mounted filesystems and runs their processes as an unprivileged user. Sessions and agent groups can remain isolated rather than automatically sharing files and conversation history.
Its credential architecture follows the same principle. Supported outbound requests can pass through OneCLI’s Agent Vault, allowing credentials to be injected by a gateway rather than placed inside the agent container itself. NanoClaw also provides an optional egress-lockdown mode that puts agents on an internal Docker network and routes supported external traffic through the gateway.
OpenClaw 2.0 can now reproduce many elements of that hardened model. 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 key difference is the starting posture. 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. NanoClaw makes isolation more fundamental to how agent execution is structured.
So does OpenClaw 2.0 have security parity with NanoClaw?
In terms of available controls, it is much closer than before. In terms of defaults and architectural philosophy, no. An enterprise can configure OpenClaw into a substantially hardened environment, but it has to make that decision deliberately.
One Gateway is still one trust domain
Another limitation is particularly important for larger organizations. OpenClaw says a Gateway should be treated as a single trust domain.
Its new multi-user permissions are designed to govern collaboration among trusted users. They should not be treated as hard isolation between mutually untrusted tenants.
For organizations requiring stronger separation — between business units, customers or other security domains, for example — OpenClaw recommends separate Gateway instances, described as “cells,” with separate state, credentials and workspaces.
Fleet tooling for managing those cells remains experimental.
That distinction could matter significantly for enterprises considering OpenClaw as a centrally operated service.
Role-based access inside one Gateway may be sufficient for a trusted engineering department or internal team. It is a different proposition from a multi-tenant platform intended to isolate customers or users who should be assumed hostile to one another.
NanoClaw has its own configuration requirements and limitations, and even its stronger outbound-network lockdown remains optional. But its smaller architecture and container-centric execution model may appeal to organizations that want a narrower security boundary that is easier to reason about.
OpenClaw is optimizing for a broader problem.
OpenClaw’s biggest advantage may be the control plane
The tradeoff is product breadth.
NanoClaw emphasizes a relatively small codebase, container isolation and customization through code and skills. Its second-generation architecture supports owner, administrator and member roles, and a separate monitoring dashboard can provide visibility into deployments.
OpenClaw 2.0 is trying to build a much broader operational environment.
Its Control UI combines employee interaction, live execution, files, approvals, terminals, code review, model-provider configuration, devices and shared sessions.
That gives OpenClaw a potential advantage for enterprises that need not only secure agent execution but a usable control plane around it.
Security teams care about isolation. Platform teams also need deployment, authentication, model configuration, auditing and policy enforcement. Employees need an interface they can actually use. Managers need a way to understand what is running. Developers need access to the underlying files and tools when something goes wrong.
OpenClaw 2.0 increasingly tries to serve all of those constituencies through one system.
What is OpenAI’s role?
OpenClaw says 933 contributors, including 569 first-time contributors, participated in the release, which includes more than 16,000 pull requests — roughly half of all pull requests ever merged into the project.
Interestingly, the release was not shared by Steinberger’s employer, OpenAI. Recall that the Austrian developer announced on Feb. 14, 2026 that he was joining OpenAI to work on bringing agents to a broader audience, a move OpenAI CEO Sam Altman publicly confirmed the following day.
But OpenClaw was not folded into OpenAI. Steinberger said at the time that OpenClaw would move to a foundation and “stay open and independent,” while OpenAI would support the project. OpenClaw now says it is stewarded by the OpenClaw Foundation, an independent 501(c)(3), with OpenAI listed alongside Microsoft, GitHub, NVIDIA, Atlassian, Tencent and other organizations as partners.
Based on the available public information, OpenClaw 2.0 should therefore be understood as an OpenClaw Foundation release, not an OpenAI product or OpenAI software release, despite Steinberger’s employment at OpenAI and OpenAI’s financial and organizational support for the project.
Enterprise readiness now depends on configuration
OpenClaw 2.0 does not eliminate the security risks associated with autonomous agents, and its own documentation identifies limitations.
Secret Store values, for example, are not themselves encrypted at rest and rely on filesystem protections. Protected credential substitution does not cover every possible execution path, including some raw sockets, containers, remote nodes and provider-native harnessesIts multi-user permissions are collaboration controls, not hostile-tenant isolation.
Those caveats should prevent enterprises from interpreting OpenClaw 2.0 as secure-by-default agent infrastructure.But they also illustrate how much the conversation around the project has changed. The relevant comparison is increasingly not simply OpenClaw versus NanoClaw. It is a container-first, constrained system such as NanoClaw versus a deliberately hardened OpenClaw deployment that provides a substantially broader employee and administrator experience.
NanoClaw retains a strong proposition for organizations prioritizing a small attack surface, container-first execution and architectural simplicity.
OpenClaw is making another bet: that enterprises ultimately need an agent platform to function as both runtime and workplace.
OpenClaw 2.0 provides many of the primitives needed to build that environment — sandboxing, permissions, protected credentials, approvals, identity, auditing and isolated deployments — alongside a browser interface designed to make the system accessible to employees who will never configure an agent from a terminal.
The remaining caveat is important: enterprises have to turn those primitives into policy. OpenClaw 2.0 doesn’t automatically make OpenClaw enterprise-ready, but it does make an enterprise-grade OpenClaw deployment far easier out-of-the-box.
And as Steinberger’s description of OpenClaw’s own development process suggests, the long-term ambition may be larger still. Rather than giving every employee another AI assistant, OpenClaw is positioning the agent itself as shared infrastructure — a persistent layer where people, models and compute collaborate on the same work.
The viral fervor we saw earlier this year around OpenClaw, the open source AI harness that turns powerful language models into autonomous workers the user can message via their favorite channels (Telegram, iMessage, WhatsApp, Discord etc), has cooled off substantially from its peak in March 2026.
But over the weekend, OpenClaw’s creator Peter Steinberger and current team of co-developers gave the world — especially enterprises — a reason to look at it again, announcing OpenClaw 2.0, billed as the most significant update to the harness and surrounding platform yet.
OpenClaw 2.0 seeks to transform what began largely as a personal agent harness into something increasingly designed for teams, shared infrastructure and enterprise workflows.
OpenClaw 2.0 introduces a rebuilt browser interface that brings conversations, files, approvals, configuration and live agent activity into a common workspace. It adds shared cloud sessions and multi-user collaboration. And it expands the security model with stronger sandboxing, role-based permissions, approval controls, secrets handling and auditing.
Together, those additions move OpenClaw closer to being infrastructure that an organization could deploy for employees rather than simply a powerful agent an individual developer runs locally.
They also sharpen a competitive question surrounding the project: whether OpenClaw has addressed the security and isolation concerns that helped inspire newer alternatives such as NanoClaw.
The answer is increasingly yes at the capability level — but not necessarily by default.
OpenClaw wants to become the shared agent layer
Released under the official name of v2026.8.1, the update spans installation, messaging, memory, skills, models, automations, browser and native applications, plugins and security.
Steinberger described the development of OpenClaw 2.0 as an exercise in using the product to build itself.
“Two months ago, we started the mission to ‘build OpenClaw with OpenClaw,’” Steinberger wrote on X early on August 31.
Over that period, he said, OpenClaw gradually moved its team away from individual local coding harnesses and toward team.openclaw.ai, a shared agent environment aware of what team members are working on.
“Multiplayer coding + infinite compute with nodes and cloud sessions has been a game changer for how we build,” Steinberger wrote, adding that local harnesses now “feel like relics of the past.”
That claim points toward one of the more important changes in OpenClaw’s enterprise proposition.
The dominant model for AI coding agents has generally been individual: a developer runs an agent in a terminal, IDE or desktop application, gives it access to a repository and lets it execute work within that environment.
OpenClaw 2.0 is pushing toward something different. Agent sessions can become persistent workspaces that outlive a single terminal or employee. They can be shared with colleagues, executed across other machines or cloud workers, and supervised through a browser.
For enterprises, that potentially turns the agent from an employee-level productivity application into a shared operational layer.
A new UI could broaden OpenClaw beyond developers
The redesigned Control UI is central to that strategy.
OpenClaw has shifted away from an Overview-first web application and made conversations the primary interface. Threads sit in a sidebar, while the active conversation occupies the main workspace. Files, approvals, settings and ongoing agent activity remain accessible around it.
The design deliberately brings OpenClaw closer to the interaction model employees already know from OpenAI’s ChatGPT, Anthropic’s Claude, Google’s Gemini and other conversational AI products.
That lowers an important barrier to enterprise adoption. Open-source agent frameworks are often powerful precisely because they expose low-level configuration, terminals, tools and runtime controls. Those same characteristics can make them difficult to deploy beyond engineering organizations.
OpenClaw 2.0 attempts to preserve the underlying control while putting a conversational interface on top of it. An employee can ask an agent to perform work without treating the terminal as the primary product interface. But OpenClaw does not hide what is happening underneath. The Control UI can surface session files, terminal activity, Git-backed changes, pull-request state, browser activity and interactive dashboards.
The release also places more emphasis on observability during agent execution. Tool calls and results are paired more clearly, file changes can appear as focused diffs, command activity is easier to inspect, and long-running background tasks can remain visible alongside the conversation. That combination matters for enterprise use.
Employees get a simpler interface for delegating work. Technical users retain access to the artifacts and execution state behind the conversation. Administrators gain a centralized place to configure and supervise the system.
The redesigned Settings workspace now encompasses agents, memory, plugins, MCP servers, devices, communication channels and device pairing. OpenClaw also consolidates model-provider administration, including credential status and, where providers expose it, model availability, quota, account balance, budget and spending information.
Limited-access browser users can request administrator privileges rather than automatically receiving them, with another administrator required to approve the escalation.
These are not especially flashy agent features. For companies deploying AI systems to dozens or hundreds of employees, they may be among the most important additions in the release.
Multiplayer sessions turn agent context into shared context
OpenClaw 2.0 also expands the agent from a personal workspace into a collaborative one.
Shared cloud sessions allow another employee to enter work already in progress without discarding the context accumulated by the agent.
Multi-user Gateways — the service that connects users and agents to tools, files, credentials and other resources — can track who created a conversation and which prompts were submitted by identified participants.
Owners and administrators can determine whether another user can read a session, suggest changes, work in draft mode or participate directly.
The interface adds session ownership, participant attribution, presence and even typing indicators. For coding teams, that introduces a workflow closer to collaborative software development than traditional AI chat.
A developer could initiate a task and allow an agent to work on it remotely. Another engineer could inspect the resulting changes. A senior engineer or administrator could approve an operation requiring additional privileges. The work does not have to remain attached to the laptop or terminal where it started.
Sessions can also move execution to paired devices or cloud workers while maintaining the broader workspace.
For enterprises experimenting with long-running agents, that is significant. Persistent agents need mechanisms for shift changes, escalation, supervision and ownership transfer. Otherwise, organizations simply create fleets of personal agents whose state disappears into individual user environments.
OpenClaw is attempting to turn that state into collaborative infrastructure. Already, some teams outside the developers of the open source project are adopting it.
Colin Johnson, CEO of marketing metrics software firm Solvely, described a similar shift in his own development workflow in a post on X.
His team had already been using OpenClaw agents through Discord, where developers could assign tasks, run commands and interact with their development environment. But he said that model still felt like “messaging a bot”: developers could share access to an agent without actually sharing the agent’s working context.
The new multiplayer WebUI changed that, he wrote, because two developers could open the same live session, see the same history and artifacts, and add information without first exporting or reconstructing what the agent had already done. “We were working inside the same context,” Colin wrote.
In one example, another developer was taking over a project he had been working on; instead of preparing a traditional handoff document, Colin joined the developer’s existing agent thread and added the missing project context directly. “The session itself became the handoff document,” he wrote.
For enterprise teams, that is a useful illustration of why persistent multiplayer sessions may matter beyond convenience: agent context can become a shared work artifact rather than information trapped inside one employee’s private conversation.
Colin’s deployment also illustrates both the enterprise potential and the remaining security boundary. His team runs its OpenClaw Gateway on a development server reachable through GitHub authentication, Cloudflare Access and a Cloudflare Tunnel, with the Gateway itself listening only on the server’s loopback interface rather than an exposed public port.
But he explicitly cautioned that this does not make the shared Gateway a multitenant environment. The developers already trust one another with the repositories, tools and agent capabilities behind it. As he put it, Cloudflare controls who can enter the workspace, while OpenClaw tracks who created, owns or contributed to the work; stronger separation still requires separate infrastructure.
Security becomes much more enterprise-oriented
That shift creates a corresponding security problem: a shared agent can potentially act with broader organizational authority than one running on a developer laptop.
OpenClaw 2.0 responds with considerably more granular controls.
Approvals can now 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 being executed still matches what was originally reviewed.
Sessions can operate under different permission levels, including read-only, guarded, workspace and full-access modes, with the highest level restricted to administrators.
Organizations can also define operator roles that require sandboxed execution for sessions created by specific identities. OpenClaw says those requirements cannot be bypassed using 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 protection.
OpenClaw’s team-scoped Secret Store distinguishes protected secrets from ordinary environment data available to the agent. For supported requests, a protected credential can be substituted into a Gateway-hosted HTTPS request without exposing that credential directly to the model.
OpenClaw can also reference external systems including 1Password and Vault.
Auditing has expanded around execution identity, approvals, session actions and outbound messages. Plugin installation can trigger capability reviews associated with the specific artifact being installed.
Those controls address questions enterprises inevitably face when deploying agents: Who initiated an action? Which agent performed it? What resources could it access? Who approved the operation? And what happens to those permissions when work moves between people or machines?
NanoClaw still takes a different approach to security
OpenClaw’s changes also make the comparison with open source, enterprise-friendly rival NanoClaw more nuanced.
NanoClaw is one of several subsequent projects to emerge around the idea that AI agents need stronger isolation and simpler security boundaries. Its architecture places operating-system-level containment at the center of the design.
NanoClaw runs agents inside Docker containers, limits those containers to explicitly mounted filesystems and runs their processes as an unprivileged user. Sessions and agent groups can remain isolated rather than automatically sharing files and conversation history.
Its credential architecture follows the same principle. Supported outbound requests can pass through OneCLI’s Agent Vault, allowing credentials to be injected by a gateway rather than placed inside the agent container itself. NanoClaw also provides an optional egress-lockdown mode that puts agents on an internal Docker network and routes supported external traffic through the gateway.
OpenClaw 2.0 can now reproduce many elements of that hardened model. 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 key difference is the starting posture. 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. NanoClaw makes isolation more fundamental to how agent execution is structured.
So does OpenClaw 2.0 have security parity with NanoClaw?
In terms of available controls, it is much closer than before. In terms of defaults and architectural philosophy, no. An enterprise can configure OpenClaw into a substantially hardened environment, but it has to make that decision deliberately.
One Gateway is still one trust domain
Another limitation is particularly important for larger organizations. OpenClaw says a Gateway should be treated as a single trust domain.
Its new multi-user permissions are designed to govern collaboration among trusted users. They should not be treated as hard isolation between mutually untrusted tenants.
For organizations requiring stronger separation — between business units, customers or other security domains, for example — OpenClaw recommends separate Gateway instances, described as “cells,” with separate state, credentials and workspaces.
Fleet tooling for managing those cells remains experimental.
That distinction could matter significantly for enterprises considering OpenClaw as a centrally operated service.
Role-based access inside one Gateway may be sufficient for a trusted engineering department or internal team. It is a different proposition from a multi-tenant platform intended to isolate customers or users who should be assumed hostile to one another.
NanoClaw has its own configuration requirements and limitations, and even its stronger outbound-network lockdown remains optional. But its smaller architecture and container-centric execution model may appeal to organizations that want a narrower security boundary that is easier to reason about.
OpenClaw is optimizing for a broader problem.
OpenClaw’s biggest advantage may be the control plane
The tradeoff is product breadth.
NanoClaw emphasizes a relatively small codebase, container isolation and customization through code and skills. Its second-generation architecture supports owner, administrator and member roles, and a separate monitoring dashboard can provide visibility into deployments.
OpenClaw 2.0 is trying to build a much broader operational environment.
Its Control UI combines employee interaction, live execution, files, approvals, terminals, code review, model-provider configuration, devices and shared sessions.
That gives OpenClaw a potential advantage for enterprises that need not only secure agent execution but a usable control plane around it.
Security teams care about isolation. Platform teams also need deployment, authentication, model configuration, auditing and policy enforcement. Employees need an interface they can actually use. Managers need a way to understand what is running. Developers need access to the underlying files and tools when something goes wrong.
OpenClaw 2.0 increasingly tries to serve all of those constituencies through one system.
What is OpenAI’s role?
OpenClaw says 933 contributors, including 569 first-time contributors, participated in the release, which includes more than 16,000 pull requests — roughly half of all pull requests ever merged into the project.
Interestingly, the release was not shared by Steinberger’s employer, OpenAI. Recall that the Austrian developer announced on Feb. 14, 2026 that he was joining OpenAI to work on bringing agents to a broader audience, a move OpenAI CEO Sam Altman publicly confirmed the following day.
But OpenClaw was not folded into OpenAI. Steinberger said at the time that OpenClaw would move to a foundation and “stay open and independent,” while OpenAI would support the project. OpenClaw now says it is stewarded by the OpenClaw Foundation, an independent 501(c)(3), with OpenAI listed alongside Microsoft, GitHub, NVIDIA, Atlassian, Tencent and other organizations as partners.
Based on the available public information, OpenClaw 2.0 should therefore be understood as an OpenClaw Foundation release, not an OpenAI product or OpenAI software release, despite Steinberger’s employment at OpenAI and OpenAI’s financial and organizational support for the project.
Enterprise readiness now depends on configuration
OpenClaw 2.0 does not eliminate the security risks associated with autonomous agents, and its own documentation identifies limitations.
Secret Store values, for example, are not themselves encrypted at rest and rely on filesystem protections. Protected credential substitution does not cover every possible execution path, including some raw sockets, containers, remote nodes and provider-native harnessesIts multi-user permissions are collaboration controls, not hostile-tenant isolation.
Those caveats should prevent enterprises from interpreting OpenClaw 2.0 as secure-by-default agent infrastructure.But they also illustrate how much the conversation around the project has changed. The relevant comparison is increasingly not simply OpenClaw versus NanoClaw. It is a container-first, constrained system such as NanoClaw versus a deliberately hardened OpenClaw deployment that provides a substantially broader employee and administrator experience.
NanoClaw retains a strong proposition for organizations prioritizing a small attack surface, container-first execution and architectural simplicity.
OpenClaw is making another bet: that enterprises ultimately need an agent platform to function as both runtime and workplace.
OpenClaw 2.0 provides many of the primitives needed to build that environment — sandboxing, permissions, protected credentials, approvals, identity, auditing and isolated deployments — alongside a browser interface designed to make the system accessible to employees who will never configure an agent from a terminal.
The remaining caveat is important: enterprises have to turn those primitives into policy. OpenClaw 2.0 doesn’t automatically make OpenClaw enterprise-ready, but it does make an enterprise-grade OpenClaw deployment far easier out-of-the-box.
And as Steinberger’s description of OpenClaw’s own development process suggests, the long-term ambition may be larger still. Rather than giving every employee another AI assistant, OpenClaw is positioning the agent itself as shared infrastructure — a persistent layer where people, models and compute collaborate on the same work.
Suscríbete y recibe las historias más importantes del día.
Al suscribirte aceptas nuestros términos y condiciones y política de privacidad.
The viral fervor we saw earlier this year around OpenClaw, the open source AI harness that turns powerful language models into autonomous workers the user can message via their favorite channels (Telegram, iMessage, WhatsApp, Discord etc), has cooled off substantially from its peak in March 2026.
But over the weekend, OpenClaw’s creator Peter Steinberger and current team of co-developers gave the world — especially enterprises — a reason to look at it again, announcing OpenClaw 2.0, billed as the most significant update to the harness and surrounding platform yet.
OpenClaw 2.0 seeks to transform what began largely as a personal agent harness into something increasingly designed for teams, shared infrastructure and enterprise workflows.
OpenClaw 2.0 introduces a rebuilt browser interface that brings conversations, files, approvals, configuration and live agent activity into a common workspace. It adds shared cloud sessions and multi-user collaboration. And it expands the security model with stronger sandboxing, role-based permissions, approval controls, secrets handling and auditing.
Together, those additions move OpenClaw closer to being infrastructure that an organization could deploy for employees rather than simply a powerful agent an individual developer runs locally.
They also sharpen a competitive question surrounding the project: whether OpenClaw has addressed the security and isolation concerns that helped inspire newer alternatives such as NanoClaw.
The answer is increasingly yes at the capability level — but not necessarily by default.
OpenClaw wants to become the shared agent layer
Released under the official name of v2026.8.1, the update spans installation, messaging, memory, skills, models, automations, browser and native applications, plugins and security.
Steinberger described the development of OpenClaw 2.0 as an exercise in using the product to build itself.
“Two months ago, we started the mission to ‘build OpenClaw with OpenClaw,’” Steinberger wrote on X early on August 31.
Over that period, he said, OpenClaw gradually moved its team away from individual local coding harnesses and toward team.openclaw.ai, a shared agent environment aware of what team members are working on.
“Multiplayer coding + infinite compute with nodes and cloud sessions has been a game changer for how we build,” Steinberger wrote, adding that local harnesses now “feel like relics of the past.”
That claim points toward one of the more important changes in OpenClaw’s enterprise proposition.
The dominant model for AI coding agents has generally been individual: a developer runs an agent in a terminal, IDE or desktop application, gives it access to a repository and lets it execute work within that environment.
OpenClaw 2.0 is pushing toward something different. Agent sessions can become persistent workspaces that outlive a single terminal or employee. They can be shared with colleagues, executed across other machines or cloud workers, and supervised through a browser.
For enterprises, that potentially turns the agent from an employee-level productivity application into a shared operational layer.
A new UI could broaden OpenClaw beyond developers
The redesigned Control UI is central to that strategy.
OpenClaw has shifted away from an Overview-first web application and made conversations the primary interface. Threads sit in a sidebar, while the active conversation occupies the main workspace. Files, approvals, settings and ongoing agent activity remain accessible around it.
The design deliberately brings OpenClaw closer to the interaction model employees already know from OpenAI’s ChatGPT, Anthropic’s Claude, Google’s Gemini and other conversational AI products.
That lowers an important barrier to enterprise adoption. Open-source agent frameworks are often powerful precisely because they expose low-level configuration, terminals, tools and runtime controls. Those same characteristics can make them difficult to deploy beyond engineering organizations.
OpenClaw 2.0 attempts to preserve the underlying control while putting a conversational interface on top of it. An employee can ask an agent to perform work without treating the terminal as the primary product interface. But OpenClaw does not hide what is happening underneath. The Control UI can surface session files, terminal activity, Git-backed changes, pull-request state, browser activity and interactive dashboards.
The release also places more emphasis on observability during agent execution. Tool calls and results are paired more clearly, file changes can appear as focused diffs, command activity is easier to inspect, and long-running background tasks can remain visible alongside the conversation. That combination matters for enterprise use.
Employees get a simpler interface for delegating work. Technical users retain access to the artifacts and execution state behind the conversation. Administrators gain a centralized place to configure and supervise the system.
The redesigned Settings workspace now encompasses agents, memory, plugins, MCP servers, devices, communication channels and device pairing. OpenClaw also consolidates model-provider administration, including credential status and, where providers expose it, model availability, quota, account balance, budget and spending information.
Limited-access browser users can request administrator privileges rather than automatically receiving them, with another administrator required to approve the escalation.
These are not especially flashy agent features. For companies deploying AI systems to dozens or hundreds of employees, they may be among the most important additions in the release.
Multiplayer sessions turn agent context into shared context
OpenClaw 2.0 also expands the agent from a personal workspace into a collaborative one.
Shared cloud sessions allow another employee to enter work already in progress without discarding the context accumulated by the agent.
Multi-user Gateways — the service that connects users and agents to tools, files, credentials and other resources — can track who created a conversation and which prompts were submitted by identified participants.
Owners and administrators can determine whether another user can read a session, suggest changes, work in draft mode or participate directly.
The interface adds session ownership, participant attribution, presence and even typing indicators. For coding teams, that introduces a workflow closer to collaborative software development than traditional AI chat.
A developer could initiate a task and allow an agent to work on it remotely. Another engineer could inspect the resulting changes. A senior engineer or administrator could approve an operation requiring additional privileges. The work does not have to remain attached to the laptop or terminal where it started.
Sessions can also move execution to paired devices or cloud workers while maintaining the broader workspace.
For enterprises experimenting with long-running agents, that is significant. Persistent agents need mechanisms for shift changes, escalation, supervision and ownership transfer. Otherwise, organizations simply create fleets of personal agents whose state disappears into individual user environments.
OpenClaw is attempting to turn that state into collaborative infrastructure. Already, some teams outside the developers of the open source project are adopting it.
Colin Johnson, CEO of marketing metrics software firm Solvely, described a similar shift in his own development workflow in a post on X.
His team had already been using OpenClaw agents through Discord, where developers could assign tasks, run commands and interact with their development environment. But he said that model still felt like “messaging a bot”: developers could share access to an agent without actually sharing the agent’s working context.
The new multiplayer WebUI changed that, he wrote, because two developers could open the same live session, see the same history and artifacts, and add information without first exporting or reconstructing what the agent had already done. “We were working inside the same context,” Colin wrote.
In one example, another developer was taking over a project he had been working on; instead of preparing a traditional handoff document, Colin joined the developer’s existing agent thread and added the missing project context directly. “The session itself became the handoff document,” he wrote.
For enterprise teams, that is a useful illustration of why persistent multiplayer sessions may matter beyond convenience: agent context can become a shared work artifact rather than information trapped inside one employee’s private conversation.
Colin’s deployment also illustrates both the enterprise potential and the remaining security boundary. His team runs its OpenClaw Gateway on a development server reachable through GitHub authentication, Cloudflare Access and a Cloudflare Tunnel, with the Gateway itself listening only on the server’s loopback interface rather than an exposed public port.
But he explicitly cautioned that this does not make the shared Gateway a multitenant environment. The developers already trust one another with the repositories, tools and agent capabilities behind it. As he put it, Cloudflare controls who can enter the workspace, while OpenClaw tracks who created, owns or contributed to the work; stronger separation still requires separate infrastructure.
Security becomes much more enterprise-oriented
That shift creates a corresponding security problem: a shared agent can potentially act with broader organizational authority than one running on a developer laptop.
OpenClaw 2.0 responds with considerably more granular controls.
Approvals can now 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 being executed still matches what was originally reviewed.
Sessions can operate under different permission levels, including read-only, guarded, workspace and full-access modes, with the highest level restricted to administrators.
Organizations can also define operator roles that require sandboxed execution for sessions created by specific identities. OpenClaw says those requirements cannot be bypassed using 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 protection.
OpenClaw’s team-scoped Secret Store distinguishes protected secrets from ordinary environment data available to the agent. For supported requests, a protected credential can be substituted into a Gateway-hosted HTTPS request without exposing that credential directly to the model.
OpenClaw can also reference external systems including 1Password and Vault.
Auditing has expanded around execution identity, approvals, session actions and outbound messages. Plugin installation can trigger capability reviews associated with the specific artifact being installed.
Those controls address questions enterprises inevitably face when deploying agents: Who initiated an action? Which agent performed it? What resources could it access? Who approved the operation? And what happens to those permissions when work moves between people or machines?
NanoClaw still takes a different approach to security
OpenClaw’s changes also make the comparison with open source, enterprise-friendly rival NanoClaw more nuanced.
NanoClaw is one of several subsequent projects to emerge around the idea that AI agents need stronger isolation and simpler security boundaries. Its architecture places operating-system-level containment at the center of the design.
NanoClaw runs agents inside Docker containers, limits those containers to explicitly mounted filesystems and runs their processes as an unprivileged user. Sessions and agent groups can remain isolated rather than automatically sharing files and conversation history.
Its credential architecture follows the same principle. Supported outbound requests can pass through OneCLI’s Agent Vault, allowing credentials to be injected by a gateway rather than placed inside the agent container itself. NanoClaw also provides an optional egress-lockdown mode that puts agents on an internal Docker network and routes supported external traffic through the gateway.
OpenClaw 2.0 can now reproduce many elements of that hardened model. 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 key difference is the starting posture. 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. NanoClaw makes isolation more fundamental to how agent execution is structured.
So does OpenClaw 2.0 have security parity with NanoClaw?
In terms of available controls, it is much closer than before. In terms of defaults and architectural philosophy, no. An enterprise can configure OpenClaw into a substantially hardened environment, but it has to make that decision deliberately.
One Gateway is still one trust domain
Another limitation is particularly important for larger organizations. OpenClaw says a Gateway should be treated as a single trust domain.
Its new multi-user permissions are designed to govern collaboration among trusted users. They should not be treated as hard isolation between mutually untrusted tenants.
For organizations requiring stronger separation — between business units, customers or other security domains, for example — OpenClaw recommends separate Gateway instances, described as “cells,” with separate state, credentials and workspaces.
Fleet tooling for managing those cells remains experimental.
That distinction could matter significantly for enterprises considering OpenClaw as a centrally operated service.
Role-based access inside one Gateway may be sufficient for a trusted engineering department or internal team. It is a different proposition from a multi-tenant platform intended to isolate customers or users who should be assumed hostile to one another.
NanoClaw has its own configuration requirements and limitations, and even its stronger outbound-network lockdown remains optional. But its smaller architecture and container-centric execution model may appeal to organizations that want a narrower security boundary that is easier to reason about.
OpenClaw is optimizing for a broader problem.
OpenClaw’s biggest advantage may be the control plane
The tradeoff is product breadth.
NanoClaw emphasizes a relatively small codebase, container isolation and customization through code and skills. Its second-generation architecture supports owner, administrator and member roles, and a separate monitoring dashboard can provide visibility into deployments.
OpenClaw 2.0 is trying to build a much broader operational environment.
Its Control UI combines employee interaction, live execution, files, approvals, terminals, code review, model-provider configuration, devices and shared sessions.
That gives OpenClaw a potential advantage for enterprises that need not only secure agent execution but a usable control plane around it.
Security teams care about isolation. Platform teams also need deployment, authentication, model configuration, auditing and policy enforcement. Employees need an interface they can actually use. Managers need a way to understand what is running. Developers need access to the underlying files and tools when something goes wrong.
OpenClaw 2.0 increasingly tries to serve all of those constituencies through one system.
What is OpenAI’s role?
OpenClaw says 933 contributors, including 569 first-time contributors, participated in the release, which includes more than 16,000 pull requests — roughly half of all pull requests ever merged into the project.
Interestingly, the release was not shared by Steinberger’s employer, OpenAI. Recall that the Austrian developer announced on Feb. 14, 2026 that he was joining OpenAI to work on bringing agents to a broader audience, a move OpenAI CEO Sam Altman publicly confirmed the following day.
But OpenClaw was not folded into OpenAI. Steinberger said at the time that OpenClaw would move to a foundation and “stay open and independent,” while OpenAI would support the project. OpenClaw now says it is stewarded by the OpenClaw Foundation, an independent 501(c)(3), with OpenAI listed alongside Microsoft, GitHub, NVIDIA, Atlassian, Tencent and other organizations as partners.
Based on the available public information, OpenClaw 2.0 should therefore be understood as an OpenClaw Foundation release, not an OpenAI product or OpenAI software release, despite Steinberger’s employment at OpenAI and OpenAI’s financial and organizational support for the project.
Enterprise readiness now depends on configuration
OpenClaw 2.0 does not eliminate the security risks associated with autonomous agents, and its own documentation identifies limitations.
Secret Store values, for example, are not themselves encrypted at rest and rely on filesystem protections. Protected credential substitution does not cover every possible execution path, including some raw sockets, containers, remote nodes and provider-native harnessesIts multi-user permissions are collaboration controls, not hostile-tenant isolation.
Those caveats should prevent enterprises from interpreting OpenClaw 2.0 as secure-by-default agent infrastructure.But they also illustrate how much the conversation around the project has changed. The relevant comparison is increasingly not simply OpenClaw versus NanoClaw. It is a container-first, constrained system such as NanoClaw versus a deliberately hardened OpenClaw deployment that provides a substantially broader employee and administrator experience.
NanoClaw retains a strong proposition for organizations prioritizing a small attack surface, container-first execution and architectural simplicity.
OpenClaw is making another bet: that enterprises ultimately need an agent platform to function as both runtime and workplace.
OpenClaw 2.0 provides many of the primitives needed to build that environment — sandboxing, permissions, protected credentials, approvals, identity, auditing and isolated deployments — alongside a browser interface designed to make the system accessible to employees who will never configure an agent from a terminal.
The remaining caveat is important: enterprises have to turn those primitives into policy. OpenClaw 2.0 doesn’t automatically make OpenClaw enterprise-ready, but it does make an enterprise-grade OpenClaw deployment far easier out-of-the-box.
And as Steinberger’s description of OpenClaw’s own development process suggests, the long-term ambition may be larger still. Rather than giving every employee another AI assistant, OpenClaw is positioning the agent itself as shared infrastructure — a persistent layer where people, models and compute collaborate on the same work.
The viral fervor we saw earlier this year around OpenClaw, the open source AI harness that turns powerful language models into autonomous workers the user can message via their favorite channels (Telegram, iMessage, WhatsApp, Discord etc), has cooled off substantially from its peak in March 2026.
But over the weekend, OpenClaw’s creator Peter Steinberger and current team of co-developers gave the world — especially enterprises — a reason to look at it again, announcing OpenClaw 2.0, billed as the most significant update to the harness and surrounding platform yet.
OpenClaw 2.0 seeks to transform what began largely as a personal agent harness into something increasingly designed for teams, shared infrastructure and enterprise workflows.
OpenClaw 2.0 introduces a rebuilt browser interface that brings conversations, files, approvals, configuration and live agent activity into a common workspace. It adds shared cloud sessions and multi-user collaboration. And it expands the security model with stronger sandboxing, role-based permissions, approval controls, secrets handling and auditing.
Together, those additions move OpenClaw closer to being infrastructure that an organization could deploy for employees rather than simply a powerful agent an individual developer runs locally.
They also sharpen a competitive question surrounding the project: whether OpenClaw has addressed the security and isolation concerns that helped inspire newer alternatives such as NanoClaw.
The answer is increasingly yes at the capability level — but not necessarily by default.
OpenClaw wants to become the shared agent layer
Released under the official name of v2026.8.1, the update spans installation, messaging, memory, skills, models, automations, browser and native applications, plugins and security.
Steinberger described the development of OpenClaw 2.0 as an exercise in using the product to build itself.
“Two months ago, we started the mission to ‘build OpenClaw with OpenClaw,’” Steinberger wrote on X early on August 31.
Over that period, he said, OpenClaw gradually moved its team away from individual local coding harnesses and toward team.openclaw.ai, a shared agent environment aware of what team members are working on.
“Multiplayer coding + infinite compute with nodes and cloud sessions has been a game changer for how we build,” Steinberger wrote, adding that local harnesses now “feel like relics of the past.”
That claim points toward one of the more important changes in OpenClaw’s enterprise proposition.
The dominant model for AI coding agents has generally been individual: a developer runs an agent in a terminal, IDE or desktop application, gives it access to a repository and lets it execute work within that environment.
OpenClaw 2.0 is pushing toward something different. Agent sessions can become persistent workspaces that outlive a single terminal or employee. They can be shared with colleagues, executed across other machines or cloud workers, and supervised through a browser.
For enterprises, that potentially turns the agent from an employee-level productivity application into a shared operational layer.
A new UI could broaden OpenClaw beyond developers
The redesigned Control UI is central to that strategy.
OpenClaw has shifted away from an Overview-first web application and made conversations the primary interface. Threads sit in a sidebar, while the active conversation occupies the main workspace. Files, approvals, settings and ongoing agent activity remain accessible around it.
The design deliberately brings OpenClaw closer to the interaction model employees already know from OpenAI’s ChatGPT, Anthropic’s Claude, Google’s Gemini and other conversational AI products.
That lowers an important barrier to enterprise adoption. Open-source agent frameworks are often powerful precisely because they expose low-level configuration, terminals, tools and runtime controls. Those same characteristics can make them difficult to deploy beyond engineering organizations.
OpenClaw 2.0 attempts to preserve the underlying control while putting a conversational interface on top of it. An employee can ask an agent to perform work without treating the terminal as the primary product interface. But OpenClaw does not hide what is happening underneath. The Control UI can surface session files, terminal activity, Git-backed changes, pull-request state, browser activity and interactive dashboards.
The release also places more emphasis on observability during agent execution. Tool calls and results are paired more clearly, file changes can appear as focused diffs, command activity is easier to inspect, and long-running background tasks can remain visible alongside the conversation. That combination matters for enterprise use.
Employees get a simpler interface for delegating work. Technical users retain access to the artifacts and execution state behind the conversation. Administrators gain a centralized place to configure and supervise the system.
The redesigned Settings workspace now encompasses agents, memory, plugins, MCP servers, devices, communication channels and device pairing. OpenClaw also consolidates model-provider administration, including credential status and, where providers expose it, model availability, quota, account balance, budget and spending information.
Limited-access browser users can request administrator privileges rather than automatically receiving them, with another administrator required to approve the escalation.
These are not especially flashy agent features. For companies deploying AI systems to dozens or hundreds of employees, they may be among the most important additions in the release.
Multiplayer sessions turn agent context into shared context
OpenClaw 2.0 also expands the agent from a personal workspace into a collaborative one.
Shared cloud sessions allow another employee to enter work already in progress without discarding the context accumulated by the agent.
Multi-user Gateways — the service that connects users and agents to tools, files, credentials and other resources — can track who created a conversation and which prompts were submitted by identified participants.
Owners and administrators can determine whether another user can read a session, suggest changes, work in draft mode or participate directly.
The interface adds session ownership, participant attribution, presence and even typing indicators. For coding teams, that introduces a workflow closer to collaborative software development than traditional AI chat.
A developer could initiate a task and allow an agent to work on it remotely. Another engineer could inspect the resulting changes. A senior engineer or administrator could approve an operation requiring additional privileges. The work does not have to remain attached to the laptop or terminal where it started.
Sessions can also move execution to paired devices or cloud workers while maintaining the broader workspace.
For enterprises experimenting with long-running agents, that is significant. Persistent agents need mechanisms for shift changes, escalation, supervision and ownership transfer. Otherwise, organizations simply create fleets of personal agents whose state disappears into individual user environments.
OpenClaw is attempting to turn that state into collaborative infrastructure. Already, some teams outside the developers of the open source project are adopting it.
Colin Johnson, CEO of marketing metrics software firm Solvely, described a similar shift in his own development workflow in a post on X.
His team had already been using OpenClaw agents through Discord, where developers could assign tasks, run commands and interact with their development environment. But he said that model still felt like “messaging a bot”: developers could share access to an agent without actually sharing the agent’s working context.
The new multiplayer WebUI changed that, he wrote, because two developers could open the same live session, see the same history and artifacts, and add information without first exporting or reconstructing what the agent had already done. “We were working inside the same context,” Colin wrote.
In one example, another developer was taking over a project he had been working on; instead of preparing a traditional handoff document, Colin joined the developer’s existing agent thread and added the missing project context directly. “The session itself became the handoff document,” he wrote.
For enterprise teams, that is a useful illustration of why persistent multiplayer sessions may matter beyond convenience: agent context can become a shared work artifact rather than information trapped inside one employee’s private conversation.
Colin’s deployment also illustrates both the enterprise potential and the remaining security boundary. His team runs its OpenClaw Gateway on a development server reachable through GitHub authentication, Cloudflare Access and a Cloudflare Tunnel, with the Gateway itself listening only on the server’s loopback interface rather than an exposed public port.
But he explicitly cautioned that this does not make the shared Gateway a multitenant environment. The developers already trust one another with the repositories, tools and agent capabilities behind it. As he put it, Cloudflare controls who can enter the workspace, while OpenClaw tracks who created, owns or contributed to the work; stronger separation still requires separate infrastructure.
Security becomes much more enterprise-oriented
That shift creates a corresponding security problem: a shared agent can potentially act with broader organizational authority than one running on a developer laptop.
OpenClaw 2.0 responds with considerably more granular controls.
Approvals can now 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 being executed still matches what was originally reviewed.
Sessions can operate under different permission levels, including read-only, guarded, workspace and full-access modes, with the highest level restricted to administrators.
Organizations can also define operator roles that require sandboxed execution for sessions created by specific identities. OpenClaw says those requirements cannot be bypassed using 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 protection.
OpenClaw’s team-scoped Secret Store distinguishes protected secrets from ordinary environment data available to the agent. For supported requests, a protected credential can be substituted into a Gateway-hosted HTTPS request without exposing that credential directly to the model.
OpenClaw can also reference external systems including 1Password and Vault.
Auditing has expanded around execution identity, approvals, session actions and outbound messages. Plugin installation can trigger capability reviews associated with the specific artifact being installed.
Those controls address questions enterprises inevitably face when deploying agents: Who initiated an action? Which agent performed it? What resources could it access? Who approved the operation? And what happens to those permissions when work moves between people or machines?
NanoClaw still takes a different approach to security
OpenClaw’s changes also make the comparison with open source, enterprise-friendly rival NanoClaw more nuanced.
NanoClaw is one of several subsequent projects to emerge around the idea that AI agents need stronger isolation and simpler security boundaries. Its architecture places operating-system-level containment at the center of the design.
NanoClaw runs agents inside Docker containers, limits those containers to explicitly mounted filesystems and runs their processes as an unprivileged user. Sessions and agent groups can remain isolated rather than automatically sharing files and conversation history.
Its credential architecture follows the same principle. Supported outbound requests can pass through OneCLI’s Agent Vault, allowing credentials to be injected by a gateway rather than placed inside the agent container itself. NanoClaw also provides an optional egress-lockdown mode that puts agents on an internal Docker network and routes supported external traffic through the gateway.
OpenClaw 2.0 can now reproduce many elements of that hardened model. 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 key difference is the starting posture. 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. NanoClaw makes isolation more fundamental to how agent execution is structured.
So does OpenClaw 2.0 have security parity with NanoClaw?
In terms of available controls, it is much closer than before. In terms of defaults and architectural philosophy, no. An enterprise can configure OpenClaw into a substantially hardened environment, but it has to make that decision deliberately.
One Gateway is still one trust domain
Another limitation is particularly important for larger organizations. OpenClaw says a Gateway should be treated as a single trust domain.
Its new multi-user permissions are designed to govern collaboration among trusted users. They should not be treated as hard isolation between mutually untrusted tenants.
For organizations requiring stronger separation — between business units, customers or other security domains, for example — OpenClaw recommends separate Gateway instances, described as “cells,” with separate state, credentials and workspaces.
Fleet tooling for managing those cells remains experimental.
That distinction could matter significantly for enterprises considering OpenClaw as a centrally operated service.
Role-based access inside one Gateway may be sufficient for a trusted engineering department or internal team. It is a different proposition from a multi-tenant platform intended to isolate customers or users who should be assumed hostile to one another.
NanoClaw has its own configuration requirements and limitations, and even its stronger outbound-network lockdown remains optional. But its smaller architecture and container-centric execution model may appeal to organizations that want a narrower security boundary that is easier to reason about.
OpenClaw is optimizing for a broader problem.
OpenClaw’s biggest advantage may be the control plane
The tradeoff is product breadth.
NanoClaw emphasizes a relatively small codebase, container isolation and customization through code and skills. Its second-generation architecture supports owner, administrator and member roles, and a separate monitoring dashboard can provide visibility into deployments.
OpenClaw 2.0 is trying to build a much broader operational environment.
Its Control UI combines employee interaction, live execution, files, approvals, terminals, code review, model-provider configuration, devices and shared sessions.
That gives OpenClaw a potential advantage for enterprises that need not only secure agent execution but a usable control plane around it.
Security teams care about isolation. Platform teams also need deployment, authentication, model configuration, auditing and policy enforcement. Employees need an interface they can actually use. Managers need a way to understand what is running. Developers need access to the underlying files and tools when something goes wrong.
OpenClaw 2.0 increasingly tries to serve all of those constituencies through one system.
What is OpenAI’s role?
OpenClaw says 933 contributors, including 569 first-time contributors, participated in the release, which includes more than 16,000 pull requests — roughly half of all pull requests ever merged into the project.
Interestingly, the release was not shared by Steinberger’s employer, OpenAI. Recall that the Austrian developer announced on Feb. 14, 2026 that he was joining OpenAI to work on bringing agents to a broader audience, a move OpenAI CEO Sam Altman publicly confirmed the following day.
But OpenClaw was not folded into OpenAI. Steinberger said at the time that OpenClaw would move to a foundation and “stay open and independent,” while OpenAI would support the project. OpenClaw now says it is stewarded by the OpenClaw Foundation, an independent 501(c)(3), with OpenAI listed alongside Microsoft, GitHub, NVIDIA, Atlassian, Tencent and other organizations as partners.
Based on the available public information, OpenClaw 2.0 should therefore be understood as an OpenClaw Foundation release, not an OpenAI product or OpenAI software release, despite Steinberger’s employment at OpenAI and OpenAI’s financial and organizational support for the project.
Enterprise readiness now depends on configuration
OpenClaw 2.0 does not eliminate the security risks associated with autonomous agents, and its own documentation identifies limitations.
Secret Store values, for example, are not themselves encrypted at rest and rely on filesystem protections. Protected credential substitution does not cover every possible execution path, including some raw sockets, containers, remote nodes and provider-native harnessesIts multi-user permissions are collaboration controls, not hostile-tenant isolation.
Those caveats should prevent enterprises from interpreting OpenClaw 2.0 as secure-by-default agent infrastructure.But they also illustrate how much the conversation around the project has changed. The relevant comparison is increasingly not simply OpenClaw versus NanoClaw. It is a container-first, constrained system such as NanoClaw versus a deliberately hardened OpenClaw deployment that provides a substantially broader employee and administrator experience.
NanoClaw retains a strong proposition for organizations prioritizing a small attack surface, container-first execution and architectural simplicity.
OpenClaw is making another bet: that enterprises ultimately need an agent platform to function as both runtime and workplace.
OpenClaw 2.0 provides many of the primitives needed to build that environment — sandboxing, permissions, protected credentials, approvals, identity, auditing and isolated deployments — alongside a browser interface designed to make the system accessible to employees who will never configure an agent from a terminal.
The remaining caveat is important: enterprises have to turn those primitives into policy. OpenClaw 2.0 doesn’t automatically make OpenClaw enterprise-ready, but it does make an enterprise-grade OpenClaw deployment far easier out-of-the-box.
And as Steinberger’s description of OpenClaw’s own development process suggests, the long-term ambition may be larger still. Rather than giving every employee another AI assistant, OpenClaw is positioning the agent itself as shared infrastructure — a persistent layer where people, models and compute collaborate on the same work.
The viral fervor we saw earlier this year around OpenClaw, the open source AI harness that turns powerful language models into autonomous workers the user can message via their favorite channels (Telegram, iMessage, WhatsApp, Discord etc), has cooled off substantially from its peak in March 2026.
But over the weekend, OpenClaw’s creator Peter Steinberger and current team of co-developers gave the world — especially enterprises — a reason to look at it again, announcing OpenClaw 2.0, billed as the most significant update to the harness and surrounding platform yet.
OpenClaw 2.0 seeks to transform what began largely as a personal agent harness into something increasingly designed for teams, shared infrastructure and enterprise workflows.
OpenClaw 2.0 introduces a rebuilt browser interface that brings conversations, files, approvals, configuration and live agent activity into a common workspace. It adds shared cloud sessions and multi-user collaboration. And it expands the security model with stronger sandboxing, role-based permissions, approval controls, secrets handling and auditing.
Together, those additions move OpenClaw closer to being infrastructure that an organization could deploy for employees rather than simply a powerful agent an individual developer runs locally.
They also sharpen a competitive question surrounding the project: whether OpenClaw has addressed the security and isolation concerns that helped inspire newer alternatives such as NanoClaw.
The answer is increasingly yes at the capability level — but not necessarily by default.
OpenClaw wants to become the shared agent layer
Released under the official name of v2026.8.1, the update spans installation, messaging, memory, skills, models, automations, browser and native applications, plugins and security.
Steinberger described the development of OpenClaw 2.0 as an exercise in using the product to build itself.
“Two months ago, we started the mission to ‘build OpenClaw with OpenClaw,’” Steinberger wrote on X early on August 31.
Over that period, he said, OpenClaw gradually moved its team away from individual local coding harnesses and toward team.openclaw.ai, a shared agent environment aware of what team members are working on.
“Multiplayer coding + infinite compute with nodes and cloud sessions has been a game changer for how we build,” Steinberger wrote, adding that local harnesses now “feel like relics of the past.”
That claim points toward one of the more important changes in OpenClaw’s enterprise proposition.
The dominant model for AI coding agents has generally been individual: a developer runs an agent in a terminal, IDE or desktop application, gives it access to a repository and lets it execute work within that environment.
OpenClaw 2.0 is pushing toward something different. Agent sessions can become persistent workspaces that outlive a single terminal or employee. They can be shared with colleagues, executed across other machines or cloud workers, and supervised through a browser.
For enterprises, that potentially turns the agent from an employee-level productivity application into a shared operational layer.
A new UI could broaden OpenClaw beyond developers
The redesigned Control UI is central to that strategy.
OpenClaw has shifted away from an Overview-first web application and made conversations the primary interface. Threads sit in a sidebar, while the active conversation occupies the main workspace. Files, approvals, settings and ongoing agent activity remain accessible around it.
The design deliberately brings OpenClaw closer to the interaction model employees already know from OpenAI’s ChatGPT, Anthropic’s Claude, Google’s Gemini and other conversational AI products.
That lowers an important barrier to enterprise adoption. Open-source agent frameworks are often powerful precisely because they expose low-level configuration, terminals, tools and runtime controls. Those same characteristics can make them difficult to deploy beyond engineering organizations.
OpenClaw 2.0 attempts to preserve the underlying control while putting a conversational interface on top of it. An employee can ask an agent to perform work without treating the terminal as the primary product interface. But OpenClaw does not hide what is happening underneath. The Control UI can surface session files, terminal activity, Git-backed changes, pull-request state, browser activity and interactive dashboards.
The release also places more emphasis on observability during agent execution. Tool calls and results are paired more clearly, file changes can appear as focused diffs, command activity is easier to inspect, and long-running background tasks can remain visible alongside the conversation. That combination matters for enterprise use.
Employees get a simpler interface for delegating work. Technical users retain access to the artifacts and execution state behind the conversation. Administrators gain a centralized place to configure and supervise the system.
The redesigned Settings workspace now encompasses agents, memory, plugins, MCP servers, devices, communication channels and device pairing. OpenClaw also consolidates model-provider administration, including credential status and, where providers expose it, model availability, quota, account balance, budget and spending information.
Limited-access browser users can request administrator privileges rather than automatically receiving them, with another administrator required to approve the escalation.
These are not especially flashy agent features. For companies deploying AI systems to dozens or hundreds of employees, they may be among the most important additions in the release.
Multiplayer sessions turn agent context into shared context
OpenClaw 2.0 also expands the agent from a personal workspace into a collaborative one.
Shared cloud sessions allow another employee to enter work already in progress without discarding the context accumulated by the agent.
Multi-user Gateways — the service that connects users and agents to tools, files, credentials and other resources — can track who created a conversation and which prompts were submitted by identified participants.
Owners and administrators can determine whether another user can read a session, suggest changes, work in draft mode or participate directly.
The interface adds session ownership, participant attribution, presence and even typing indicators. For coding teams, that introduces a workflow closer to collaborative software development than traditional AI chat.
A developer could initiate a task and allow an agent to work on it remotely. Another engineer could inspect the resulting changes. A senior engineer or administrator could approve an operation requiring additional privileges. The work does not have to remain attached to the laptop or terminal where it started.
Sessions can also move execution to paired devices or cloud workers while maintaining the broader workspace.
For enterprises experimenting with long-running agents, that is significant. Persistent agents need mechanisms for shift changes, escalation, supervision and ownership transfer. Otherwise, organizations simply create fleets of personal agents whose state disappears into individual user environments.
OpenClaw is attempting to turn that state into collaborative infrastructure. Already, some teams outside the developers of the open source project are adopting it.
Colin Johnson, CEO of marketing metrics software firm Solvely, described a similar shift in his own development workflow in a post on X.
His team had already been using OpenClaw agents through Discord, where developers could assign tasks, run commands and interact with their development environment. But he said that model still felt like “messaging a bot”: developers could share access to an agent without actually sharing the agent’s working context.
The new multiplayer WebUI changed that, he wrote, because two developers could open the same live session, see the same history and artifacts, and add information without first exporting or reconstructing what the agent had already done. “We were working inside the same context,” Colin wrote.
In one example, another developer was taking over a project he had been working on; instead of preparing a traditional handoff document, Colin joined the developer’s existing agent thread and added the missing project context directly. “The session itself became the handoff document,” he wrote.
For enterprise teams, that is a useful illustration of why persistent multiplayer sessions may matter beyond convenience: agent context can become a shared work artifact rather than information trapped inside one employee’s private conversation.
Colin’s deployment also illustrates both the enterprise potential and the remaining security boundary. His team runs its OpenClaw Gateway on a development server reachable through GitHub authentication, Cloudflare Access and a Cloudflare Tunnel, with the Gateway itself listening only on the server’s loopback interface rather than an exposed public port.
But he explicitly cautioned that this does not make the shared Gateway a multitenant environment. The developers already trust one another with the repositories, tools and agent capabilities behind it. As he put it, Cloudflare controls who can enter the workspace, while OpenClaw tracks who created, owns or contributed to the work; stronger separation still requires separate infrastructure.
Security becomes much more enterprise-oriented
That shift creates a corresponding security problem: a shared agent can potentially act with broader organizational authority than one running on a developer laptop.
OpenClaw 2.0 responds with considerably more granular controls.
Approvals can now 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 being executed still matches what was originally reviewed.
Sessions can operate under different permission levels, including read-only, guarded, workspace and full-access modes, with the highest level restricted to administrators.
Organizations can also define operator roles that require sandboxed execution for sessions created by specific identities. OpenClaw says those requirements cannot be bypassed using 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 protection.
OpenClaw’s team-scoped Secret Store distinguishes protected secrets from ordinary environment data available to the agent. For supported requests, a protected credential can be substituted into a Gateway-hosted HTTPS request without exposing that credential directly to the model.
OpenClaw can also reference external systems including 1Password and Vault.
Auditing has expanded around execution identity, approvals, session actions and outbound messages. Plugin installation can trigger capability reviews associated with the specific artifact being installed.
Those controls address questions enterprises inevitably face when deploying agents: Who initiated an action? Which agent performed it? What resources could it access? Who approved the operation? And what happens to those permissions when work moves between people or machines?
NanoClaw still takes a different approach to security
OpenClaw’s changes also make the comparison with open source, enterprise-friendly rival NanoClaw more nuanced.
NanoClaw is one of several subsequent projects to emerge around the idea that AI agents need stronger isolation and simpler security boundaries. Its architecture places operating-system-level containment at the center of the design.
NanoClaw runs agents inside Docker containers, limits those containers to explicitly mounted filesystems and runs their processes as an unprivileged user. Sessions and agent groups can remain isolated rather than automatically sharing files and conversation history.
Its credential architecture follows the same principle. Supported outbound requests can pass through OneCLI’s Agent Vault, allowing credentials to be injected by a gateway rather than placed inside the agent container itself. NanoClaw also provides an optional egress-lockdown mode that puts agents on an internal Docker network and routes supported external traffic through the gateway.
OpenClaw 2.0 can now reproduce many elements of that hardened model. 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 key difference is the starting posture. 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. NanoClaw makes isolation more fundamental to how agent execution is structured.
So does OpenClaw 2.0 have security parity with NanoClaw?
In terms of available controls, it is much closer than before. In terms of defaults and architectural philosophy, no. An enterprise can configure OpenClaw into a substantially hardened environment, but it has to make that decision deliberately.
One Gateway is still one trust domain
Another limitation is particularly important for larger organizations. OpenClaw says a Gateway should be treated as a single trust domain.
Its new multi-user permissions are designed to govern collaboration among trusted users. They should not be treated as hard isolation between mutually untrusted tenants.
For organizations requiring stronger separation — between business units, customers or other security domains, for example — OpenClaw recommends separate Gateway instances, described as “cells,” with separate state, credentials and workspaces.
Fleet tooling for managing those cells remains experimental.
That distinction could matter significantly for enterprises considering OpenClaw as a centrally operated service.
Role-based access inside one Gateway may be sufficient for a trusted engineering department or internal team. It is a different proposition from a multi-tenant platform intended to isolate customers or users who should be assumed hostile to one another.
NanoClaw has its own configuration requirements and limitations, and even its stronger outbound-network lockdown remains optional. But its smaller architecture and container-centric execution model may appeal to organizations that want a narrower security boundary that is easier to reason about.
OpenClaw is optimizing for a broader problem.
OpenClaw’s biggest advantage may be the control plane
The tradeoff is product breadth.
NanoClaw emphasizes a relatively small codebase, container isolation and customization through code and skills. Its second-generation architecture supports owner, administrator and member roles, and a separate monitoring dashboard can provide visibility into deployments.
OpenClaw 2.0 is trying to build a much broader operational environment.
Its Control UI combines employee interaction, live execution, files, approvals, terminals, code review, model-provider configuration, devices and shared sessions.
That gives OpenClaw a potential advantage for enterprises that need not only secure agent execution but a usable control plane around it.
Security teams care about isolation. Platform teams also need deployment, authentication, model configuration, auditing and policy enforcement. Employees need an interface they can actually use. Managers need a way to understand what is running. Developers need access to the underlying files and tools when something goes wrong.
OpenClaw 2.0 increasingly tries to serve all of those constituencies through one system.
What is OpenAI’s role?
OpenClaw says 933 contributors, including 569 first-time contributors, participated in the release, which includes more than 16,000 pull requests — roughly half of all pull requests ever merged into the project.
Interestingly, the release was not shared by Steinberger’s employer, OpenAI. Recall that the Austrian developer announced on Feb. 14, 2026 that he was joining OpenAI to work on bringing agents to a broader audience, a move OpenAI CEO Sam Altman publicly confirmed the following day.
But OpenClaw was not folded into OpenAI. Steinberger said at the time that OpenClaw would move to a foundation and “stay open and independent,” while OpenAI would support the project. OpenClaw now says it is stewarded by the OpenClaw Foundation, an independent 501(c)(3), with OpenAI listed alongside Microsoft, GitHub, NVIDIA, Atlassian, Tencent and other organizations as partners.
Based on the available public information, OpenClaw 2.0 should therefore be understood as an OpenClaw Foundation release, not an OpenAI product or OpenAI software release, despite Steinberger’s employment at OpenAI and OpenAI’s financial and organizational support for the project.
Enterprise readiness now depends on configuration
OpenClaw 2.0 does not eliminate the security risks associated with autonomous agents, and its own documentation identifies limitations.
Secret Store values, for example, are not themselves encrypted at rest and rely on filesystem protections. Protected credential substitution does not cover every possible execution path, including some raw sockets, containers, remote nodes and provider-native harnessesIts multi-user permissions are collaboration controls, not hostile-tenant isolation.
Those caveats should prevent enterprises from interpreting OpenClaw 2.0 as secure-by-default agent infrastructure.But they also illustrate how much the conversation around the project has changed. The relevant comparison is increasingly not simply OpenClaw versus NanoClaw. It is a container-first, constrained system such as NanoClaw versus a deliberately hardened OpenClaw deployment that provides a substantially broader employee and administrator experience.
NanoClaw retains a strong proposition for organizations prioritizing a small attack surface, container-first execution and architectural simplicity.
OpenClaw is making another bet: that enterprises ultimately need an agent platform to function as both runtime and workplace.
OpenClaw 2.0 provides many of the primitives needed to build that environment — sandboxing, permissions, protected credentials, approvals, identity, auditing and isolated deployments — alongside a browser interface designed to make the system accessible to employees who will never configure an agent from a terminal.
The remaining caveat is important: enterprises have to turn those primitives into policy. OpenClaw 2.0 doesn’t automatically make OpenClaw enterprise-ready, but it does make an enterprise-grade OpenClaw deployment far easier out-of-the-box.
And as Steinberger’s description of OpenClaw’s own development process suggests, the long-term ambition may be larger still. Rather than giving every employee another AI assistant, OpenClaw is positioning the agent itself as shared infrastructure — a persistent layer where people, models and compute collaborate on the same work.
The viral fervor we saw earlier this year around OpenClaw, the open source AI harness that turns powerful language models into autonomous workers the user can message via their favorite channels (Telegram, iMessage, WhatsApp, Discord etc), has cooled off substantially from its peak in March 2026.
But over the weekend, OpenClaw’s creator Peter Steinberger and current team of co-developers gave the world — especially enterprises — a reason to look at it again, announcing OpenClaw 2.0, billed as the most significant update to the harness and surrounding platform yet.
OpenClaw 2.0 seeks to transform what began largely as a personal agent harness into something increasingly designed for teams, shared infrastructure and enterprise workflows.
OpenClaw 2.0 introduces a rebuilt browser interface that brings conversations, files, approvals, configuration and live agent activity into a common workspace. It adds shared cloud sessions and multi-user collaboration. And it expands the security model with stronger sandboxing, role-based permissions, approval controls, secrets handling and auditing.
Together, those additions move OpenClaw closer to being infrastructure that an organization could deploy for employees rather than simply a powerful agent an individual developer runs locally.
They also sharpen a competitive question surrounding the project: whether OpenClaw has addressed the security and isolation concerns that helped inspire newer alternatives such as NanoClaw.
The answer is increasingly yes at the capability level — but not necessarily by default.
OpenClaw wants to become the shared agent layer
Released under the official name of v2026.8.1, the update spans installation, messaging, memory, skills, models, automations, browser and native applications, plugins and security.
Steinberger described the development of OpenClaw 2.0 as an exercise in using the product to build itself.
“Two months ago, we started the mission to ‘build OpenClaw with OpenClaw,’” Steinberger wrote on X early on August 31.
Over that period, he said, OpenClaw gradually moved its team away from individual local coding harnesses and toward team.openclaw.ai, a shared agent environment aware of what team members are working on.
“Multiplayer coding + infinite compute with nodes and cloud sessions has been a game changer for how we build,” Steinberger wrote, adding that local harnesses now “feel like relics of the past.”
That claim points toward one of the more important changes in OpenClaw’s enterprise proposition.
The dominant model for AI coding agents has generally been individual: a developer runs an agent in a terminal, IDE or desktop application, gives it access to a repository and lets it execute work within that environment.
OpenClaw 2.0 is pushing toward something different. Agent sessions can become persistent workspaces that outlive a single terminal or employee. They can be shared with colleagues, executed across other machines or cloud workers, and supervised through a browser.
For enterprises, that potentially turns the agent from an employee-level productivity application into a shared operational layer.
A new UI could broaden OpenClaw beyond developers
The redesigned Control UI is central to that strategy.
OpenClaw has shifted away from an Overview-first web application and made conversations the primary interface. Threads sit in a sidebar, while the active conversation occupies the main workspace. Files, approvals, settings and ongoing agent activity remain accessible around it.
The design deliberately brings OpenClaw closer to the interaction model employees already know from OpenAI’s ChatGPT, Anthropic’s Claude, Google’s Gemini and other conversational AI products.
That lowers an important barrier to enterprise adoption. Open-source agent frameworks are often powerful precisely because they expose low-level configuration, terminals, tools and runtime controls. Those same characteristics can make them difficult to deploy beyond engineering organizations.
OpenClaw 2.0 attempts to preserve the underlying control while putting a conversational interface on top of it. An employee can ask an agent to perform work without treating the terminal as the primary product interface. But OpenClaw does not hide what is happening underneath. The Control UI can surface session files, terminal activity, Git-backed changes, pull-request state, browser activity and interactive dashboards.
The release also places more emphasis on observability during agent execution. Tool calls and results are paired more clearly, file changes can appear as focused diffs, command activity is easier to inspect, and long-running background tasks can remain visible alongside the conversation. That combination matters for enterprise use.
Employees get a simpler interface for delegating work. Technical users retain access to the artifacts and execution state behind the conversation. Administrators gain a centralized place to configure and supervise the system.
The redesigned Settings workspace now encompasses agents, memory, plugins, MCP servers, devices, communication channels and device pairing. OpenClaw also consolidates model-provider administration, including credential status and, where providers expose it, model availability, quota, account balance, budget and spending information.
Limited-access browser users can request administrator privileges rather than automatically receiving them, with another administrator required to approve the escalation.
These are not especially flashy agent features. For companies deploying AI systems to dozens or hundreds of employees, they may be among the most important additions in the release.
Multiplayer sessions turn agent context into shared context
OpenClaw 2.0 also expands the agent from a personal workspace into a collaborative one.
Shared cloud sessions allow another employee to enter work already in progress without discarding the context accumulated by the agent.
Multi-user Gateways — the service that connects users and agents to tools, files, credentials and other resources — can track who created a conversation and which prompts were submitted by identified participants.
Owners and administrators can determine whether another user can read a session, suggest changes, work in draft mode or participate directly.
The interface adds session ownership, participant attribution, presence and even typing indicators. For coding teams, that introduces a workflow closer to collaborative software development than traditional AI chat.
A developer could initiate a task and allow an agent to work on it remotely. Another engineer could inspect the resulting changes. A senior engineer or administrator could approve an operation requiring additional privileges. The work does not have to remain attached to the laptop or terminal where it started.
Sessions can also move execution to paired devices or cloud workers while maintaining the broader workspace.
For enterprises experimenting with long-running agents, that is significant. Persistent agents need mechanisms for shift changes, escalation, supervision and ownership transfer. Otherwise, organizations simply create fleets of personal agents whose state disappears into individual user environments.
OpenClaw is attempting to turn that state into collaborative infrastructure. Already, some teams outside the developers of the open source project are adopting it.
Colin Johnson, CEO of marketing metrics software firm Solvely, described a similar shift in his own development workflow in a post on X.
His team had already been using OpenClaw agents through Discord, where developers could assign tasks, run commands and interact with their development environment. But he said that model still felt like “messaging a bot”: developers could share access to an agent without actually sharing the agent’s working context.
The new multiplayer WebUI changed that, he wrote, because two developers could open the same live session, see the same history and artifacts, and add information without first exporting or reconstructing what the agent had already done. “We were working inside the same context,” Colin wrote.
In one example, another developer was taking over a project he had been working on; instead of preparing a traditional handoff document, Colin joined the developer’s existing agent thread and added the missing project context directly. “The session itself became the handoff document,” he wrote.
For enterprise teams, that is a useful illustration of why persistent multiplayer sessions may matter beyond convenience: agent context can become a shared work artifact rather than information trapped inside one employee’s private conversation.
Colin’s deployment also illustrates both the enterprise potential and the remaining security boundary. His team runs its OpenClaw Gateway on a development server reachable through GitHub authentication, Cloudflare Access and a Cloudflare Tunnel, with the Gateway itself listening only on the server’s loopback interface rather than an exposed public port.
But he explicitly cautioned that this does not make the shared Gateway a multitenant environment. The developers already trust one another with the repositories, tools and agent capabilities behind it. As he put it, Cloudflare controls who can enter the workspace, while OpenClaw tracks who created, owns or contributed to the work; stronger separation still requires separate infrastructure.
Security becomes much more enterprise-oriented
That shift creates a corresponding security problem: a shared agent can potentially act with broader organizational authority than one running on a developer laptop.
OpenClaw 2.0 responds with considerably more granular controls.
Approvals can now 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 being executed still matches what was originally reviewed.
Sessions can operate under different permission levels, including read-only, guarded, workspace and full-access modes, with the highest level restricted to administrators.
Organizations can also define operator roles that require sandboxed execution for sessions created by specific identities. OpenClaw says those requirements cannot be bypassed using 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 protection.
OpenClaw’s team-scoped Secret Store distinguishes protected secrets from ordinary environment data available to the agent. For supported requests, a protected credential can be substituted into a Gateway-hosted HTTPS request without exposing that credential directly to the model.
OpenClaw can also reference external systems including 1Password and Vault.
Auditing has expanded around execution identity, approvals, session actions and outbound messages. Plugin installation can trigger capability reviews associated with the specific artifact being installed.
Those controls address questions enterprises inevitably face when deploying agents: Who initiated an action? Which agent performed it? What resources could it access? Who approved the operation? And what happens to those permissions when work moves between people or machines?
NanoClaw still takes a different approach to security
OpenClaw’s changes also make the comparison with open source, enterprise-friendly rival NanoClaw more nuanced.
NanoClaw is one of several subsequent projects to emerge around the idea that AI agents need stronger isolation and simpler security boundaries. Its architecture places operating-system-level containment at the center of the design.
NanoClaw runs agents inside Docker containers, limits those containers to explicitly mounted filesystems and runs their processes as an unprivileged user. Sessions and agent groups can remain isolated rather than automatically sharing files and conversation history.
Its credential architecture follows the same principle. Supported outbound requests can pass through OneCLI’s Agent Vault, allowing credentials to be injected by a gateway rather than placed inside the agent container itself. NanoClaw also provides an optional egress-lockdown mode that puts agents on an internal Docker network and routes supported external traffic through the gateway.
OpenClaw 2.0 can now reproduce many elements of that hardened model. 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 key difference is the starting posture. 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. NanoClaw makes isolation more fundamental to how agent execution is structured.
So does OpenClaw 2.0 have security parity with NanoClaw?
In terms of available controls, it is much closer than before. In terms of defaults and architectural philosophy, no. An enterprise can configure OpenClaw into a substantially hardened environment, but it has to make that decision deliberately.
One Gateway is still one trust domain
Another limitation is particularly important for larger organizations. OpenClaw says a Gateway should be treated as a single trust domain.
Its new multi-user permissions are designed to govern collaboration among trusted users. They should not be treated as hard isolation between mutually untrusted tenants.
For organizations requiring stronger separation — between business units, customers or other security domains, for example — OpenClaw recommends separate Gateway instances, described as “cells,” with separate state, credentials and workspaces.
Fleet tooling for managing those cells remains experimental.
That distinction could matter significantly for enterprises considering OpenClaw as a centrally operated service.
Role-based access inside one Gateway may be sufficient for a trusted engineering department or internal team. It is a different proposition from a multi-tenant platform intended to isolate customers or users who should be assumed hostile to one another.
NanoClaw has its own configuration requirements and limitations, and even its stronger outbound-network lockdown remains optional. But its smaller architecture and container-centric execution model may appeal to organizations that want a narrower security boundary that is easier to reason about.
OpenClaw is optimizing for a broader problem.
OpenClaw’s biggest advantage may be the control plane
The tradeoff is product breadth.
NanoClaw emphasizes a relatively small codebase, container isolation and customization through code and skills. Its second-generation architecture supports owner, administrator and member roles, and a separate monitoring dashboard can provide visibility into deployments.
OpenClaw 2.0 is trying to build a much broader operational environment.
Its Control UI combines employee interaction, live execution, files, approvals, terminals, code review, model-provider configuration, devices and shared sessions.
That gives OpenClaw a potential advantage for enterprises that need not only secure agent execution but a usable control plane around it.
Security teams care about isolation. Platform teams also need deployment, authentication, model configuration, auditing and policy enforcement. Employees need an interface they can actually use. Managers need a way to understand what is running. Developers need access to the underlying files and tools when something goes wrong.
OpenClaw 2.0 increasingly tries to serve all of those constituencies through one system.
What is OpenAI’s role?
OpenClaw says 933 contributors, including 569 first-time contributors, participated in the release, which includes more than 16,000 pull requests — roughly half of all pull requests ever merged into the project.
Interestingly, the release was not shared by Steinberger’s employer, OpenAI. Recall that the Austrian developer announced on Feb. 14, 2026 that he was joining OpenAI to work on bringing agents to a broader audience, a move OpenAI CEO Sam Altman publicly confirmed the following day.
But OpenClaw was not folded into OpenAI. Steinberger said at the time that OpenClaw would move to a foundation and “stay open and independent,” while OpenAI would support the project. OpenClaw now says it is stewarded by the OpenClaw Foundation, an independent 501(c)(3), with OpenAI listed alongside Microsoft, GitHub, NVIDIA, Atlassian, Tencent and other organizations as partners.
Based on the available public information, OpenClaw 2.0 should therefore be understood as an OpenClaw Foundation release, not an OpenAI product or OpenAI software release, despite Steinberger’s employment at OpenAI and OpenAI’s financial and organizational support for the project.
Enterprise readiness now depends on configuration
OpenClaw 2.0 does not eliminate the security risks associated with autonomous agents, and its own documentation identifies limitations.
Secret Store values, for example, are not themselves encrypted at rest and rely on filesystem protections. Protected credential substitution does not cover every possible execution path, including some raw sockets, containers, remote nodes and provider-native harnessesIts multi-user permissions are collaboration controls, not hostile-tenant isolation.
Those caveats should prevent enterprises from interpreting OpenClaw 2.0 as secure-by-default agent infrastructure.But they also illustrate how much the conversation around the project has changed. The relevant comparison is increasingly not simply OpenClaw versus NanoClaw. It is a container-first, constrained system such as NanoClaw versus a deliberately hardened OpenClaw deployment that provides a substantially broader employee and administrator experience.
NanoClaw retains a strong proposition for organizations prioritizing a small attack surface, container-first execution and architectural simplicity.
OpenClaw is making another bet: that enterprises ultimately need an agent platform to function as both runtime and workplace.
OpenClaw 2.0 provides many of the primitives needed to build that environment — sandboxing, permissions, protected credentials, approvals, identity, auditing and isolated deployments — alongside a browser interface designed to make the system accessible to employees who will never configure an agent from a terminal.
The remaining caveat is important: enterprises have to turn those primitives into policy. OpenClaw 2.0 doesn’t automatically make OpenClaw enterprise-ready, but it does make an enterprise-grade OpenClaw deployment far easier out-of-the-box.
And as Steinberger’s description of OpenClaw’s own development process suggests, the long-term ambition may be larger still. Rather than giving every employee another AI assistant, OpenClaw is positioning the agent itself as shared infrastructure — a persistent layer where people, models and compute collaborate on the same work.
