OpenClaw's Plugin EOVERRIDE Bug Is the Kind of Boring Dependency Failure That Takes Agents Offline

There is a category of bug that never makes the release notes but costs operations teams hours: the kind where a dependency management change in version N+1 makes every plugin install or update fail in version N+1, even though nothing else changed. OpenClaw 2026.6.5 shipped one of these. Issue #91772, filed the same evening, describes a scenario where a managed npm root with a stale peer pin could no longer process any subsequent plugin install or update after upgrading to 2026.6.5. The agent still ran. The integration you needed was broken.

The failure path is classic dependency management pain. Version 2026.6.5 started exporting the full pnpm-workspace.yaml override set into managed plugin npm roots — 26 override entries, including hono: 4.12.18. Older managed roots could still have hono pinned at 4.12.23. npm saw both the direct dependency hono=4.12.23 and the override hono=4.12.18, ran its Arborist conflict check, and rejected the manifest with EOVERRIDE: "Override for [email protected] conflicts with direct dependency." PR #91786, opened the same night, changes the managed-root writer so stale managed pins reconcile with the fresh npm plan before npm runs.

Why This Matters Beyond One Package

Plugin ecosystems live or die on upgrade reliability. OpenClaw is increasingly pushing integrations into installable plugins — the right architectural direction — which means npm roots become part of the agent control plane. If a managed root wedges, the agent may still boot while the integration you depend on cannot update, cannot install, or runs against stale peers. That is worse than a clean failure because operators can misdiagnose it as a plugin-specific bug, spend time on the wrong problem, and file a report that has nothing to do with the actual root cause.

The secondary UX failure in the original issue report is also instructive: after npm fails with EOVERRIDE, the installer prints Also not a valid hook pack: package.json missing openclaw.hooks, burying the actionable npm error. That is the kind of operator experience that usually signals a real production papercut. When the real error is 15 lines above the visible message, and the visible message talks about hooks instead of overrides, debugging becomes archaeology.

The Fix and What It Means

PR #91786 introduces reconcileManagedNpmRootOverrideConflicts(), which enforces the EOVERRIDE invariant during managed npm root writes. The key design principle: OpenClaw-owned managed pins should be reconciled by OpenClaw's current plan, while user-owned dependencies should retain their existing spec. The distinction matters. A platform cannot both manage a dependency and preserve stale managed state forever.

On the next plugin install or update, affected roots self-heal. There is no separate doctor migration, no hand-editing of package.json, no scavenger hunt through ~/.openclaw/npm/projects. The next openclaw plugins install or openclaw plugins update run against an affected root triggers the reconciliation and resolves the conflict. That is the right user experience: a broken state that fixes itself when the user tries to do the natural next thing.

What Builders Should Take Away

The lesson generalizes beyond OpenClaw. If your agent platform has plugins, skills, MCP servers, or tool packs, dependency metadata is security and reliability metadata. Pinning is not enough; you need ownership semantics, rollback behavior, stale-state reconciliation, and error messages that preserve the root cause. The model is not going to debug npm Arborist for you while the channel integration is down.

Specifically: audit your platform's dependency ownership model. If you export override sets into managed roots, those roots need a migration path when your override schema changes. If you pin peer dependencies, those pins need a reconcile step before npm runs. If you show operator-facing errors, those errors need to surface the actual failure, not a secondary manifest validation that npm runs because the real conflict was already fatal.

For OpenClaw operators: if you hit EOVERRIDE or package.json missing openclaw.hooks after upgrading to 2026.6.5, the fix is to run your next plugin install or update — it should self-heal. If it does not, that is worth a bug report, because the reconciliation logic in #91786 should catch exactly this shape.

Sources: GitHub issue #91772, GitHub PR #91786, OpenClaw v2026.6.5 release