OpenClaw merged PR #165417 just before the 08:00 UTC morning cutoff, fixing a subtle but important Doctor maintenance regression. The bug could make Doctor report an offline-maintenance refusal while revalidating the same requester that had already started the update.
That sounds like an internal edge case, but it sits on a sensitive path: update repair. Doctor has to hold the right lock, keep checking requester authority, and still refuse unrelated owners. If the system mistakes its own maintenance marker for a foreign holder, a legitimate repair can stall at the exact moment users expect recovery tooling to be most dependable.
What Changed
The fix keeps the caller's own maintenance window out of the shared lock wait. According to the PR, an authorized update can now enter its own Doctor maintenance window immediately and continue checking requester authority throughout repair.
The important boundary remains intact: revocation still stops repair. Foreign container owners still use the existing bounded wait, stale-heartbeat recovery, and live-holder refusal behavior. The PR also says there are no configuration, schema, dependency, or CLI changes.
In practical terms, the owner of a repair operation should no longer trip over its own lock while still protecting against other processes that might be operating on the same Gateway state.
Why It Matters
OpenClaw's update and repair path has become more stateful over time as runtime data moved into SQLite and Doctor took on more recovery responsibility. That makes ownership checks more precise, but it also means policy reads have to happen in the same custody context as the physical lock.
The regression came from requester checks that ran after the physical maintenance lock was acquired, but outside the retained schema scope needed for the SQLite-backed policy check. The PR moves those reads through the lock owner's existing custody and verifies physical ownership and policy together before publishing the projection.
That is a boring-sounding correction in the best possible way. Update repair code should be explicit about who owns a lock, who is allowed to continue, and when revocation should stop the operation.
Validation
The PR reports reproduction of the original requester-authority failures before the fix. Afterward, the requester-authority and Gateway namespace suites passed three times, including Doctor foreign-holder coverage.
The author also reports direct importer coverage across 77 files, eager-import closure checks, Doctor contract closure checks, a full node scripts/check-changed.mjs pass, and git diff --check.
There is one caveat worth noting: the PR says an independent P1 review attempt did not complete because the isolated Codex client stayed in local session-index initialization for more than 12 minutes. Maintainer review was still required when the body was written.
Bottom Line
PR #165417 is a reliability fix for OpenClaw's repair path. Authorized Doctor maintenance should now recognize its own lock, keep authority checks fresh, and preserve the refusal behavior that protects unrelated owners.