openclaw - ✅(Solved) Fix v2026.4.22: Telegram channels crash on startup — Cannot find package 'openclaw' in plugin-runtime-deps [1 pull requests, 4 comments, 4 participants]

Official PRs (…)
ON THIS PAGE

Recommended Tools

×6

Utilities matched from this issue’s tags and category — try them while you read without losing context.

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

Helpful · Quick feedback

Loading…
GitHub stats
openclaw/openclaw#70701Fetched 2026-04-24 05:54:27
View on GitHub
Comments
4
Participants
4
Timeline
13
Reactions
1
Timeline (top)
cross-referenced ×5commented ×4referenced ×2closed ×1

Error Message

[default] channel exited: Cannot find package 'openclaw' imported from /Users/<user>/.openclaw/plugin-runtime-deps/openclaw-2026.4.22-1cdd6313f129/dist/extensions/telegram/account-config-Cifs-fXF.js
[default] auto-restart attempt 6/10 in 171s

Same error for every configured Telegram account (iris, argus, venus, default).

Root Cause

The new plugin-runtime-deps directory for 2026.4.22 (openclaw-2026.4.22-1cdd6313f129/node_modules/) is missing the openclaw package itself. The Telegram extension code tries to import from 'openclaw' but the package isn't present in the plugin-runtime-deps node_modules.

Previous versions had this package available; the 2026.4.22 update appears to have omitted it.

Fix Action

Workaround

Manually symlinking the openclaw package fixes it:

ln -sf ~/.local/lib/node_modules/openclaw   ~/.openclaw/plugin-runtime-deps/openclaw-2026.4.22-1cdd6313f129/node_modules/openclaw
openclaw gateway restart

PR fix notes

PR #70852: fix(plugins): stage bundled-plugin runtime-dep install outside the plugin root

Description (problem / solution / changelog)

Summary

Fixes gateway-startup plugin-runtime-dep install failure on packaged (Docker image, npm global) installs of 2026.4.22 where every bundled plugin whose package.json still contains a workspace:* dep fails with:

npm error code EUNSUPPORTEDPROTOCOL
npm error Unsupported URL Type "workspace:": workspace:*

Reported in #70844 (Docker image, EUNSUPPORTEDPROTOCOL at install step); same root cause as #70701, #70756, #70773, #70818, #70839 (npm global, downstream Cannot find package 'openclaw' from plugin-runtime-deps/… at ESM import).

Root cause

ensureBundledPluginRuntimeDeps in src/plugins/bundled-runtime-deps.ts already filters workspace: specs from the CLI argument list (normalizeInstallableRuntimeDepVersion, parseInstallableRuntimeDep). But the install step is spawnSync("npm", ["install", ...specs], { cwd: installExecutionRoot }), and installExecutionRoot defaults to installRoot. When installRoot === pluginRoot (the packaged case where the plugin dir is writable and no external stage is configured), npm reads the plugin's own package.json as the project manifest and tries to resolve its workspace:* deps — failing the whole batch regardless of what was passed on the CLI.

