OpenClaw merged a Git updater reliability fix in PR #154042: checkout-based updates no longer fail just because a candidate pack crosses the old 256 MiB cap, and the updater no longer needs to hold a pack-sized JavaScript buffer.
The change is targeted at large update packages. The PR says the previous cap was a retained-buffer bound, not a free-disk-space check. That distinction matters because a valid pack could be too large for the JavaScript transfer path even when Git itself could handle it.
What changed
The updater now reuses the process runner's native stdin-descriptor convention. Instead of reading the staged pack into JavaScript or piping it through IPC, Git reads the already-open staged file directly.
The PR does not claim zero disk copies. The staged pack still exists, and Git's installed pack still exists after import. Git remains responsible for validating and publishing imported objects.
The important shift is at the process boundary:
- The updater pins the safely opened file before admission.
- The descriptor is closed on every exit path before deleting the inspection checkout.
- Complete-object checks, offline partial-clone activation, keep-file ownership, concurrent-repack protection, and rollback behavior are preserved.
- Large packs are no longer rejected by the old fixed retained-buffer cap.
Already-installed updaters keep their previous behavior until replaced, so the PR is careful not to claim it can repair the first blocked update for an older driver.
Why it matters
OpenClaw updates run through a sensitive path: they need to move large candidate code safely, verify Git objects, recover when things fail, and avoid making the updater itself a memory bottleneck.
This fix turns a JavaScript-buffer problem back into a Git file-descriptor problem. That is a better fit for the workload. Git already knows how to stream and validate packs; the updater's job is to stage the candidate safely and hand it off without creating a second large in-memory copy.
For operators, the practical result is fewer surprise failures on large Git checkout updates and less memory pressure during update preparation.
Validation notes
The PR includes a real before-and-after test with a valid 269,504,993-byte pack. The original code rejects that pack at 268,435,456 bytes. The fixed code imports it, checks out a 257 MiB blob, verifies the hash, and releases its owned keep file.
During fixed preparation, the reported retained ArrayBuffer delta was 352 bytes rather than a pack-sized allocation. The author also verified the original local-fetch failure involving lazy fetching being disabled and a bad pack header, then showed the descriptor path preparing before admission and importing successfully after the upstream directory became unavailable.
Test coverage includes descriptor inheritance and parent close behavior, removed staging pathnames, competing input rejection, offline imports, admission refusal, retry, rollback, published-checkout moves, retained pack ownership, descriptor release, update-flow regressions, and CLI post-update recovery.
Exact-head CI passed, including the native watcher and security-review aggregation. The PR also includes a published-driver-to-candidate upgrade proof using openclaw@2026.9.4, with serving probes, legacy agent, cron and plugin survival, repeat-update and Doctor checks, and backup rollback.
For anyone running OpenClaw in larger environments, this is not a flashy UI feature. It is better plumbing in one of the places where better plumbing pays off.