openclaw - 💡(How to fix) Fix [Bug] doctor false-misses bundled runtime deps and bundled channel loader can hit ENOTEMPTY on plugin-sdk alias [1 comments, 2 participants]

Summary

On OpenClaw 2026.4.24, I hit two related bundled-runtime-deps problems on macOS:

1. openclaw doctor kept reporting Bundled plugin runtime deps are missing and openclaw gateway restart stayed slow because bundled runtime deps were repeatedly restaged.
2. During doctor / bundled channel loading, channel startup could warn with ENOTEMPTY ... openclaw/plugin-sdk.

After local investigation, the machine is stable again, but both behaviors look like upstream bugs rather than just local config mistakes.

Environment

• OpenClaw: 2026.4.24
• Install method: npm global install, not a git checkout
• OS: macOS

Symptoms observed

A. doctor kept reporting missing bundled runtime deps

openclaw doctor repeatedly showed:

Bundled plugin runtime deps are missing.
- @anthropic-ai/[email protected]
- @anthropic-ai/vertex-sdk@^0.16.0
- @aws-sdk/[email protected]
- @aws-sdk/[email protected]
- @aws-sdk/[email protected]
- @aws/bedrock-token-generator@^1.1.0
- @clack/prompts@^1.2.0
- @google/genai@^1.50.1
- @grammyjs/runner@^2.0.3
- @grammyjs/transformer-throttler@^1.2.1
- @homebridge/ciao@^1.3.6
- @mariozechner/[email protected]
- @mariozechner/[email protected]
- @modelcontextprotocol/[email protected]
- @mozilla/readability@^0.6.0
- [email protected]
- commander@^14.0.3
- express@^5.2.1
- grammy@^1.42.0
- linkedom@^0.18.12
- node-edge-tts@^1.2.10
- pdfjs-dist@^5.6.205
- [email protected]
- [email protected]
- [email protected]
- ws@^8.20.0

At the same time, gateway logs showed bundled plugins restaging/installing runtime deps during startup, which made restart slower than expected.

B. ENOTEMPTY while loading bundled channels

I also reproduced warnings like:

[channels] failed to load bundled channel feishu: ENOTEMPTY, Directory not empty: /Users/.../.openclaw/plugin-runtime-deps/openclaw-2026.4.24-.../dist/extensions/node_modules/openclaw/plugin-sdk

I saw the same family of warning for qqbot, telegram, and earlier for imessage.

Investigation notes

1. The package-level runtime dep scan and the runtime dep layout did not agree

scanBundledPluginRuntimeDeps() resolves the package install root and checks sentinels under:

<installRoot>/node_modules/<pkg>/package.json

Relevant code:

• dist/bundled-runtime-deps-BdEAdjwi.js
  • resolveBundledRuntimeDependencyPackageInstallRoot(...)
  • scanBundledPluginRuntimeDeps(...)
  • dependencySentinelPath(...)
  • hasDependencySentinel(...)

On this machine, the runtime deps that were actually present were under:

~/.openclaw/plugin-runtime-deps/openclaw-2026.4.24-.../dist/extensions/node_modules/...

but not under:

~/.openclaw/plugin-runtime-deps/openclaw-2026.4.24-.../node_modules/...

I verified this directly:

• scanBundledPluginRuntimeDeps(...) returned missing: 26
• but the same packages existed under dist/extensions/node_modules/...

Once I made the package install root expose node_modules at the location the scan expects, the same scan returned missing: 0 and doctor stopped reporting missing bundled runtime deps.

That suggests the scan logic and the effective runtime dep layout can drift apart, causing doctor false negatives and repeated restaging during startup.

2. bundled-runtime-root-CuaPBWeD.js still has older plugin-sdk alias logic

I found that these two files differ:

• dist/loader-NucjcOgv.js
• dist/bundled-runtime-root-CuaPBWeD.js

In loader-NucjcOgv.js, ensureOpenClawPluginSdkAlias() is already defensive:

• it only removes pluginSdkAliasDir if it exists and is not a directory
• otherwise it reuses the directory and writes wrappers into it

But in bundled-runtime-root-CuaPBWeD.js, ensureOpenClawPluginSdkAlias() still did this:

fs.rmSync(pluginSdkAliasDir, {
  recursive: true,
  force: true
});
fs.mkdirSync(pluginSdkAliasDir, { recursive: true });

Locally, changing bundled-runtime-root-CuaPBWeD.js to match the safer loader-NucjcOgv.js behavior removed the ENOTEMPTY warnings in doctor.

So this part looks like a real code drift / stale implementation issue.

Local workaround that restored a healthy state

What got this machine back to normal:

1. Ensure the bundled runtime deps are visible at the package install root path that scanBundledPluginRuntimeDeps() checks.
2. Patch dist/bundled-runtime-root-CuaPBWeD.js so ensureOpenClawPluginSdkAlias() behaves like the safer implementation already present in dist/loader-NucjcOgv.js.

After that:

• scanBundledPluginRuntimeDeps(...) returned missing: 0
• openclaw doctor no longer reported Bundled plugin runtime deps are missing
• openclaw gateway restart dropped from very slow / timeout-prone behavior to about 10-15 seconds on this machine
• openclaw gateway status --deep returned Connectivity probe: ok and Capability: admin-capable

Suggestion

I think this is worth fixing in two places:

1. Runtime dep scan / install-root consistency

   • Make sure the path used by scanBundledPluginRuntimeDeps() is always the same path where bundled runtime deps are actually materialized for packaged installs.
   • Or tolerate the dist/extensions/node_modules layout if that is intentional.

2. Unify plugin-sdk alias behavior

   • Make dist/bundled-runtime-root-CuaPBWeD.js use the same safe directory-handling logic that already exists in dist/loader-NucjcOgv.js.

If useful, I can also provide a very small patch diff for the bundled-runtime-root part, since I already validated that locally.