Bug Report

OpenClaw version: 2026.4.22 (also reproduces on 2026.4.23)
Node: 22.22.0
npm: 10.9.4
OS: Ubuntu 24.04.3 LTS (Linux 6.8.0-107-generic, x86_64)
jiti: 2.6.1 (bundled in openclaw/node_modules/jiti)
Install path: /usr/lib/node_modules/openclaw (via sudo npm install -g openclaw)
Run mode: user-level systemd --user unit (openclaw-gateway.service), default systemd hardening only — no ProtectHome=true / ProtectSystem=strict

Summary

The jiti-based plugin loader fails to import every bundled plugin whose transitive dep chain touches typebox's re-export barrels. This takes out anthropic, google, lmstudio, xai, memory-core (and likely every pi-ai / pi-coding-agent user — i.e. most provider plugins) with an Error: Cannot find module './<name>.mjs' coming from typebox, even though the referenced .mjs files do exist on disk and load fine under plain Node ESM. The loader then retries the whole chain on each failure, which in 2026.4.23 (see secondary regression below) spawns a ~17-package merged npm install on every retry and effectively hangs the gateway for minutes.

Observed errors (last ~7 h, single host)

  37  Cannot find module './el_GR.mjs'
  30  Cannot find module './else.mjs'
   1  Cannot find module './additionalProperties.mjs'
  14  Cannot find module '@whiskeysockets/baileys'   (separate, pre-existing)

Sample lines:

[plugins] anthropic failed to load from /usr/lib/node_modules/openclaw/dist/extensions/anthropic/index.js:
  Error: Cannot find module './else.mjs'
[plugins] google    failed to load from .../google/index.js:   Error: Cannot find module './else.mjs'
[plugins] lmstudio  failed to load from .../lmstudio/index.js: Error: Cannot find module './else.mjs'
[plugins] xai       failed to load from .../xai/index.js:      Error: Cannot find module './el_GR.mjs'
[plugins] memory-core failed to load from .../memory-core/index.js: Error: Cannot find module './el_GR.mjs'

The filename in the error rotates between else.mjs, el_GR.mjs, and additionalProperties.mjs across runs/plugins — all three are valid files inside typebox@1.1.28:

• typebox/build/schema/types/else.mjs
• typebox/build/system/locale/el_GR.mjs
• typebox/build/schema/types/additionalProperties.mjs

Import site (the one the barrel-export comes from):

• typebox/build/schema/types/index.mjs → export * from './else.mjs'; (among many)
• typebox/build/system/locale/_locale.mjs → export * from './el_GR.mjs'; (among many)

Key signal: files exist, native Node imports them fine

$ ls /usr/lib/node_modules/openclaw/node_modules/typebox/build/schema/types/else.mjs
-rw-r--r-- 1 root root 4410 Apr 24 18:53 .../else.mjs

$ cd /usr/lib/node_modules/openclaw/dist/extensions/anthropic
$ node -e "import('./index.js').then(m => console.log('OK', Object.keys(m)))"
OK [ 'default' ]

So /usr/lib/node_modules/openclaw/dist/extensions/anthropic/index.js loads cleanly under the same Node binary that the gateway uses. Only the openclaw plugin loader path (getJiti(safeSource)(safeImportSource) in loader-*.js, ~line 2914) fails.

