openclaw - ✅(Solved) Fix [Bug]: Telegram channel keeps loading stale runtime hash after update/reinstall (Cannot find package 'openclaw' from plugin-runtime-deps) [1 pull requests, 2 comments, 3 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#70773Fetched 2026-04-24 05:53:53
View on GitHub
Comments
2
Participants
3
Timeline
9
Reactions
0
Author
Timeline (top)
commented ×2cross-referenced ×2labeled ×2referenced ×2

After updating to OpenClaw 2026.4.22 (00bd2cf), Telegram channel startup repeatedly fails with: Cannot find package 'openclaw' imported from .../.openclaw/plugin-runtime-deps/openclaw-2026.4.22-4eca5026e977/... It appears to resolve a stale runtime hash (4eca...) although the installed build is 00bd2cf.

Root Cause

After updating to OpenClaw 2026.4.22 (00bd2cf), Telegram channel startup repeatedly fails with: Cannot find package 'openclaw' imported from .../.openclaw/plugin-runtime-deps/openclaw-2026.4.22-4eca5026e977/... It appears to resolve a stale runtime hash (4eca...) although the installed build is 00bd2cf.

Fix Action

Fix / Workaround

Workaround:

  • downgrade to 2026.4.20 restores functionality.

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

- `[plugins] telegram installed bundled runtime deps: @grammyjs/runner..., grammy...`
- `[telegram] [default] starting provider (...)`
- `[telegram] [default] channel exited: Cannot find package 'openclaw' imported from /home/.../.openclaw/plugin-runtime-deps/openclaw-2026.4.22-4eca.../dist/extensions/telegram/monitor-polling.runtime-...js`
- auto-restart repeats

Troubleshooting already done:
- cleared `~/.openclaw/plugin-runtime-deps`, `~/.openclaw/cache`, npm cache
- reinstalled `[email protected]`
- verified old `4eca...` dirs no longer present on disk
- issue persists at runtime

Workaround:
- downgrade to `2026.4.20` restores functionality.
RAW_BUFFERClick to expand / collapse

Bug type

Regression (worked before, now fails)

Beta release blocker

No

Summary

After updating to OpenClaw 2026.4.22 (00bd2cf), Telegram channel startup repeatedly fails with: Cannot find package 'openclaw' imported from .../.openclaw/plugin-runtime-deps/openclaw-2026.4.22-4eca5026e977/... It appears to resolve a stale runtime hash (4eca...) although the installed build is 00bd2cf.

Steps to reproduce

  1. Install/update to [email protected] (global npm install).
  2. Start gateway as non-root user.
  3. Observe startup logs for Telegram provider

Expected behavior

Telegram provider should load runtime deps from the currently installed build and start normally.

Actual behavior

Telegram provider exits and auto-restarts in a loop with: Cannot find package 'openclaw' imported from ...openclaw-2026.4.22-4eca.../dist/extensions/telegram/monitor-polling.runtime-...js

OpenClaw version

2026.4.22 (00bd2cf)

Operating system

Linux (Debian/Ubuntu-like)

Install method

Global npm install (/usr/lib/node_modules/openclaw)

Model

openai/gpt-5.2 (agent model in gateway logs)

Provider / routing chain

OpenRouter (via OpenClaw gateway)

Additional provider/model setup details

No unusual model/provider customization relevant to this issue. Problem occurs during Telegram plugin/channel startup.

Logs, screenshots, and evidence

- `[plugins] telegram installed bundled runtime deps: @grammyjs/runner..., grammy...`
- `[telegram] [default] starting provider (...)`
- `[telegram] [default] channel exited: Cannot find package 'openclaw' imported from /home/.../.openclaw/plugin-runtime-deps/openclaw-2026.4.22-4eca.../dist/extensions/telegram/monitor-polling.runtime-...js`
- auto-restart repeats

Troubleshooting already done:
- cleared `~/.openclaw/plugin-runtime-deps`, `~/.openclaw/cache`, npm cache
- reinstalled `[email protected]`
- verified old `4eca...` dirs no longer present on disk
- issue persists at runtime

Workaround:
- downgrade to `2026.4.20` restores functionality.

Impact and severity

High for affected installs: Telegram channel is unusable (crash/restart loop), blocks messaging workflows.

Additional information

Potentially related to previous bundled runtime dependency issues:

  • #58701
  • #60263
  • #59286
  • #59867
  • #69842

This report may be a variant specifically involving stale runtime hash resolution in 2026.4.22.

extent analysis

TL;DR

The most likely fix is to downgrade OpenClaw to version 2026.4.20 as a temporary workaround until the issue with stale runtime hash resolution in 2026.4.22 is resolved.

Guidance

  • Verify that the issue is indeed caused by the stale runtime hash resolution by checking the logs for the Cannot find package 'openclaw' error and the presence of the old 4eca... directory.
  • Try clearing the ~/.openclaw/plugin-runtime-deps and ~/.openclaw/cache directories again, as well as the npm cache, to ensure that all old dependencies are removed.
  • If the issue persists, consider reporting it as a bug related to the previous bundled runtime dependency issues (#58701, #60263, #59286, #59867, #69842).
  • Test the workaround by downgrading to 2026.4.20 and verify that the Telegram channel starts normally.

Example

No code snippet is provided as the issue seems to be related to a specific version of OpenClaw and its dependencies.

Notes

The issue may be specific to the 2026.4.22 version of OpenClaw, and downgrading to 2026.4.20 may not be a permanent solution. Further investigation and debugging may be required to resolve the issue.

Recommendation

Apply the workaround by downgrading to 2026.4.20 until a fixed version of OpenClaw is released, as it has been verified to restore functionality.

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…

FAQ

Expected behavior

Telegram provider should load runtime deps from the currently installed build and start normally.

Still need to ship something?

×6

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

Back to top recommendations

TRENDING

openclaw - ✅(Solved) Fix [Bug]: Telegram channel keeps loading stale runtime hash after update/reinstall (Cannot find package 'openclaw' from plugin-runtime-deps) [1 pull requests, 2 comments, 3 participants]