OpenClaw 2026.9.4 can undo a failed update, and its ready cloud workers bill until deleted

Two entries in this release change what happens when nobody is watching. The first is recovery: an update that fails can now put the previous version back. The second is billing: the new prepared cloud workers are real machines at a provider, and they are charged for from the moment they are reserved until somebody deletes them.

A failed update can restore the previous version

When an update fails and the checks find the situation safe, OpenClaw restores the retained package, the command shim, the service, and the configuration as it stood before activation, then verifies the previous Gateway again. The word retained matters: the old package is kept on purpose so there is something to restore.

The limits are stated as plainly as the feature. A changed database schema, an incompatible new database, or a configuration edit an operator made in between all block the automatic rollback. Database migrations still require a verified backup taken before the upgrade. And a recovered update is still recorded as a failed update, with the rollback outcome written next to it, so the failure does not disappear from the record.

Prepared cloud workers are a running cost, not a cache

Eligible sessions from local Git projects and public GitHub repositories can reuse workers that were prepared in advance, which removes the setup wait before a conversation starts. Sessions tied to private repositories and paired devices stay outside this flow.

The reserve is on by default: one ready worker per project or profile, capped at four across the Gateway. Those machines run at the provider and are billed as running machines until they are deleted, which is the part worth reading before the next invoice. Both reserves can be set to zero, one per profile and one for the pool as a whole.

• The default reserve is one ready worker per project or profile.
• The Gateway-wide ceiling for the prepared pool is four workers.
• Snapshot storage and ready-worker charges apply until the resources are deleted.

Plugins get one place, and hosts get a read-only configuration

Bundled and ClawHub plugins are now discovered, installed, and configured from one Plugins workspace in the Control UI, with short plugin page addresses and a single search across installed and ClawHub skills. This is housekeeping rather than capability, but it is the kind that decides whether a plugin gets installed at all.

For deployments where the configuration belongs to the host rather than the user, setting the environment variable OPENCLAW_CONFIG_READONLY to 1 stops OpenClaw from rewriting it. The block covers ordinary writes, setup, Doctor repairs, plugin changes, and updates, while read-only configuration commands keep working. It does not freeze runtime state, only configuration.

Plugin authors get two dates. The old string argument to buildCredentialSafetyPrompt entered deprecation and stays supported through November 30, 2026, after which authors should pass an object carrying controlToolsAvailable. The deprecated untrusted-named context aliases reached their removal date of September 8, 2026, and were kept anyway, because removal now waits on evidence that published plugins have migrated.

The fixes that are access boundaries, not bugs

One group of fixes in this release is about what one part of the system may read from another. These are the entries to weigh when deciding how soon to upgrade, because each one describes a boundary that was not holding.

• Attachment reads from a sibling agent's isolated environment are now prevented.
• Cloud metadata addresses stay blocked even when private IPv6 exceptions are enabled.
• Slack HTTP request bodies are now bounded instead of unbounded.
• Stale signed Feishu webhook callbacks are rejected, and pipelined MCP calls stop after a rejected upload.