What Changed in OpenClaw 2.0: Sessions, Plugins, Keys

If you already run OpenClaw, here is what OpenClaw 2.0 changes for your install: sessions and transcripts move into SQLite — and sessions created after the migration will not appear in older releases — plugin installs from a new source outside ClawHub and the official catalog now warn before code lands, and credentials get a team-scoped Secret Store that separates protected values from agent-readable ones. The tag is v2026.8.1: the vendor’s announcement blog is timestamped 12:00 UTC on August 30, 2026, and the GitHub release was published at 03:30 UTC on August 31.

The vendor calls it the largest update in the project’s history, and for once the structural evidence backs the adjective. But the most telling change is one no headline led with: between tag v2026.7.1 and tag v2026.8.1, the security documentation renamed its scope heading from “personal assistant security model” to “one trust boundary per gateway” — in the same release that taught sessions to run on other machines and be shared with teammates. The change list is below; the upgrade decisions are in section 07.

First, the name. There is no semver 2.0.0: the project uses a CalVer-shaped scheme — calendar versioning in the form YYYY.M.N — and the vendor’s own release notes title the release “v2026.8.1 (AKA OpenClaw 2.0)”. The dates split across two artifacts: the announcement blog post carries a published time of 12:00 UTC on August 30, while the GitHub release went public at 03:30 UTC on August 31 — the announcement ran roughly fifteen hours ahead of the tag. One housekeeping note the release notes make themselves: a package published as 2026.9.1-beta.1 was mis-versioned and is actually 2026.8.1-beta.4 — it is not newer than stable 2026.8.1.

Four change areas carry the release. A fifth, un-headlined one is structural: fourteen named integrations — BytePlus, ComfyUI, Mistral, NovitaAI, OpenCode, Synthetic, Volcengine, Vydra and Xiaomi in one batch; Cohere, Meta providers, DuckDuckGo search, Voyage embeddings and iMessage in a second — moved out of the core install into separately installed official packages. The default install got smaller; more of the surface became opt-in plugins. If you are installing OpenClaw for the first time rather than upgrading, our setup guide owns that path — this post is about what moved.

One term recurs from here on: the Gateway is OpenClaw’s long-running process — plugins run in-process with it, and provider credentials stay behind it. On the performance figures, the vendor was more careful than most of its coverage. The release notes state both numbers with their methodology attached — request counts and startup time from one simulated scenario — and much of the trade coverage we sampled ran the 575 ms figure bare. Help Net Security was the exception that reproduced the qualifier in full. Here is the sentence as the vendor wrote it:

Read it precisely: 140 to 45 is a count of JavaScript HTTP requests, not kilobytes or modules; 1.6 seconds to 575 milliseconds is cold startup to Chat in a single scenario, against a mocked Gateway, with 50 ms of simulated latency — no sample size, no variance, no hardware stated. “Roughly 2.8× faster in the vendor’s own mocked test” is defensible. “2.8× faster”, unqualified, is not — and that is the version most headlines shipped.

The release notes’ own warning box is blunt: “This release changes how sessions and transcripts are stored by moving them into SQLite. Before downgrading to an older file-backed release, use the current CLI to restore archived legacy transcript artifacts; sessions created after the migration will not appear in older releases.” In practice that makes the migration one-way: the rollback path is “restore archived legacy artifacts”, not “reinstall the old version”. The same box tells you to create a verified backup before upgrading, and the release ships matching tooling — openclaw backup sqlite creates, lists, verifies and restores database snapshots. Note that sessions are not the only thing that moved: the new credential store (section 05) is SQLite too, so the headline undersells the scope of the storage change.

Sessions also stopped being single-machine. A session can now run in three placements: on the Gateway host, on a paired device, or on a cloud worker, which the new Cloud Sessions documentation describes as “a throwaway machine leased through Crabbox”, disposable by design, with no standing credentials on it. The credential sentence that makes this a different proposition from copying an API key onto a rented box:

The vendor also draws an explicit limit on the shared-session feature, and it belongs next to the feature rather than in a footnote: the release notes say the collaboration controls “are not tenant isolation or a security boundary, and revoked access can briefly look available until the UI refreshes or the Gateway rejects the action”. The GitHub release body compresses it to “these are collaboration controls, not hostile-tenant isolation”. Multiplayer sessions are for people who already trust each other — which is exactly the framing the renamed security scope formalises in the next section.

Every write-up we reviewed quotes “one trust boundary per gateway” as a 2.0 slogan. None of them noted that the phrase is new — or where it lives. It is not release-note language: it comes from the security documentation, docs/gateway/security/index.md. We fetched that file as shipped at three git tags. The phrase appears three times at v2026.8.1 and zero times at both v2026.7.1 and v2026.6.11. And the section heading itself was renamed between releases: at v2026.7.1 it read “Scope: personal assistant security model”; at v2026.8.1 the same heading reads “Scope: one trust boundary per gateway”. A release that added team sessions renamed its security scope away from “personal assistant”.

The new wording is careful. A trust boundary — the perimeter inside which every user and process is assumed to trust the others — used to be defined as “one user/trust boundary per gateway”. The 2.0 text widens it: “Supported: one trust boundary per gateway - a single operator or a mutually trusting team (prefer one OS user/host/VPS per boundary). Not supported: one shared gateway/agent used by mutually untrusted or adversarial users.” So the boundary grew from one person to one trusting team, while the not-supported language around it hardened. The rename is not cosmetic bookkeeping either — the documentation set physically grew around it. Five security- and credential-adjacent pages exist at v2026.8.1 that did not exist at v2026.7.1:

