openclaw - 💡(How to fix) Fix Bundled runtime deps can churn when multiple dependency plans share one install root [2 comments, 3 participants]

Summary

OpenClaw's bundled runtime dependency installer appears able to get into a repeated npm install add/remove loop when multiple bundled plugins/channels share the same runtime dependency install root but write different dependency manifests over time.

This is not a simple missing-package failure. In the observed case, the npm installs usually exited 0, but startup/control-ui/channel loading repeatedly triggered npm, and npm repeatedly added/removed groups of packages.

Observed behavior

After updating OpenClaw, normal startup/control-ui/channel loading repeatedly showed runtime dependency installs under a path like:

~/.openclaw/plugin-runtime-deps/openclaw-<version>-<hash>/

Symptoms included:

npm install ... exit 0

but repeated add/remove churn across subsequent starts or channel/plugin loads.

Related channel load failures also appeared when dependencies had just been pruned or were mid-install, for example missing bundled channel packages such as Slack/Discord/Nostr/Telegram/Feishu deps. A separate but related failure mode looked like npm rename conflicts:

npm error code ENOTEMPTY
npm error syscall rename
npm error path .../node_modules/openai
npm error dest .../node_modules/.openai-<tmp>

Working hypothesis

The runtime dependency installer may be reusing one install execution root for more than one runtime dependency plan. If one subsystem writes a narrower generated package.json, npm treats packages required by a previous/wider plan as extraneous and prunes them. Later, another subsystem needs those packages again and installs them back.

So each individual npm install can succeed, but the shared install root never converges cleanly because different plans keep replacing the manifest with different subsets.

In other words, the issue is not only "some deps are missing". The stronger issue is that distinct runtime dependency plans can prune each other when they share an install root.

Expected behavior

Once bundled runtime deps for the active OpenClaw version have been materialized, normal startup/control-ui/channel loading should not repeatedly run networked npm installs or repeatedly add/remove the same package groups.

Possible fix direction

One possible approach is to make the generated runtime dependency manifest behave as a superset for a shared install root:

1. When checking whether a dependency plan is already materialized, compare by package name and verify installed versions satisfy the currently required specs.
2. When writing the generated install manifest, merge existing manifest specs with newly required specs instead of replacing the manifest with only the latest subset.

That makes the shared install root monotonically accumulate the packages required by observed runtime dep plans, instead of allowing a later narrower plan to prune packages required by an earlier/wider one.

Alternative upstream designs that may be cleaner:

• give each independent runtime dependency plan its own install root
• compute one full bundled runtime dependency plan before installing
• move networked install/repair into an explicit prepare/doctor step instead of normal interactive startup paths

Useful diagnostics

Commands that helped distinguish this from a normal missing-dependency issue:

openclaw plugins deps --json
find ~/.openclaw/plugin-runtime-deps -name '*debug-0.log' -mtime -1 -print
pgrep -af 'npm.*install|openclaw.*plugins deps'

The confusing part is that openclaw plugins deps --json can eventually become clean while the user still experiences repeated npm activity during startup/control-ui/channel loading.

Environment

Observed on macOS with OpenClaw installed from npm globally:

OpenClaw 2026.4.29
macOS arm64
npm global package install

Related context

This may be adjacent to earlier runtime dependency work and reports, including:

• #63309
• #72270
• #58782
• #63065
• #67099

Those may not be exact duplicates. This issue is specifically about repeated npm add/remove churn caused by different runtime dependency plans sharing and overwriting one install root.