OpenClaw extended-stable: how to update a production agent
OpenClaw extended-stable is the release channel for a package-installed Gateway that needs selected security and reliability backports without following every regular release. It is a sensible default for an agent that sends customer messages, runs scheduled work, or has credentials you cannot casually test against a moving development line. The tradeoff is deliberate: you get a supported monthly package line, not every new feature the moment it lands.
The current extended-stable selector resolves to OpenClaw 2026.6.34. That maintenance release includes browser and network boundary fixes, recovery work for agent and provider runs, channel-delivery repairs, safer diagnostics, and runtime-state hardening. It is a useful example of why the channel exists: the release is about reducing operational risk rather than changing how your agent looks on a good day.
Contents
- What the extended-stable channel means
- When OpenClaw extended-stable is the right channel
- A safe update sequence
- What changes after an extended-stable update
- How it differs from a one-off version install
- FAQ
What the extended-stable channel means
OpenClaw has four documented channels: stable, extended-stable, beta, and dev. Stable follows the normal npm latest line. Beta is for candidate builds. Dev follows the moving main line and is explicitly for experimentation and active development. Extended-stable is different: it is a package-only channel that resolves the public npm extended-stable selector, verifies the exact selected package, and fails closed if the registry data is missing or inconsistent.
The release policy is intentionally narrower than an LTS promise. OpenClaw says extended-stable releases are cut monthly, receive backported security and reliability fixes, and remain supported until the next monthly release, for at least one month. Treat it as a controlled maintenance track, not as an excuse to stop checking release notes or health status.
| Channel | Best fit | What it follows |
|---|---|---|
stable | Most personal and general-purpose Gateways | npm latest |
extended-stable | Production workflows that value a slower, reviewed change cadence | verified monthly package target |
beta | Testing a candidate before general release | npm beta, with documented fallback behavior |
dev | Contributors and experimental environments | moving GitHub main |
This channel choice fits the model behind how OpenClaw works. The Gateway is the runtime that joins channels, tools, credentials, workspace state, and agent execution. Updating it changes a control surface, not merely the app’s user-facing surface.
When OpenClaw extended-stable is the right channel
Choose extended-stable when the cost of a surprise regression is higher than the value of receiving a new feature immediately. Common examples include a Gateway that handles client-facing support, runs recurring automations, or brokers access to company systems through reviewed tools.
That does not make extended-stable automatically safer in every environment. It is only available to package installs. If you run OpenClaw from a Git checkout, the documented channel flow rejects extended-stable without changing the checkout. That is a good boundary: a source-based environment should not silently mutate into a package-managed production install.
Use the channel decision to separate environments by purpose:
- Keep a development Gateway on
devorbetawhen you need to test a new integration early. - Use stable when you want the regular release line and can absorb its normal cadence.
- Use extended-stable when the workflow benefits more from backported repairs than from the newest product surface.
The release notes for 2026.6.34 show the kind of maintenance that belongs here. They cover unsafe browser and network access paths, agent and provider recovery, queued channel work, credential exposure in diagnostics, SQLite checkpoints, and dependency security updates. These are unglamorous changes. They are also exactly the changes that can matter after a Gateway has been running for weeks.
For the broader decision framework, see AI agent update safety and the OpenClaw security guide. Those posts focus on evidence and boundaries. This one focuses on choosing a release line that matches the job.
A safe update sequence
Do not switch a production Gateway based on a label alone. First inspect what is installed and preview the effective target.
- Record the current state. Run
openclaw update status --jsonand save the version, install kind, active channel, and update availability with the change record. - Confirm that this is a package install. Extended-stable is package-only. A Git checkout must stay on its own source-update path unless you intentionally migrate it.
- Preview the target. Run
openclaw update --channel extended-stable --dry-run. The dry run reports the effective channel, target version, planned actions, and whether downgrade confirmation would be required. - Read the release notes for the selected version. At the time of writing, the exact target is 2026.6.34. Read the release notes rather than assuming a maintenance release is irrelevant to your Gateway.
- Switch the persisted channel. Run
openclaw update --channel extended-stableduring a maintenance window. A successful update persistsupdate.channelso later normal updates continue to use that release line. - Verify the live Gateway. Check
openclaw --version, then useopenclaw gateway status --deep --jsonandopenclaw doctor --lint --json. Test one narrow, low-risk channel or tool path that represents the work your Gateway actually performs.
The updater detects the installation type, fetches the target, runs doctor checks, and restarts the Gateway by default. That coordination is why the official documentation recommends openclaw update over a raw package-manager command on a supervised install.
What changes after an extended-stable update
An extended-stable update aligns the core version with a release-channel policy. The updater verifies the exact package selected by the channel, and eligible official npm plugins with bare, default, or latest intent converge to the same exact core version. Explicit version pins, third-party plugins, non-npm sources, and explicit non-latest tags stay unchanged.
That distinction deserves attention. A healthy core update does not prove every plugin received a new build, and a plugin that remains pinned is not necessarily broken. It may be preserving an operator decision. Review openclaw plugins list --json after the update if a channel or provider is part of a critical workflow.
OpenClaw 2026.6.34 also ships exact package and container references for the extended-stable line. If you deploy containers, pin the exact version and image variant you validated rather than relying only on a moving label. The release notes list 2026.6.34, 2026.6.34-slim, and 2026.6.34-browser images for amd64 and arm64.
This is a maintenance practice, not a security guarantee. Keep your normal credential, tool-policy, and recovery controls. If you are new to the platform, start with what OpenClaw is before treating any release channel as a replacement for operating discipline.
How it differs from a one-off version install
A direct npm install -g openclaw@extended-stable selects the current package, but it does not persist the chosen update channel. The next ordinary update may follow whatever channel your configuration already selected.
Use openclaw update --channel extended-stable when you want a persistent production policy. Use a one-off tag or exact version when you are testing a specific artifact and do not want to change future update behavior. The docs make another important distinction: --tag is a one-off package target, while extended-stable is a verified channel flow and cannot be combined with an effective --tag extended-stable setting.
The practical question is simple: are you selecting an artifact for this one maintenance event, or are you selecting the policy for the next one too? Write that answer down with the Gateway’s version and health-check results. It prevents an emergency change from quietly becoming the permanent release strategy.
FAQ
What is OpenClaw extended-stable?
OpenClaw extended-stable is a package-only monthly release channel with backported security and reliability fixes. It resolves and verifies the exact npm package selected by the public extended-stable target and does not fall back to stable, beta, or dev when the target cannot be verified.
Can I use extended-stable on a Git checkout?
No. The documented channel flow rejects extended-stable on Git checkouts without mutating or converting them. Use the source-update workflow for a checkout, or deliberately migrate to a package installation if that is the intended operating model.
Does extended-stable install automatically?
No. OpenClaw can show read-only update hints when update checks are enabled, but extended-stable remains a foreground package update. Review the dry run and release notes before applying it.
What does OpenClaw 2026.6.34 change?
OpenClaw 2026.6.34 is an extended-stable maintenance release with security and reliability repairs across browser and network boundaries, agent and provider recovery, channel delivery, diagnostics, runtime state, and patched production dependencies.