The OpenClaw Foundation released v2026.8.1 as "OpenClaw 2.0" on August 31, 2026. What began as an installation overhaul and a rebuilt browser interface grew into a system that lets multiple people hand off the same conversation and move processing to a different device or the cloud. The Gateway now holds the conversation, credentials, and workspace, while execution location and the person in charge can be swapped later. It's an update that pushes a personal AI assistant into the role of a control plane for handing off team work.
933 contributors and more than 16,000 PRs behind "2.0"
According to the official blog, 933 people took part in this update, 569 of them first-time contributors. More than 16,000 pull requests were merged—roughly half of all PRs OpenClaw has integrated to date. The official version number is 2026.8.1; "2.0" is simply a name reflecting the scale of the changes.
That scale stands out against OpenClaw's usual release pace. Over the preceding 230 days, the project had shipped 106 releases—roughly one every one to two days. This time, official releases were paused for about seven weeks while the team tested fresh installs and upgrades from existing environments side by side. Rebuilding the installation screen required rethinking how state is saved, overhauling session management, tightening permissions, and enabling cloud-based processing.
For new users, the setup process now detects a local ChatGPT or Claude subscription, API keys, or local models to use for initial configuration. Instead of requiring every field to be filled in upfront, users can start a conversation first and finish the rest of the setup afterward. OpenClaw shortened the entry point while gathering the features needed for larger-scale operation around that same conversation.
A browser dashboard for overseeing work from within the conversation
The Control UI (browser dashboard) is a single-page app built with Vite and Lit, served by the Gateway. The new version opens directly into a conversation, giving access to settings, ongoing tasks, and execution status from the same screen. A session progress panel next to the chat shows current status, plan progress, pull requests, and elapsed time, and keeps tracking even after a page reload.
A side thread's job is to oversee long-running agents. When a user asks a question about an active session, the Gateway reads the visible history and workspace and has a separate, smaller model answer it—without writing into the main execution conversation or interrupting the agent. The chat box has shifted from a place to type commands into a screen for watching work unfold and stepping in with judgment calls.
When used by multiple people, the browser dashboard also shows who created a session, who currently owns it, and who has participated. Viewer presence and typing indicators are treated as temporary information—partially typed text is never saved to history or fed into the model's context. It's a design that separates the content of a conversation from the state of people watching it simultaneously.
The conversation stays on the Gateway; only processing moves
In OpenClaw 2.0, the same session can run in one of three places. Normally, processing happens on the machine running the Gateway, but users can switch to a paired device they own or to a cloud worker that's discarded after use. OpenClaw's regular execution and Codex's remote execution can use the same set of destinations.
| Execution target | Processing machine | Best suited for | Permission needed to deploy |
|---|---|---|---|
| Gateway | Host running the Gateway | Everyday sessions | No additional permission |
| Paired device | Local Mac, build machine, owned server | Work using existing hardware | operator.write |
| Cloud worker | Rented, disposable cloud machine | Temporary parallel work, long-running tasks, isolation from local device | operator.admin |
What these three execution targets change is not where the conversation lives, but which machine does the processing. The Gateway retains the conversation, the reconciled workspace, model credentials, and deployment records. Remote machines are entrusted with running commands, editing files, and processing tool calls, but model queries are relayed through the Gateway, so provider credentials are never handed to the remote machine.
This separation shows up in how recovery works, too. If a cloud worker stops or is destroyed, the session and the last-synced work remain on the Gateway side, and a replacement machine can be provisioned on the next message. If a paired device goes offline, the Gateway remembers the deployment target and waits for that device to come back. Cloud workers are an optional feature that only appears in configured environments, and the official documentation doesn't publish measured figures for processing speed, cost, or recovery time.
This is where OpenClaw 2.0's design change comes in. By not pinning a session to a specific PC and instead assigning execution targets to a conversation owned by the Gateway, both the person and the machine involved can be swapped mid-task. The browser overhaul and shared sessions are both built on this same state-management foundation.
"Multiplayer" is not a security boundary
OpenClaw's multi-user feature is designed for collaboration among trusted people, and it does not treat owner labels or participation history as isolation boundaries. The official documentation states explicitly that if a person can operate an agent, that person can also instruct the agent to do anything the agent is capable of. It's a feature for families or teams sharing a single agent—not a mechanism for housing mutually distrustful customers in the same environment.
A session has three kinds of records: creator, owner, and participants. The creator generally never changes and serves as the starting point for permissions that determine who can share the session. The owner is similar to an assignee on a GitHub Issue—it can be reassigned to a person or an agent, but changing the assignment display does not transfer access rights. Participants are the history of people or agents who actually entered input; someone who only viewed the session is not included.
Access control is handled by a separate layer. Team roles configure whether a user can read other people's sessions, which agents they can use, how much operating authority they're granted, and whether new sessions require a sandbox. Operating authority ranges from view-focused operator.read, to operator.write which allows sending messages and operating tools, up to operator.admin, which includes changing settings and approving high-risk actions.
On top of that, session permission modes determine the scope of file operations. read-only allows reading only; guarded requires a human to approve writes within the workspace; workspace has the model review execution within that same scope. full places no restrictions on the file system and requires administrator privileges to use. The official documentation notes that in environments without explicit permission settings or a sandbox, the default may fall back to full.
In other words, the assignee avatar, the role, and the session permission each do a different job. The avatar shows who's responsible, the role restricts operations on the Gateway, and the session permission limits the scope of files and commands. If strong separation between clients or departments is required, the official recommendation is to run a separate Gateway under a different OS user or on a different host.
What to check before updating—before exploring new features
Existing users face two breaking changes. One is the removal of the bundled OpenProse plugin and the /prose command; the other is a change that migrates codex/* and openai-codex/* model references and saved sessions to openai/*. Both changes are documented as migratable via openclaw doctor --fix.
There's also an SDK migration notice for external plugin developers, dated September 1, 2026. However, this is advance notice to prepare for future removal—the affected APIs were not immediately removed in v2026.8.1. The urgency of the response differs depending on whether someone is simply using a plugin or is a developer distributing one.
What's easy to overlook is not the added features but the changes to default behavior. In personal environments, several things now run by default: extracting relevant context from private conversations with the same agent, background memory consolidation, and automatic application of approved skills. Conversations persist across date boundaries and idle periods, and the concurrency limit for top-level agents is set to 8 or 16 depending on CPU parallelism. After updating, even with the same configuration file as before, the memory an agent references and the number of jobs it runs concurrently may change.
State storage has also shifted primarily to SQLite, making a pre-update backup essential. The official update procedure calls for saving configuration and state, then running doctor, and confirming the Gateway starts up correctly. If you roll back to an older version after the SQLite migration, sessions created after the migration won't be visible from the old runtime. Rolling back code and rolling back state to an earlier point need to be treated as separate operations.
Whether OpenClaw 2.0 can be adopted as a shared work platform doesn't come down to the number of features. It requires separating Gateways by circle of trust, explicitly setting roles and session permissions, testing state backup and recovery, and measuring actual remote-execution costs and sync times. Once those conditions are in place, teams can hand off long-running work without losing conversational context, even as the person in charge or the executing machine changes.