I also scanned the whole bundled typebox for missing ./*.mjs re-export targets — no files are missing. So this is not a packaging issue on the typebox side (unlike the Windows report #70837 where collapse.mjs was genuinely absent). It is specifically a jiti resolution issue against typebox's barrel re-exports, triggered during openclaw plugin loading.

Impact

• Default agent model is anthropic/claude-opus-4-6, so every agent using Claude, Gemini, LM Studio, or xAI is unusable until the loader succeeds.
• Only clawdx-plugin and telegram make it through — they do not pull in the typebox code path that blows up.
• Plugin loader retries on a ~10–15 s interval forever, so the log fills with the same error and memory-core (embedding lookups) repeatedly fails.

Secondary regression introduced in 2026.4.23

Not the same bug but very visible because the loader failure above triggers it on every retry:

On 2026.4.23, each retry of a failed-to-load plugin kicks off a merged npm install at ~/.openclaw/plugin-runtime-deps/openclaw-<ver>-<hash>/ with a ~17-package flat spec list aggregated across plugins:

npm install @anthropic-ai/sdk@0.90.0 \
  @aws-sdk/client-bedrock-runtime@3.1033.0 @aws-sdk/client-bedrock@3.1033.0 \
  @aws-sdk/credential-provider-node@3.972.33 @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 \
  @mariozechner/pi-ai@0.70.0 @mariozechner/pi-coding-agent@0.70.0 \
  ajv@^8.18.0 grammy@^1.42.0 typebox@1.1.28 undici@8.1.0 ws@^8.20.0 zod@^4.3.6

That install takes ~2 min wall time on a fast connection and runs on every retry — so from the operator's POV it presents as npm install "hanging" the gateway indefinitely. On 2026.4.22 this merged install does not happen; only per-plugin installs fire, each ~5 s. So something between 4.22 and 4.23 started aggregating all plugin runtime deps into a single retry-bound install. (Relevant code: ensureBundledPluginRuntimeDeps / installBundledRuntimeDeps in the bundled bundled-runtime-deps-*.js.)

Reproduction

1. sudo npm install -g openclaw@2026.4.22 on a clean Ubuntu 24.04 host (Node 22.22.0, npm 10.9.4).
2. rm -rf ~/.openclaw/plugin-runtime-deps
3. Enable the bundled anthropic plugin (or any other provider plugin that pulls in typebox via @mariozechner/pi-ai).
4. openclaw gateway start and watch journalctl --user -u openclaw-gateway -f.

Expected: plugins load, gateway reports ready (N plugins: ...) with provider plugins included.

Actual: gateway reports ready (2 plugins: clawdx-plugin, telegram; ~7s) and the provider plugins keep failing with Cannot find module './else.mjs' (or ./el_GR.mjs).

Sanity check that this is loader-specific, not a disk/typebox issue:

cd /usr/lib/node_modules/openclaw/dist/extensions/anthropic
node -e "import('./index.js').then(m => console.log('OK')).catch(e => console.error(e))"
# → OK [ 'default' ]

Earlier versions tried

So 4.22 is the most functional version on Linux-with-global-npm-install today, but the loader bug still makes every Claude/Gemini agent non-functional.

Workaround

None that I've found. Forcing Node to load the bundled index.js directly works (shown above), but there is no config flag to disable the jiti path in the gateway loader.

Suggested follow-ups

1. Fix the jiti-vs-typebox-re-export resolution. Either upgrade/downgrade jiti, stop running .mjs files through jiti when they can be loaded natively (they are already ESM), or pre-resolve typebox's barrels at package time.
2. Gate the merged runtime-deps install behind an "initial install only" check so a per-plugin load failure does not trigger a full cross-plugin reinstall every retry (the 4.23 regression).
3. When a plugin fails to load N times with the same error, stop retrying and surface a single clear error instead of filling the log indefinitely.

Related

• Bug: tavily extension fails to load - typebox missing collapse.mjs #70837 — Windows, same error shape but the .mjs is actually missing from the bundle (a different root cause in the same code path).
• [Bug]: 4.22 plugin loader performs runtime npm install into ~/.npm/_cacache, fails under systemd ProtectHome=true #71070 — 4.22 runtime-npm-install regression under ProtectHome=true; related in that 4.12+ started doing runtime deps resolution at startup.
• [Bug]: Windows plugin TS source-loading via jiti is pathologically slow in real production call sites #59281, Bundled channel plugins cause stack overflow via jiti module loading #61259, CLI agent/message commands 100% crash: jiti TDZ ReferenceError in pi-embedded #61875, [Bug]: Infinite CPU loop from jiti circular require when loading bundled plugin metadata #56946, Feishu channel crash on Windows: dual jiti/ESM module instance splits runtime store #61614 — other jiti-in-plugin-loader issues; this one is another data point.