The inventory turns “2.0 reworked security” from a claim into a list. One caution on reading it: presence is HTTP status at each tag, not proof of new functionality — content can move between paths. But five new pages covering cloud placement, credential brokering, dependency locking and tenant separation, landing in the same release as team sessions, is a coherent story: the project stopped describing itself as a personal assistant and started documenting where one trust boundary ends and the next begins.

The context for this section is February: the ClawHavoc incident, in which malicious ClawHub skills disguised as cryptocurrency wallets and trading bots delivered credential-stealing malware to OpenClaw users — our analysis at the time covers it. 2.0’s install rules read as the direct answer, and the security doc diff makes the answer specific. New at v2026.8.1, with no equivalent sentence at v2026.7.1: “ClawHub packages and OpenClaw’s bundled/official catalog are trusted sources. A new arbitrary npm, npm-pack:, git, local path/archive, or marketplace source warns before install; noninteractive installs require --force after you review and trust that source.”

The concrete mechanics stack up. A policy warn result stops before commit, and interactive commands make you type the plugin or skill name back before continuing. A rendered review longer than 4,000 characters fails closed before prompting. Capability review is bound to the exact artifact being installed and asks again when an update requests more authority. And the single most concrete supply-chain change in the release: ClawHub GitHub installs now require a full commit SHA instead of a mutable branch or tag. A new dependency-locking page documents the lockfile review boundary and an advisory gate behind it. This is the shape the plugin-security lessons we drew in February pointed at: provenance questions asked before code lands, not after.

Two honest limits keep this from reading as vendor PR. First, the sentence that did not change: “Plugins run in-process with the Gateway - treat them as trusted code.” appears at both tags. 2.0 did not sandbox plugins away from the Gateway process; it changed what you are asked before a plugin gets in. Second, a wording shift worth noting as a wording shift: the doc used to say installing plugins runs “untrusted” code and now says it runs “executable” code — a documentation change that reads as a move to a tiered-source model, not a proven behaviour change.

The new team-scoped Secret Store — also SQLite-backed, managed through the CLI and Settings — separates two kinds of value. Protected secrets are write-only after saving and can be placed into an approved Gateway-hosted HTTPS request through masked prompts, Vault or 1Password references, and destination-bound substitution, without ever appearing in plaintext configuration or model-visible text. Agent-readable environment values are a separate, weaker grant: the command that receives them can still print or transmit them. A new optional 1Password broker resolves curated references with service-account auth, per-secret approval and value-free audit — its documentation page did not exist one tag earlier.

The vendor’s own caveat belongs in the body of any write-up, so here it is, verbatim:

And the substitution path has edges: destination-bound substitution applies only to Gateway-hosted HTTPS commands whose subprocess honors its proxy settings — the vendor lists raw sockets, containers, remote nodes, provider-native harnesses, plain HTTP and WebSockets as outside that path. The right read: this is a real improvement in where credentials can avoid appearing, with a trust-boundary floor (filesystem permissions) that the vendor names rather than hides. If your team’s hardening posture was built on our February hardening guide, the secret-handling chapter is the one 2.0 most changes.

The vendor frames 2.0 against its own shipping habit, and the frame is checkable — so we checked it against the GitHub Releases API rather than repeating it:

Checking a vendor’s number and finding it right is rarer than it should be. “106 releases in 230 days” is not a round marketing figure — it is the literal count of stable GitHub releases in that exact window, independently reproducible from the API. The pause is 48 days, matching the sentence and not the heading, and we do not inherit a vendor’s own headline error. One nuance the raw list adds: the gap was not a total stop — four non-prerelease tags and six prereleases landed inside it, which we read as patch and backport tags on earlier release lines rather than new feature releases. That is our read of the tag names, not a vendor statement.

The community figures travel differently. The blog states the release “was built by 933 contributors, including 569 first-time contributors, and is composed of over 16,000 pull requests”, and that it contains roughly half of all pull requests ever merged. Those are vendor-stated and we could not independently verify them — GitHub’s public contributors endpoint counts a repository’s lifetime entries, a different population that neither confirms nor contradicts a per-release figure. Carry them with the label, or not at all.

Three migrations want planning: the sessions-to-SQLite move (back up first), the removal of the bundled OpenProse plugin and /prose command, and the migration of codex/* and openai-codex/* model references to openai/*. The release body names openclaw doctor --fix for the OpenProse and OpenAI-route migrations only. Two defaults deserve a deliberate look because they are on by default: model-backed background memory consolidation (“grounded dreaming”, with an explicit disable control) and automatic self-learning, which applies scanner-approved new skills without being asked. And one date to diary: the release body announces upcoming deprecations for September 1, including an SDK removal gate for external plugins — announced gates, not removals in this release. If your team publishes plugins, the vendor-neutral Agent Plugins standard the release notes name is the migration target to watch.

The larger pattern is worth filing: an agent platform’s release notes are now security documents, and reading them — diffing them — is part of operating the tool. If your organisation is adopting agent tooling and needs that discipline built into the process, from install-source policy to credential handling, our AI transformation engagements do exactly this work.