OpenClaw merged PR #151110, a P1 update repair aimed at a Windows npm failure mode: an update could roll back when Doctor failed to remove a disposable lint snapshot, even though that cleanup failure did not put operator data at risk.
The change is small in product shape but important for update resilience. During an update, the cleanup failure is now recorded as a warning instead of replacing the detector's actual findings or blocking the update path.
The Windows Update Problem
The PR describes the issue as a cleanup classification bug. Doctor creates temporary lint snapshot state as part of its checks. On Windows, removal can fail when private handles are still involved. In the bad path, that cleanup failure could become severe enough to interrupt an npm update.
That is too strong a response for disposable state. The failure may still be useful to report, but it should not erase the more important diagnostic result or cause a rollback by itself.
OpenClaw now carries the failed-removal classification through the existing update warning channel. Standalone doctor --lint keeps its error severity, but update-time Doctor cleanup is treated differently because the update driver is trying to preserve a working installation while validating the candidate.
What Changed
The PR says Doctor now classifies the failed removal after awaited private-handle retirement and reports it through update warnings. The shipped 2026.9.3 parent marker selects that behavior, including when the older canary clears OPENCLAW_UPDATE_IN_PROGRESS.
The implementation is deliberately scoped:
- No new options
- No schema changes
- No new dependencies
- No retry mechanism
- No change to standalone lint severity
The production diff is reported as 21 net lines, with broader test coverage around the update and Doctor paths.
Evidence From The PR
The validation includes 1,461 local tests across Doctor lint, runtime tool schema checks, candidate canary behavior, and update-command suites. The PR also reports node scripts/check-changed.mjs passing in full and a clean branch autoreview.
The Windows-specific evidence is particularly relevant. The authors reproduced the published 2026.9.3 cleanup error on Windows Server build 20348 with Node 24.19.0, then validated candidate behavior against a 2026.9.4 installation. Candidate migration rehearsal, Doctor lint, config validation, plugin resolution, migration continuation, and the Gateway canary all passed natively.
The PR is explicit about one remaining limit: the full native update failed before activation because the published 2026.9.4 driver hit a package rollback verification timeout. That failure occurred before the candidate could replace the old driver's swap code, so the PR presents the Windows run as candidate-validation proof rather than a completed native upgrade claim.
For operators, the practical takeaway is clear: a disposable Doctor cleanup problem should be visible, but it should not be enough to derail an otherwise valid OpenClaw update.