OpenClaw 2026.6.34 Is the Extended-Stable Upgrade to Take

OpenClaw 2026.6.34 is now the release to use on the extended-stable channel. It is a maintenance build rather than a feature release, but that understates its value: the release concentrates security-boundary, delivery-recovery and runtime-state repairs that matter most on unattended Gateways.

The official release says the moving npm and container extended-stable selectors resolve to 2026.6.34. It also publishes exact npm provenance, release workflows and multi-architecture container digests. 2026.6.33 remains a valid historical tag, but it was superseded by .34; there is no reason to target .33 for a new extended-stable deployment.

The operator decision

Our recommendation: upgrade extended-stable installations to 2026.6.34 after a normal backup and canary. Pin the exact version or digest where reproducibility matters rather than relying indefinitely on the moving channel alias.

This is not advice to move beta, dev or current stable installations onto an older-numbered line. Extended-stable is a separate risk choice: fewer new capabilities in exchange for a deliberately maintained security and reliability baseline.

The .34 release adds 25 audited pull requests on top of .33. The areas worth an operator’s attention are:

• browser, sandbox and network routes reject more unsafe access paths;
• agent and provider failures are less likely to end active work silently;
• channel recovery preserves pending work and bounded behaviour under retry or overload;
• status and diagnostic surfaces redact credential-bearing account details;
• SQLite, workspace, process and plugin-response paths tolerate transient host conditions more safely;
• production dependency resolutions include patched versions of brace-expansion, PostCSS, fast-uri, ip-address and Undici.

That combination makes .34 more than changelog housekeeping. It reduces both direct exposure and the operationally nastier class of failure where a run appears to finish but accepted work or context has quietly vanished.

Do not treat recovery fixes as delivery proof

The release strengthens receipt handling, retry ownership and queue recovery, but no generic upgrade can prove that your particular channel, provider and supervisor combination behaves correctly.

After upgrading, run one harmless canary through every critical route. For each canary, record a unique identifier and verify three facts: the recipient saw it once, OpenClaw recorded a terminal outcome, and a Gateway restart did not resend it. Do the same for a deliberately failed provider request so alerts and retry state are observable.

For browser-enabled deployments, test from the actual network topology. A loopback-only test does not exercise a reverse proxy, custom origin or remote browser route. Keep the canary non-sensitive and confirm rejected routes fail closed.

The compatibility warning is real

The release repeats overdue Plugin SDK removals: before_agent_start, root openclaw/plugin-sdk imports, providerAuthEnvVars and channelEnvVars are scheduled for removal. Plugin maintainers should migrate to modern hook stages, focused SDK subpath imports and manifest setup descriptors now.

That warning matters even though .34 is maintenance-only. Extended-stable can preserve a runtime line; it cannot preserve deprecated third-party plugin contracts forever. Inventory locally installed plugins before the upgrade, then verify startup diagnostics and one real invocation from each plugin after restart.

A safe rollout sequence

1. Back up the state directory and record the currently running exact version or container digest.
2. Inspect custom plugins for the deprecated SDK surfaces named above.
3. Upgrade a canary Gateway to exact 2026.6.34 artifacts.
4. Verify Gateway readiness, SQLite-backed session continuity and provider authentication.
5. Exercise one inbound and outbound path per critical channel, including a restart between attempts.
6. If you use browser or sandbox features, test the real proxy and origin topology.
7. Promote the same exact artifact to the remaining Gateways; move to the channel alias only if automatic movement is intentional.

Bottom line

2026.6.34 is the sensible extended-stable target. Its value is not novelty; it is a tighter set of trust boundaries and better custody of work under failure. Upgrade, but keep the rollout evidence-based: exact artifact, recoverable state, one-delivery canaries and explicit plugin compatibility checks.