OpenClaw 2.0 (2026.8.1): Read This Before You Upgrade

Bottom Line

OpenClaw normally ships every day or two. This release took nearly seven weeks, and the project’s own post admits it was not supposed to be a major version — they went in to improve a few things and ended up rebuilding half the stack.

That is worth taking seriously as a signal. When a project that ships daily disappears for seven weeks and comes back having rewritten installation, messaging, memory, skills, models, automations, browser apps, plugins and security, the first week after release is not the week to upgrade a machine you depend on.

The community reaction on release day reflected that. Reports ranged from “seamless” to an hour lost getting back to a working state. Both are true, and which one you get depends mostly on how customised your install is.

The change that matters: sessions moved to SQLite

Everything else in this release is additive. This one is not.

Sessions and transcripts previously lived as files. In 2026.8.1 they live in SQLite. The release notes state plainly that sessions created after the migration will not appear in older releases.

That makes the upgrade effectively one-way for your history. You can roll back the binary, but the conversations you had after upgrading do not come with you unless you restore archived legacy transcript artifacts using the current CLI first — which means doing it before you downgrade, while the new version is still installed.

Do this before you upgrade:

1. Take a verified backup. Not “I think the folder is somewhere” — a backup you have actually checked can be restored.
2. Read the project’s downgrade guide now, while you have a working install, rather than at 11pm when you need it.
3. If OpenClaw is doing real work for you this week, wait. A failed upgrade should cost you an hour, not a deadline.

This is the same advice we gave for the 3.x series and it has not changed: the backup is the upgrade plan.

”I updated and still have 2026.7.x”

This was the single most common complaint on release day, and it is usually not a failed download.

The 2.0 installer changed how the binary lands on both major platforms:

• macOS: the app can now self-move to Applications. If you previously ran it from elsewhere, you can end up with two copies.
• Linux: the installer now puts openclaw on your PATH without manual shell configuration. If you had already added it manually, one install can shadow the other.

So before assuming the update failed, find out which binary your shell is actually running:

which -a openclaw
openclaw --version

If which -a returns more than one path, that is your answer. Remove or rename the stale one and re-check the version.

Pairing changed on purpose

Several people reported that upgrading undid their Discord pairing code. Pairing was reworked rather than broken:

• Official pairing now distinguishes Full from Limited mobile access.
• Unencrypted LAN connections are automatically marked Limited.
• Certificate pinning is maintained for IP and LAN connections.
• The installer now blocks network deployments that would expose OpenClaw without authentication.

Re-pairing after this upgrade is expected. If a device came back with less access than it had before, the most likely reason is that it connects over an unencrypted LAN link and has been downgraded to Limited by design — not a bug.

That last installer change is worth dwelling on. If your setup previously worked by exposing OpenClaw on your network without authentication, 2.0 will stop you, and it stops you before making changes. That is a good default and it will break some people’s setups.

What actually changed, by subsystem

Filtering the release notes down to things you will notice:

Models

• Fresh OpenAI setups now default to GPT-5.6.
• Gemma 4 is the new llama.cpp default on RAM-gated systems.
• One-click local model setup on web and macOS.
• In-process local GGUF text inference.

Onboarding

• Guided setup verifies AI access before saving config, so you fail fast rather than at first use.
• Mobile setup leads with QR and setup-code pairing instead of manual entry.
• The first conversation hands off directly after setup rather than making you finish a wizard.

Control UI

• Rebuilt around the conversation, with files, approvals and settings kept close to it.
• The Overview page is retired — it is chat-first now.
• Sessions open in real browser tabs with readable slugs; the sidebar remembers its width.
• “Session” and “thread” terminology unified.

Sessions and agents

• Named agents keep credentials through creation and config resets.
• Multi-agent CLI operations stay with their owning agent.
• Codex-backed sessions can branch from a selected message without modifying the original.

Skills and search

• Skills and web-search config moved into the conversational setup flow.
• Optional Firecrawl search, with a keyless setup option.

Gateway and auth

• Remote Gateway credentials are authenticated before setup proceeds.
• Gateway health failures stay inside setup with the original diagnostics, instead of dumping you out with a vague error.
• Safe token recovery during onboarding.

Plugins

• Plugin ownership is preserved during Codex onboarding.
• Non-interactive onboarding rejects invalid options before creating agents or writing config.
• Concurrent setup on the same profile fails fast and tells you who holds it.

Should you upgrade?

Upgrade now if you are setting up a fresh machine. The onboarding work is the strongest part of this release, and you have no history to migrate — the SQLite change costs you nothing.

Wait if OpenClaw is doing work you depend on this week. Nothing here is urgent enough to risk a working setup mid-project. Upgrade on a Friday, not a Monday.

Back up first, in every case. The storage migration is the one irreversible thing in this release.

Take particular care if you run OpenClaw over a LAN without authentication, or you have a heavily customised install with plugins. Those are the two configurations most likely to need work after upgrading.

What we do not know yet

This release is one day old. We have read the release notes and watched the first wave of reports; we have not yet run 2026.8.1 in anger across the hardware tiers we normally test.

Open questions we will answer once we have:

• Whether the SQLite session store changes memory or disk behaviour on RAM-constrained machines.
• Whether Gemma 4 as the llama.cpp default is the right call at each RAM tier, or whether you should override it.
• How the in-process GGUF inference compares to running llama.cpp separately.

We will update this post rather than write a new one. If you hit something not covered here, the setup error index is where fixes land first.