OpenClaw merged PR #151805, a P1 Gateway startup fix aimed at large agent fleets and SQLite recovery paths.
The headline is simple: unchanged stores should not be forced through repeated expensive startup work. The details are more careful. The PR makes startup consume prepared schema, plugin, and model facts while keeping changed, replaced, revoked, and newly registered stores under bounded certification and integrity checks.
What Was Going Wrong
Large fleets can amplify small startup costs. According to the PR, Gateway startup could repeat preparation for unchanged state and fail before HTTP bind when SQLite workers competed for lifecycle custody.
There was also a small-install regression hiding in the same area. An empty-store certifier could return without publishing canonical proof. That meant pre-dispatch session authorization kept asking for the same certification instead of reaching the agent handler. A one-agent Gateway could report ready while the first agent RPC timed out.
That combination is rough: fleet operators see slow or failed startup, while tiny installs can hit a confusing first-request timeout.
What Changed
PR #151805 introduces a generation-bound session_key_contract.canonical_ready receipt for successful canonical certification. Empty stores now finish through the certification owner and record the receipt when initialization has no pending rows. Later boots can reuse that proof instead of repeating the same work.
The PR also shares more startup facts at their owner:
- Schema preflight can reuse unchanged admission headers
- Canonical readiness can consume a persisted receipt
- Equivalent model sources are parsed once across workspaces
- Plugin metadata merges workspace inputs before building the immutable graph
- Private-snapshot discovery policy is read once instead of repeatedly
The key phrase is unchanged state. The PR keeps fresh inspection for changed WALs, replacements, newly registered stores, explicit revocation, and stores that need write authority.
Performance Evidence
The evidence includes both regression tests and fleet-scale measurements. Historical fleet measurements show a control that failed before binding, while the candidate bound and responded. A later runtime comparison reported median Gateway start-to-first-response improving from 11.48 seconds on pinned main to 8.05 seconds on the accepted runtime candidate.
The PR also reports that the corrected tree passed 25 changed suites with 252 tests, pnpm check:changed, exact-head CI with 158 jobs, and structured review at P1 scope.
Those numbers should be read carefully. The largest fleet measurements are historical and pinned to earlier candidate and control refs, while the final rebased head carries the reviewed implementation. Still, the direction is clear: less duplicated startup work, fewer custody races, and a cleaner first request path.
Operator Takeaway
For most users, this should show up as a Gateway that starts more reliably and avoids doing expensive validation when nothing changed. For teams running many agents, the bigger win is operational: unchanged stores remain read-only during startup maintenance, while real changes still get checked.
That is exactly the balance OpenClaw needs as deployments get larger. Startup should be fast because the platform remembers what it already proved, not because it skips the checks that keep state trustworthy.