OpenClaw merged a substantial updater performance fix this morning aimed at a very specific but painful case: update prevalidation when configured plugin paths point at installed bundled plugins or very large dependency trees.
PR #166317, "fix(update): reduce slow prevalidation for large plugin trees," keeps the existing safety checks intact while cutting down repeated filesystem work. The headline number from the PR is striking: in one production-shaped rehearsal, complete prevalidation including cleanup dropped from 12 minutes 49 seconds to 5 minutes 42 seconds.
That is not framed as a universal upgrade-speed guarantee. It is a single-host measurement for a workload with large plugin trees. But it does show where the update path was spending avoidable time.
What Changed
The updater now captures the serving installation's actual bundled-plugin selection before entering the staged worker. That lets the candidate update process match bundled plugin entries against the real installed source, instead of rediscovering the candidate as the source and copying the old installation unnecessarily.
The PR also adds throttled progress receipts for completed filesystem work. Those receipts feed the existing I/O watchdog without turning every file into a ledger event.
For large guarded copies, OpenClaw now uses the existing four-worker pool while preserving the same custody rules:
- Original destination identity stays attached to copied files.
- Source fingerprints and byte hashes remain part of validation.
- Publication stays create-only.
- Native operation fencing, worker stop, drain, and join ordering remain in place.
In plain terms: this is a performance fix, not a shortcut around update safety.
Why It Matters
OpenClaw updates already do more than copy a package into place. They validate candidate state, snapshot databases, inspect plugins, run startup checks, preserve rollback information, and guard filesystem operations. That safety work is valuable, but it can become expensive when a plugin tree is large or when bundled-plugin paths make the updater repeat work it can prove is already known.
The PR reports plugin allocation falling from 4.73 GB to 1.56 GB in the same private rehearsal. State preparation also dropped from 638.258 seconds to 238.465 seconds.
For operators, the practical benefit is shorter update preparation windows on installations with heavier plugin layouts. The PR says the full improvement requires both the updated installed driver and candidate worker. Older driver and worker combinations remain compatible, but may keep some previous copying and progress-probe overhead.
Evidence From the Merge
The final verification included a native macOS update rehearsal from the published 2026.9.8 updater to the candidate package. The PR says the update completed with exit 0 and status ok, preserving an ordinary custom plugin with 1,024 payload files totaling 256 MiB, a read-only file, and a relative symlink from the private canary root.
The candidate also passed 182 focused tests, a scoped changed-file gate, a full package build, and canonical tarball integrity checks. The authors disclose the limits: the native proof exercised owned foreground Gateways and package update behavior, not LaunchAgent activation.
Bottom Line
This is the kind of infrastructure change most users only notice when it is missing. OpenClaw update prevalidation still performs the same classes of validation, but it now avoids a large chunk of redundant plugin-tree work in the path where updates could feel stuck.