Evidence: upstream/main carries workspace:* declarations in 106 extensions/*/package.json (predominantly "@openclaw/plugin-sdk": "workspace:*"). The 18 plugins that fail in the Docker repro are exactly the subset that declare such entries as runtime deps (dependencies / optionalDependencies).

The npm-global variants in #70701 / #70756 / #70773 / #70818 / #70839 hit a related but different surface: resolveBundledRuntimeDependencyInstallRoot resolves to an external stage dir (clean manifest), so npm install succeeds but the resulting node_modules/ tree does not satisfy the filtered-out workspace packages, and the subsequent ESM import of openclaw fails at plugin load. Same defect class, different failure point.

Fix

Activate the existing isolated-execution-root + replaceNodeModulesDir machinery for the packaged case too. When installRoot === pluginRoot and we are not in the source-checkout cache-dir path, stage the install inside <installRoot>/.openclaw-install-stage (minimal generated package.json) and move the produced node_modules/ back to the plugin root as before.

+const isPluginRootInstall =
+  path.resolve(installRoot) === path.resolve(params.pluginRoot);
+const sourceCheckoutCacheStage =
+  cacheDir &&
+  isPluginRootInstall &&
+  resolveSourceCheckoutBundledPluginPackageRoot(params.pluginRoot)
+    ? cacheDir
+    : undefined;
 const installExecutionRoot =
-  cacheDir &&
-  path.resolve(installRoot) === path.resolve(params.pluginRoot) &&
-  resolveSourceCheckoutBundledPluginPackageRoot(params.pluginRoot)
-    ? cacheDir
-    : undefined;
+  sourceCheckoutCacheStage ??
+  (isPluginRootInstall ? path.join(installRoot, PLUGIN_ROOT_INSTALL_STAGE_DIR) : undefined);

No change to the existing workspace: filter, no new surface, no change to external stage or source-checkout semantics.

Shape note

@steipete flagged in #70138 that runtime-dep repair belongs at gateway/plugin startup (not npm pack postinstall). This change keeps that contract — it only widens when the existing stage/move is activated; the repair still runs through ensureBundledPluginRuntimeDeps called from src/plugins/loader.ts:2190. It does not reintroduce the eager-install shape that was closed in #70650.

Validation

  • pnpm exec vitest run --config test/vitest/vitest.plugins.config.ts src/plugins/bundled-runtime-deps.test.ts — 31/31 (includes 1 new regression test: stages plugin-root install when the plugin's own package.json declares workspace:* deps)
  • pnpm exec vitest run --config test/vitest/vitest.plugins.config.ts src/plugins/ — 43/43 across 8 test files
  • pnpm exec tsgo --noEmit -p tsconfig.core.json — clean
  • pnpm exec tsgo --noEmit -p tsconfig.core.test.json — clean
  • pnpm exec oxlint src/plugins/bundled-runtime-deps.ts src/plugins/bundled-runtime-deps.test.ts — 0 warnings, 0 errors
  • node scripts/check-src-extension-import-boundary.mjs --json[]
  • node scripts/check-sdk-package-extension-import-boundary.mjs --json[]

I did not run codex review --base origin/main because I do not have Codex CLI access locally; happy to run Codex review in a later iteration if a maintainer provides guidance.

Test plan

  • Build ghcr.io/openclaw/openclaw:<this-branch> and verify gateway startup against an existing ~/.openclaw that was pre-populated from 2026.4.15, reproducing the repro in #70844 from a clean state.
  • Smoke: verify <pluginRoot>/node_modules/ is populated after gateway start and the .openclaw-install-stage/ sub-directory is cleaned up / idempotent across restarts.
  • Spot-check that source-checkout dev flow (pnpm dev in the monorepo) still uses the cache-dir stage (not .openclaw-install-stage/) so no regression on contributor ergonomics.
  • Cross-check with reporters on #70701 / #70756 / #70773 / #70818 / #70839 that the downstream Cannot find package 'openclaw' symptom also resolves.

AI assistance

This PR was AI-assisted with Claude Code (Opus 4.7). All code paths changed here were read end-to-end by me; the diagnosis against src/plugins/loader.ts:2190 and src/plugins/bundled-runtime-deps.ts is documented in the linked issue #70844 comment thread.

Testing degree: fully tested for the touched bundled-plugin runtime-dep install-staging surface.

I understand the code path changed here: packaged bundled plugins now stage their runtime-dep install one directory below pluginRoot so npm never reads the plugin's workspace:*-containing manifest during install; the existing replaceNodeModulesDir helper moves the produced node_modules/ back to pluginRoot after install succeeds.

Closes #70844

Changed files

  • CHANGELOG.md (modified, +1/-1)
  • scripts/e2e/bundled-channel-runtime-deps-docker.sh (modified, +2/-1)
  • src/plugins/bundled-runtime-deps.test.ts (modified, +96/-0)
  • src/plugins/bundled-runtime-deps.ts (modified, +69/-34)
  • src/plugins/loader.test.ts (modified, +34/-27)
  • src/plugins/loader.ts (modified, +2/-1)

Code Example

[default] channel exited: Cannot find package 'openclaw' imported from /Users/<user>/.openclaw/plugin-runtime-deps/openclaw-2026.4.22-1cdd6313f129/dist/extensions/telegram/account-config-Cifs-fXF.js
[default] auto-restart attempt 6/10 in 171s

---

ln -sf ~/.local/lib/node_modules/openclaw   ~/.openclaw/plugin-runtime-deps/openclaw-2026.4.22-1cdd6313f129/node_modules/openclaw
openclaw gateway restart
RAW_BUFFERClick to expand / collapse

Bug Report

Version: OpenClaw 2026.4.22 (00bd2cf) OS: macOS Darwin 25.4.0 (arm64) Node: v24.13.0

What happened

After updating to 2026.4.22, all Telegram bot accounts (default, and multi-account agents) immediately crash on startup with a crash-restart loop. None of the bots receive or respond to Telegram messages.

Error

[default] channel exited: Cannot find package 'openclaw' imported from /Users/<user>/.openclaw/plugin-runtime-deps/openclaw-2026.4.22-1cdd6313f129/dist/extensions/telegram/account-config-Cifs-fXF.js
[default] auto-restart attempt 6/10 in 171s

Same error for every configured Telegram account (iris, argus, venus, default).

Root Cause

The new plugin-runtime-deps directory for 2026.4.22 (openclaw-2026.4.22-1cdd6313f129/node_modules/) is missing the openclaw package itself. The Telegram extension code tries to import from 'openclaw' but the package isn't present in the plugin-runtime-deps node_modules.

Previous versions had this package available; the 2026.4.22 update appears to have omitted it.

Workaround

Manually symlinking the openclaw package fixes it:

ln -sf ~/.local/lib/node_modules/openclaw   ~/.openclaw/plugin-runtime-deps/openclaw-2026.4.22-1cdd6313f129/node_modules/openclaw
openclaw gateway restart

Impact

  • All Telegram channels broken out of the box after update
  • All agents dead on Telegram until workaround applied
  • Auto-restart loop (6/10 attempts) burns resources

extent analysis

TL;DR

Manually symlinking the openclaw package to the plugin-runtime-deps directory fixes the crash-restart loop issue with Telegram bot accounts.

Guidance

  • Verify that the openclaw package is missing from the plugin-runtime-deps directory by checking the directory contents.
  • Apply the provided workaround by running the ln -sf command to create a symlink to the openclaw package.
  • Restart the OpenClaw gateway after applying the workaround to ensure the changes take effect.
  • Monitor the Telegram bot accounts to confirm they are receiving and responding to messages correctly.

Example

The workaround command is: ```bash ln -sf ~/.local/lib/node_modules/openclaw ~/.openclaw/plugin-runtime-deps/openclaw-2026.4.22-1cdd6313f129/node_modules/openclaw

Followed by `openclaw gateway restart`.

## Notes
This workaround assumes that the `openclaw` package is installed in the default location (`~/.local/lib/node_modules/`). If the package is installed in a different location, the symlink path will need to be adjusted accordingly.

## Recommendation
Apply the workaround by symlinking the `openclaw` package, as it is a direct fix for the missing package issue causing the crash-restart loop.

Vote matrix · Quick signals

Works
Did the solution work? Tap to confirm.
Easy Fix
Was it a quick fix?
Time Saver
Did it save you time?
Blocking
Was it severely blocking?
Common Issue
Are others likely hitting this too?
Flaky / Intermittent
Is it intermittent?
Verified / Reproducible
Can you reproduce it reliably?
Loading…

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

Back to top recommendations

TRENDING