OpenClaw merged PR #168419, a migration safety fix that refuses provider loading and imports while another Gateway already owns the selected local state.
The problem is easy to miss until it bites: migration commands can write local state outside the running Gateway. If that happens while the Gateway is live, the process that users are actually talking to can keep stale in-memory assumptions after an import changes files underneath it.
What Changed
The fix wraps migration provider loading and apply work with OpenClaw's existing local-state owner. If a Gateway is already running against the selected state root, the migration command now fails early with a clear refusal instead of planning or mutating state.
When the Gateway is stopped, the command takes exclusive offline ownership through the import, rollback, and provider cleanup path. Memory imports that run inside the owning Gateway keep their existing route.
The PR deliberately avoids adding a new migration RPC layer, config-loading interception, schema change, or broad compatibility surface. It uses the ownership machinery that already exists and applies it at the migration boundary.
Why It Matters
Migrations are one of the most sensitive pieces of an agent runtime. They often touch account data, imported transcripts, memory stores, provider configuration, or local files that other processes assume are stable.
The failure mode here is not only "two writers at once." It is "one writer succeeds while the visible Gateway keeps operating with old facts." That can lead to confusing follow-up failures, partial recovery, or cleanup that looks complete to one process and incomplete to another.
The new guard makes the operational rule explicit:
- If a live Gateway owns the state, migration commands stay out.
- If the Gateway is stopped, the command owns the offline import until cleanup is done.
- If nested roots or uncertain child cleanup appear, the command preserves the existing physical lease behavior rather than silently admitting later writes.
That is a conservative design, and for state migration, conservative is the right shape.
Proof From The PR
The PR body records focused provider and command tests, changed-file checks, Madge, Knip, a worker ratchet, SDK comparison, and multiple review rounds. It also includes fresh regression evidence for two important cases.
One regression proved that a provider could change the selected root during planning and still be admitted before the repair. Another proved that uncertain child cleanup could leave later mutation admitted when it should have been refused. Both assertions are retained after the fix.
The final landing used a coordinator-authorized inherited-CI exception for an unrelated cron assertion that was already failing on main. The PR documents that exception rather than presenting the whole CI run as green.
Bottom Line
PR #168419 tightens OpenClaw's migration boundary around the real owner of local state. Migration imports now wait their turn instead of racing the live Gateway, which should make import, rollback, and cleanup behavior easier to reason about when operators move data between providers.