openclaw - 💡(How to fix) Fix Plugin register fails with ENOTEMPTY in openclaw-unknown-* shadow runtime-deps dir on every gateway boot [2 comments, 3 participants]

Summary

On every ai.openclaw.gateway launch, the plugin loader fails to register the bundled Telegram plugin (and several other channels) with ENOTEMPTY. Two related directories live under ~/.openclaw/plugin-runtime-deps/:

• openclaw-2026.4.24-02f98c7ef353/ — the expected versioned dir
• openclaw-unknown-2018ccba5afc/ — a shadow dir with unknown instead of a version. This appears to come from a version-detection fallback during install, and once it exists, every subsequent boot stages new plugin content into it but cannot complete because the destination tree already exists.

Trashing the entire ~/.openclaw/plugin-runtime-deps/ directory and restarting the gateway recreates the same broken pair immediately on first boot — so this isn't stale state from a prior install. The install logic itself produces the broken state.

Environment

• openclaw: 2026.4.24
• node: v25.9.0 (also reproduced under v24.14.0 nvm)
• npm: 11.12.1
• macOS: 26.3.1
• Bound: loopback ws://127.0.0.1:18789

Reproduction

1. With openclaw installed and gateway running, observe ~/.openclaw/plugin-runtime-deps/ contains a versioned dir (openclaw-<version>-<hash>) AND a shadow openclaw-unknown-<hash> dir.
2. trash ~/.openclaw/plugin-runtime-deps
3. launchctl kickstart -k gui/$UID/ai.openclaw.gateway
4. After restart, ls ~/.openclaw/plugin-runtime-deps/ shows both dirs again.
5. openclaw status reports [plugins] telegram failed during register with ENOTEMPTY.

Concrete error log lines

From ~/.openclaw/logs/gateway.err.log, two distinct ENOTEMPTY shapes seen back-to-back across two consecutive gateway restarts (timestamps within the same incident, log lines abbreviated for readability):

[plugins] telegram failed during register from
  /…/node_modules/openclaw/dist/extensions/telegram/index.js:
  Error: ENOTEMPTY, Directory not empty:
    /Users/<user>/.openclaw/plugin-runtime-deps/openclaw-unknown-2018ccba5afc/dist/extensions/node_modules/openclaw/plugin-sdk
    '/Users/<user>/.openclaw/plugin-runtime-deps/openclaw-unknown-2018ccba5afc/dist/extensions/node_modules/openclaw/plugin-sdk'

[plugins] telegram failed during register from
  /…/node_modules/openclaw/dist/extensions/telegram/index.js:
  Error: ENOTEMPTY: directory not empty, rename
    '/Users/<user>/.openclaw/plugin-runtime-deps/openclaw-unknown-2018ccba5afc/dist/extensions/.plugin-telegram-pgHesQ/plugin'
    →
    '/Users/<user>/.openclaw/plugin-runtime-deps/openclaw-unknown-2018ccba5afc/dist/extensions/telegram'

The .plugin-telegram-<random> directory naming suggests a "stage to temp dir then atomic rename" pattern. The atomic rename is failing because the destination (extensions/telegram) already exists from a prior boot's partial install — and the rename target itself is a directory, so fs.renameSync cannot replace it.

Earlier on the same boot, the node_modules/openclaw/plugin-sdk ENOTEMPTY suggests the same atomic-replace pattern is applied to the bundled plugin-sdk SDK at a different stage.

Other bundled channels error similarly (visible in openclaw status output): bluebubbles, discord, googlechat, imessage, irc, msteams, nextcloud-talk, nostr, synology-chat, twitch, whatsapp. They all hit the same ENOTEMPTY on extensions/node_modules/openclaw/plugin-sdk in both the versioned and unknown- shadow dirs.

Likely root cause

Two suspected issues working together:

1. Version detection occasionally returns unknown, which makes the install pick a different runtime-deps directory name (openclaw-unknown-<hash>) instead of openclaw-<version>-<hash>. This shadow dir then accumulates state independently from the versioned one.

2. Plugin extraction is not idempotent. The "stage to temp dir, then rename to final location" pattern doesn't account for the final-location dir already existing. On a clean install this works; on subsequent installs, renameSync of dir → dir hits ENOTEMPTY. The extraction logic should either:

   • rm -rf (or platform-equivalent) the destination dir before rename, OR
   • skip the install if a valid version is already present, OR
   • use a content-addressed install path so successive installs don't collide.

The plugin-sdk ENOTEMPTY at the node_modules/openclaw/plugin-sdk path is a related but separate manifestation of the same non-idempotent extraction.

Impact

• The bundled Telegram plugin fails to register entirely; any code path using openclaw gateway call chat.send or the openclaw-mediated Telegram delivery fails.
• Workaround: applications that need Telegram delivery can bypass the plugin and curl https://api.telegram.org/bot<token>/sendMessage directly. We've been doing this in our integration successfully.
• The gateway itself otherwise functions; openclaw status still produces output, just with the plugin errors prepended.

Suggested next steps

• Reproduce locally with the steps above and verify the openclaw-unknown-* shadow dir is created on every gateway boot.
• Make plugin extraction idempotent (delete destination before rename, or use a content-hashed final path).
• Surface the version-detection failure that produces unknown rather than silently producing a parallel install dir.

Happy to capture more diagnostics on request — sanitized log files, gateway start traces, or a minimal repro on a different machine.