OpenClaw 2.0 ends a two-month freeze with 16,000 PRs, a one-way session migration, and sandboxing off by default

388,449 stars. 106 releases in 230 days, then nothing, then this.

OpenClaw tagged v2026.8.1 at 03:30 UTC on August 31, branding it 2.0 and treating it as the project's first real major version. The scale is the first thing you notice: more than 16,000 pull requests folded in, about half the project's lifetime total, from 933 contributors of whom 569 were first-time committers (GitHub). That is what a deliberate freeze buys you. It also tells you why the freeze existed.

The headline feature is multiplayer. Persistent cloud sessions run on rented machines, teammates join mid-run with participant attribution and per-person permission levels, and setup auto-detects your existing ChatGPT or Claude subscription, API keys, or local models (VentureBeat). If you have ever tried to hand a running agent session to a colleague, you know why that matters. If you have ever watched a colleague approve something in your session, you also know why the next paragraph matters more.

Sandboxing and execution approvals ship disabled. You turn them on deliberately. Combine that default with shared cloud sessions on rented machines and you have a multi-user execution environment where nobody had to opt into isolation, which is a shape I would not deploy at work without reading the permission model line by line first.

The upgrade trap is storage. Sessions and transcripts move from file-backed storage to SQLite, older releases cannot read migrated sessions, and downgrading requires restoring legacy artifacts through the CLI. That is a one-way door. Back up your session directory before you run the migration, and if you have any tooling that reads OpenClaw transcripts off disk, it is broken as of this release.

Security defaults did tighten in useful ways: network installs without authentication are blocked before startup, remote Gateway credentials are validated before onboarding promotion, unencrypted LAN connections are held in Limited mode, and certificate pinning is enforced for LAN and IP connections on Android. So the project clearly spent freeze time on hardening. It just chose to leave the two controls that constrain what the agent can do to your machine turned off, and I would like to know the reasoning, because "the user will enable it" has an evidence base and it is not good.

Practical move: upgrade in a scratch clone first, migrate sessions there, confirm your tooling still reads them, then enable sandboxing and approvals before you point it at anything real.