Summary

2026.7.1's post-core plugin payload smoke check fails on an unreadable package.json and reports it through the startup-migration gate, refusing gateway readiness. A filesystem-permission problem on one optional plugin is (a) misclassified as a state-migration failure and (b) fatal to the whole gateway.

Reproduction

One plugin dir under the state dir (extensions/whatsapp/ in our case) was root-owned with package.json mode 600, from an old provisioning step; the gateway runs as an unprivileged user. 2026.6.11 booted fine for weeks with that state, it never ran this check. On 2026.7.1:

[openclaw] Could not start the CLI.
[openclaw] Reason: OpenClaw startup migrations did not complete cleanly; refusing to report the gateway ready.
- Plugin "whatsapp" failed post-core payload smoke check (invalid-package-json): Could not parse package.json: EACCES: permission denied, open '/data/extensions/whatsapp/package.json' Run `openclaw update repair` to retry plugin repair. Run `openclaw plugins inspect whatsapp --runtime --json` for details.

(and then the process segfaults rather than exiting non-zero, filed as #109831.)

Why the classification matters

The per-plugin detail line is accurate and actionable. But the headline is "startup migrations did not complete cleanly", and in a real incident that framing sent us auditing migration state (leftover sidecars, shared-state namespaces) before anyone looked at file ownership. openclaw update repair, which the message suggests, also cannot fix a permission problem.

Expected (either would do)

• Classify it as a plugin-load/verification error, not a migration failure, with the EACCES line as the headline; or better,
• disable the failing plugin with a loud warning and boot the gateway. One unreadable plugin dir taking down the whole gateway is a rough trade, especially since latent permission problems are invisible on versions that don't run the check and only surface mid-upgrade.

Related

Found during the same upgrade as #109832 (sidecar gate) and #109831 (SIGSEGV failure path); the fix on our side was chown -R node:node extensions/.