Four OpenClaw Fixes Landed After beta.5: State Recovery, Codex Growth, Windows Processes and Plugin Channels

Four material operational fixes merged to OpenClaw main after 2026.7.2-beta.5 was published: recovery from a poisoned cached state-database handle, enforcement of the transcript byte fuse for Codex sessions, cleanup of Windows child process trees, and preservation of the beta channel during bulk plugin updates.

They do not justify a blind source upgrade. They do change the containing-version decision for operators already seeing one of these failure modes. Beta.5 was published on 28 July at 03:23 UTC; these fixes merged later, between 29 July 04:01 and 04:26 UTC. Beta.5 therefore cannot contain them merely because they now appear on main.

Triage by symptom

A merge timestamp proves source chronology, not package availability. Confirm a release note, package manifest or exact deployed SHA before removing an interim control.

State repair no longer requires process repair

PR #114278 addresses a cached-handle failure. If the shared state database briefly returned SQLITE_CORRUPT or SQLITE_NOTADB, OpenClaw could keep the failed handle cached for the lifetime of the Gateway. Even after the file was repaired or restored on disk, later operations continued failing until restart. The upstream report names Telegram channels, exec approvals and OpenAI-compatible paths among the affected surfaces.

The fix evicts the cached handle only after a write reports proven corruption, allowing the next open to verify the current file generation. This is deliberately narrower than “retry every SQLite error.” Transient contention and arbitrary I/O failures should not trigger uncontrolled handle replacement.

Operator implication: a restart remains a reasonable containment step on an older affected build, but it is not a substitute for determining why corruption was reported. Preserve the database, WAL or rollback journal, logs and recovery artifacts before repair. Do not delete sidecars or fabricate tables to make startup green.

This extends, rather than replaces, the broader SQLite recovery work packaged in beta.5. The earlier release hardened snapshots, quarantine and schema admission; this later fix lets a running process stop clinging to a handle associated with the damaged generation.

Codex native compaction did not cap host history

PR #115514 closes a split-brain retention problem. Codex-runtime sessions skipped OpenClaw preflight compaction because native Codex performs its own automatic compaction. That skip occurred before OpenClaw evaluated agents.defaults.compaction.maxActiveTranscriptBytes.

The native thread could remain within its own context policy while the host SQLite transcript branch grew without the configured byte fuse. That host branch is used to seed a fresh native thread, so growth affected both storage and future session startup.

The fix applies the host transcript byte guard to Codex sessions without pretending that host compaction and native context compaction are the same mechanism.

Operator implication: after adopting a containing build, test the configured threshold with a long Codex session and inspect the host transcript branch across restart or thread recreation. Watching only provider token usage will not prove host-state retention is bounded.

Windows process-tree cleanup now escalates on proven failure

PR #115535 fixes a Windows-specific leak involving MCP servers, agent subprocesses and other Node process trees. OpenClaw already attempted graceful taskkill /T, but a console process could refuse that termination and leave descendants behind.

The merged change preserves graceful-first, awaited termination and escalates immediately only when taskkill reports failure. It also retains a grace-period fallback, one-shot signalling and PID-reuse protection.

Operator implication: acceptance tests should launch a harmless nested process tree, terminate the owning run and verify that no descendants remain. Check process identity, not only a recycled PID. Repeated leaked MCP servers can hold ports, files and credentials even when the original agent appears gone.

Beta plugin updates must stay beta

PR #115083 fixes a compatibility trap for beta operators without an explicit update.channel. On such installations, openclaw plugins update --all could choose stable official plugin packages, recreating plugin/core skew during a bulk update.

The corrected path preserves the beta channel fallback. Until a containing package is identified, pin official plugin versions alongside the OpenClaw core version or avoid bulk updates during the change window. A Control UI beta badge does not prove every installed plugin came from the matching channel.

This is not an argument to float everything on beta. It is an argument that core and official plugin channel selection must be one auditable deployment decision.

Acceptance checklist

For a candidate containing build:

1. Record the exact core and official plugin versions or source SHA.
2. Back up the complete state database family before any recovery exercise.
3. Inject corruption only into a disposable fixture; confirm repair followed by a new open does not require a Gateway restart.
4. Run a long synthetic Codex session and verify both native context behaviour and host transcript-byte enforcement.
5. On Windows, terminate a nested test process tree and prove descendants are gone.
6. From a disposable beta installation, dry-run or inspect bulk plugin selection and confirm it remains on the beta-compatible line.
7. Restart once more and verify channels, approvals, schedules and plugin loading.

Do not test destructive state recovery or process termination against a production Gateway.

Evidence and limits

OpenClaw Academy reviewed the official merged pull-request and commit records supplied by the repository collector, plus the previously verified beta.5 publication chronology. Upstream labels the state fix P0 and the plugin-channel fix P1; those labels describe project prioritization, not a universal emergency severity rating.

We did not corrupt a live database, run the Windows process-tree reproduction, force a Codex transcript past the byte threshold or execute a beta bulk plugin update. Runtime behaviour and upstream test claims remain attributed to the merged records. No supplied release record establishes a packaged version containing all four fixes.

Bottom line

Beta.5 is not the end of the current recovery campaign. If you have a Gateway stuck after state repair, unbounded Codex host transcripts, leaked Windows subprocesses or beta/stable plugin skew, track the specific containing fix and keep a narrow interim control.

Everyone else should resist main-branch whiplash: add these cases to acceptance testing, wait for a confirmed package, and upgrade because your operating evidence says to—not because four useful commits landed before breakfast.