What's the latest OpenClaw version? npm, GitHub, and Docker, untangled

Three places “the latest version” lives

OpenClaw releases surface in three systems, and they are not always in step:

• npm dist-tags are the source of truth for package installs. latest is current stable, beta is the next line, and extended-stable trails behind for people who want releases that have soaked for a while. One command shows all of them:

  npm view openclaw dist-tags

• The release notes on docs.openclaw.ai and the GitHub release carry what changed: breaking changes, migrations, security fixes. The version number alone tells you nothing about whether an update matters to you. The “Latest” badge on GitHub’s releases page is set by hand, too: on the day we checked, it still sat on 2026.8.2 while npm and ghcr had moved to 2026.9.1.
• Container images publish to ghcr.io/openclaw/openclaw (a Docker Hub mirror exists; prefer ghcr). Since 2.0 the tag policy is explicit: plain version tags such as 2026.9.1 and dated rebuild tags such as 2026.8.1-r20260820 are immutable, while latest, main, extended-stable and their -slim and -browser variants are moving tags, rebuilt weekly to pick up operating-system security updates between releases. Pin a version tag or a dated tag when you want a deployment to change only when you say so.

The gap between npm and Docker

All three 2.x releases so far had their images on ghcr the day they reached npm. That was not the pattern for patch releases in July: 2026.7.1 went stable on the 13th, the 2026.7.1-1 and 2026.7.1-2 patches landed on npm five days later, and the 2026.7.1-2 image did not appear for another two and a half weeks. We watched a Docker install sit on 2026.7.1 for that whole stretch while the update banner insisted a newer version existed, because the banner keys off npm. So a container install can be fully current for its channel and still be nagged. The practical rule: compare your version against the channel you actually install from, not against npm’s latest in the abstract. Since 2.0, images, the CLI, the Gateway and the Control UI report the full version consistently, so a running patch release no longer offers itself as an update.

Is the latest version the one to install?

For a fresh install, yes. There is nothing to migrate, and the problems 2.0 had in its first days clustered around upgrading existing installs, not around fresh installs from the image. For an agent already on 2026.7.x, the move to any 2.x release runs one openclaw doctor --fix migration, and that is where the care goes. The release-day bug that made headless doctor runs silently skip the migration was closed the same day it was filed, with its fix merged ahead of 2026.8.2. The tracker still carries open reports against the update path on 2026.9.1, filed on September 3 and 4, so read the open issues for your setup before the day you pick. What changed in 2.0 and how to judge the upgrade has the detail.

What version am I running?

openclaw --version answers for package installs. For Docker setups the truth is the image tag in your compose file, and the reason to pin an exact image rather than track a moving tag: an agent’s version should change when its operator decides, not when a tag moves overnight. Whichever install you have, the version-checking habit pairs with the updating discipline; how to update without breaking your agent covers that half.