Summary

On a packaged 2026.4.24 install, bundled runtime dependency staging can deterministically generate an anomalous secondary stage directory like ~/.openclaw/plugin-runtime-deps/openclaw-unknown-a44f41aef101.

This is not stale residue: the running Gateway can actively resolve modules from that unknown stage.

The strongest local root-cause evidence suggests a second staging pass is using the already-generated canonical stage root as packageRoot, so readPackageVersion(packageRoot) falls back to unknown, and createPathHash(packageRoot) hashes the canonical stage path.

Environment

• OpenClaw version: 2026.4.24
• Packaged install root: /usr/lib/node_modules/openclaw
• Canonical runtime deps stage root resolved by bundled runtime code:
  • /root/.openclaw/plugin-runtime-deps/openclaw-2026.4.24-4eca5026e977
• Recurrently generated anomalous stage:
  • /root/.openclaw/plugin-runtime-deps/openclaw-unknown-a44f41aef101
• Host type: Linux/systemd packaged install

Expected behavior

Bundled runtime deps should stage once from the real package root and consistently use the canonical stage directory for this packaged install.

Actual behavior

A second anomalous stage named openclaw-unknown-* is generated on restart and can become part of active runtime resolution.

Key evidence

1) Canonical packaged-install stage root is correct and stable

Local code-path verification of bundled runtime helpers showed the intended packaged-install root is the external runtime-deps stage, not /usr/lib/node_modules/openclaw/node_modules.

Resolved values observed locally:

• resolveBundledRuntimeDependencyPackageInstallRoot('/usr/lib/node_modules/openclaw', {env}) -> /root/.openclaw/plugin-runtime-deps/openclaw-2026.4.24-4eca5026e977
• resolveBundledRuntimeDependencyInstallRoot('/usr/lib/node_modules/openclaw/dist/extensions/browser', {env}) -> same canonical root
• resolveBundledRuntimeDependencyInstallRoot('/usr/lib/node_modules/openclaw/dist/extensions/feishu', {env}) -> same canonical root

2) openclaw-unknown-* is actively used, not stale

Post-start logs referenced modules from the anomalous stage, e.g. stack traces resolving through:

• /root/.openclaw/plugin-runtime-deps/openclaw-unknown-a44f41aef101/node_modules/axios/dist/node/axios.cjs
• /root/.openclaw/plugin-runtime-deps/openclaw-unknown-a44f41aef101/node_modules/follow-redirects/index.js

3) unknown is regenerated on restart

After quarantining/removing the anomalous stage and restarting the Gateway, it reappeared with fresh timestamps after service start, proving recurrence rather than historical residue.

4) The anomalous stage contains real bundled extension mirror contents

/root/.openclaw/plugin-runtime-deps/openclaw-unknown-a44f41aef101/dist/extensions contained many bundled channels/extensions (for example signal, imessage, mattermost, qqbot, msteams, telegram, googlechat, feishu, slack, discord, etc.), showing it is part of a normal staging/mirroring flow under degraded identity.

5) Bundled channel load failures also write npm cache under unknown

Observed log example:

• [channels] failed to load bundled channel whatsapp: npm error code 128
• npm log path under: /root/.openclaw/plugin-runtime-deps/openclaw-unknown-a44f41aef101/.openclaw-npm-cache/_logs/...

This strongly suggests bundled channel runtime staging/loading is happening under the anomalous root.

6) The hash suffix a44f41aef101 matches the canonical stage root path

By reproducing the hash logic locally, a44f41aef101 matched the path hash of:

• /root/.openclaw/plugin-runtime-deps/openclaw-2026.4.24-4eca5026e977

That means the anomalous directory name:

• openclaw-unknown-a44f41aef101

is consistent with computing:

• readPackageVersion(packageRoot) -> 'unknown'
• createPathHash(packageRoot) -> hash(canonical_stage_root_path)

This is the strongest indicator that a second staging pass is using the already-generated canonical stage root as packageRoot.

Relevant code shape observed locally

From bundled runtime code:

const packageRoot = resolveBundledPluginPackageRoot(params.pluginRoot) ?? params.pluginRoot;
const packageKey = `openclaw-${sanitizePathSegment(readPackageVersion(packageRoot))}-${createPathHash(packageRoot)}`;

And:

function readPackageVersion(packageRoot) {
  const parsed = readJsonObject(path.join(packageRoot, 'package.json'));
  return (parsed && typeof parsed.version === 'string' ? parsed.version.trim() : '') || 'unknown';
}

If packageRoot is accidentally the canonical stage root, there is no valid top-level package version there, so unknown is expected.

Impact

• Split-stage runtime state (canonical + unknown)
• Recurrent restaging on restart
• Runtime module resolution may land in the anomalous stage
• One-time cleanup does not stick
• Operationally, users may be forced into symlink-based stabilization/workarounds just to keep runtime deps resolvable across restarts

Practical workaround currently required

On this affected host, the only stable workaround found so far is to let both:

• canonical stage root
• anomalous unknown stage root

resolve the same node_modules, rather than trying to delete unknown permanently.

What seems worth checking upstream

• Whether bundled runtime deps / mirror code can accidentally feed a stage root back into package-root resolution during a second staging pass
• Whether resolveBundledPluginPackageRoot(...) / mirror remap logic can return a staged path instead of the original package root
• Whether stage roots should carry enough metadata to avoid unknown, or better, whether they should never be treated as package roots at all
• Whether bundled channel loading (e.g. whatsapp) is triggering this path especially often

If useful, I can also provide

• exact restart timeline / timestamps showing regeneration order
• exact file paths and code references from the packaged dist/*.js files inspected locally
• log excerpts for the whatsapp failure and unknown npm cache path