OpenClaw merged a P0 availability fix this morning: PR #117257, "fix(plugin-state): treat missing plugin-state table as empty on read-only fresh stores". It targets the worst kind of onboarding bug: a brand-new install failing before the Gateway can report ready.
The PR says the failure affected a fresh, empty OPENCLAW_STATE_DIR. Startup could create state/openclaw.sqlite with only bootstrap tables, then legacy-state migration detection would try to read plugin state through a read-only connection. Because the plugin-state table did not exist yet, SQLite returned no such table: plugin_state_entries.
That benign first-run condition was wrapped as a plugin-state store error. The result was not benign: the Gateway could exit with code 7 and refuse to report ready.
What Changed
The fix narrows the read-only fallback to the exact fresh-store shape. OpenClaw already treated a missing database file as "no legacy state." This PR extends that idea to the missing plugin-state table, but only when the surrounding database still matches the startup lease bootstrap checkpoint.
That distinction matters. The patch does not broadly ignore SQLite errors, create tables from read-only paths, change schema versions, or reorder startup. It recognizes one specific empty-store condition and keeps other failures loud.
The accepted refinement described in the PR is especially important. The fallback now checks the database's schema shape before returning empty results. If the store has progressed beyond the fresh checkpoint, a missing plugin-state table still fails closed instead of pretending a damaged schema is clean.
Why It Matters
First-run reliability is not polish. If OpenClaw cannot bring up the Gateway on a clean state directory, every downstream workflow is blocked: channels cannot connect, plugins cannot load, and operators are forced into manual repair before they have even started.
The workaround before this fix was running openclaw doctor --fix. That is reasonable for recovering a damaged install, but it is a bad first-run experience. A clean install should not require a doctor step just to cross the ready line.
This also protects operators from the opposite mistake. The PR is careful not to hide real corruption. Populated stores and initialized schemas still surface genuine plugin-state read failures.
Evidence
The PR includes live before-and-after evidence on real builds. Before the fix, a main-based integration build exited with code 7 on a fresh state directory and emitted several plugin-state detection warnings. After the fix, the same path reached readyz=200 in seven seconds, reported {"ready":true,"failing":[]}, and loaded 13 plugins without detection warnings.
Regression coverage was added around plugin-state lookup, list, key-range, and count operations against a database that contains only unrelated tables. A boundary-level startup-lease bootstrap plus migration-detection test also covers the behavior that originally blocked readiness.
For anyone testing the 2026.7.2 beta line on a clean machine, this is a small-looking patch with outsized impact. OpenClaw should now treat a genuinely empty fresh store like an empty fresh store, not a broken runtime.