Summary

On a clean npm install -g [email protected], every Discord provider instance crash-loops immediately after plugin provisioning with:

[discord] [default] channel exited: Cannot find package 'openclaw' imported from
/home/<user>/.openclaw-<profile>/plugin-runtime-deps/openclaw-2026.4.22-<hash>/dist/extensions/discord/provider-<hash>.js
[discord] [default] auto-restart attempt N/10 in 300s

Gateway HTTP (/health) stays alive because only the Discord provider dies, but Discord messaging is completely broken fleet-wide. Affects 20/20 gateways in my deployment.

Environment

• OpenClaw: 2026.4.22 (commit 00bd2cf)
• Install: sudo npm install -g [email protected]
• npm prefix: /usr (so package is at /usr/lib/node_modules/openclaw)
• Node: v22.22.0
• OS: Ubuntu 24.04.4 LTS, kernel 6.8.0
• Previous version 2026.4.15 on the same machines did not exhibit this.

Root cause

The Discord provider at plugin-runtime-deps/openclaw-2026.4.22-<hash>/dist/extensions/discord/provider-<hash>.js does bare-specifier subpath imports:

import { normalizeAccountId } from "openclaw/plugin-sdk/account-id";
import { chunkItems, logDebug, ... } from "openclaw/plugin-sdk/text-runtime";
import { resolveAgentRoute } from "openclaw/plugin-sdk/routing";
// ... ~15 more 'openclaw/plugin-sdk/*' imports

The provider's own node_modules sibling directory (plugin-runtime-deps/openclaw-<hash>/node_modules/) is populated with every OTHER peer (acpx, @anthropic-ai, discord-api-types, @buape/carbon, etc.) — but openclaw itself is missing from it:

$ ls /home/openclaw/.openclaw-<profile>/plugin-runtime-deps/openclaw-2026.4.22-<hash>/node_modules/
accepts  acpx  agent-base  @agentclientprotocol  ajv  ajv-formats  ansi-regex  ...
# no `openclaw` directory here

Node's ESM resolver walks up from the provider file looking for node_modules/openclaw. It doesn't find it locally, and (because npm prefix is /usr) it doesn't reach the global /usr/lib/node_modules/openclaw either — user home is traversed but /usr is not an ancestor. The resolver gives up and throws.

The package exports declaration is valid:

$ jq '.exports | keys | map(select(test("plugin-sdk")))' /usr/lib/node_modules/openclaw/package.json
["./plugin-sdk", "./plugin-sdk/account-core", "./plugin-sdk/account-helpers", "./plugin-sdk/account-id", ...]

So subpath resolution would work if openclaw were findable. It just isn't findable from the plugin cache location.

Repro

1. Fresh Ubuntu 24, Node 22.
2. sudo npm install -g [email protected].
3. Create a profile with Discord configured, start the gateway.
4. First-boot plugin provisioning creates ~/.openclaw-<profile>/plugin-runtime-deps/openclaw-2026.4.22-<hash>/.
5. Observe [discord] channel exited: Cannot find package 'openclaw' in journalctl, followed by auto-restart attempt N/10.

Workaround (local patch, NOT a real fix)

mkdir -p ~/node_modules
ln -sfn /usr/lib/node_modules/openclaw ~/node_modules/openclaw
systemctl --user restart openclaw-gateway-<profile>

This puts openclaw on the Node ESM walk-up path (user home). Works because the resolver does reach ~/node_modules from ~/.openclaw-*/plugin-runtime-deps/.... Confirmed restart produces [gateway] ready (5 plugins: acpx, browser, discord, lobster, memory-core; ~9s) with zero further Cannot find package errors.

I can cleanly reproduce the bug by removing the symlink and restarting; it crash-loops again within one provisioning cycle.

Suggested fix

One of:

1. Include openclaw itself in the plugin-runtime-deps/openclaw-<hash>/node_modules/ bundle during plugin provisioning (simplest, matches how other peers are handled).
2. Or: rewrite the provider bundler to convert openclaw/plugin-sdk/* imports to relative paths into the same cache dir, since the subpath exports are stable.
3. Or: set NODE_PATH automatically in the spawned provider process to include the global install location.

Option 1 seems most aligned with the existing cache strategy.

Impact

This blocks all Discord I/O on any 4.22 install where npm prefix is /usr (the standard npm global location on Debian/Ubuntu when using apt-managed Node or a system install). Gateway HTTP endpoints stay up but the bot can neither send nor receive messages, so the Discord-integrated fleet workflow is non-functional until the symlink workaround is applied.

Happy to provide more journal output, full dependency listings, or test a patch.