Summary

On OpenClaw 2026.6.5, openclaw plugins install can fail deterministically with npm EOVERRIDE for managed npm-root projects whose manifests were created by earlier OpenClaw versions. Two behaviours compound:

1. 2026.6.5 imports pnpm workspace overrides into managed npm roots. readOpenClawManagedNpmRootOverrides() now calls readHostWorkspaceOverrides(packageRoot), which reads the pnpm-workspace.yaml that ships inside the published npm package and exports its overrides: block (~26 entries, including hono: 4.12.18, @hono/node-server: 1.19.14, @aws-sdk/*) into ~/.openclaw/npm/projects/<name>-<hash>/package.json as npm overrides — including pins for packages that are not part of the host's runtime dependency graph.

2. Managed peer-dependency pins never advance. syncManagedNpmRootPeerDependencies() keeps an existing pin via nextDependencies[packageName] = dependencies[packageName] ?? dependencySpec. A project manifest that earlier OpenClaw versions pinned to hono: "4.12.23" (recorded in openclaw.managedPeerDependencies) keeps that exact spec forever.

The combination writes a manifest npm itself rejects: dependencies.hono = "4.12.23" plus overrides.hono = "4.12.18". npm's assertRootOverrides (@npmcli/arborist/lib/node.js) throws EOVERRIDE because an override may not change the effective spec of a root direct dependency:

npm error code EOVERRIDE
npm error Override for hono@4.12.23 conflicts with direct dependency

The install then rolls back the manifest, so the conflicting state is invisible after the fact — which makes this confusing to debug. (I captured the mid-install manifest by snapshotting package.json on a 50 ms loop while the install ran.)

Environment

• OpenClaw 2026.6.5 (5181e4f), installed via npm into ~/.npm-global
• node v24.16.0, npm 11.13.0, Linux (systemd)
• Plugin being updated: @drakon-systems/shieldcortex-realtime (extension-format pack, openclaw.extensions; it declares no hono dependency and no overrides itself)

Reproduction

1. A managed project at ~/.openclaw/npm/projects/<plugin>-<hash>/ whose package.json contains a stale managed peer pin, e.g. "hono": "4.12.23" in dependencies with "hono" listed in openclaw.managedPeerDependencies (created by a pre-2026.6 OpenClaw; observed on several machines).
2. Upgrade host to 2026.6.5.
3. openclaw plugins install --force <plugin>@latest → EOVERRIDE, rollback, plugin left on the previous version.

Mid-install manifest captured right before npm ran (trimmed):

{
  "dependencies": {
    "@drakon-systems/shieldcortex-realtime": "4.31.2",
    "hono": "4.12.23",
    "...": "..."
  },
  "overrides": {
    "hono": "4.12.18",
    "@hono/node-server": "1.19.14",
    "@anthropic-ai/sdk": "0.100.1",
    "...": "..."
  },
  "openclaw": {
    "managedOverrides": ["hono", "..."],
    "managedPeerDependencies": ["hono", "..."]
  }
}

Impact

• Every subsequent plugin install/update in an affected project fails until the manifest is repaired by hand.
• After the npm failure the installer prints Also not a valid hook pack: Error: package.json missing openclaw.hooks, which is misleading for extension-format packs — the actionable error is the npm one.
• Related: because existing pins are never advanced, plugins can keep running against stale peer-dependency versions indefinitely even when installs succeed (we found a plugin running against a peer lib several versions behind the plugin itself).

Workaround

Edit the project package.json: delete the stale entry (e.g. hono) from both dependencies and openclaw.managedPeerDependencies, then re-run the install. The peer plan re-pins it consistently with the override and the install succeeds.

Suggested fixes

• (a) Before running npm, reconcile managed overrides against root dependencies: if an override key is also a root dependency in the managed root, align the dependency spec to the override (or drop that override key). This makes EOVERRIDE structurally impossible.
• (b) Advance managed peer pins from the fresh peer plan rather than unconditionally preserving the existing spec (dependencies[name] ?? dependencySpec).
• (c) Optionally filter workspace overrides to packages actually reachable in the host runtime graph before exporting them to plugin roots.

Happy to provide more detail or test a fix.