OpenClaw bug report — bundled-deps installer cascade in v2026.4.24

Suggested title: [v2026.4.24] Plugin bundled-deps installer thrashes — every plugin reinstalls every ~5 min, hangs gateway

Suggested labels: bug, regression, plugins

Summary

In v2026.4.24, the plugin stageRuntimeDependencies installer enters a self-perpetuating reinstall cascade. Each plugin's npm install causes other plugins' bundled deps to become "missing" again, which triggers them to reinstall, which causes the next plugin's deps to go missing, and so on. The cycle repeats roughly every ~6 minutes indefinitely.

While each install runs (8–15s), the gateway's JS event loop is blocked in module resolution, so:

• Gateway HTTP returns no response (TCP backlog fills with CLOSE-WAIT).
• Telegram channel polling stalls; messages received but never processed.
• Agent calls hang and trigger "stuck session" stall recovery, which (we suspect) reloads plugins and accelerates the cascade.

End-user symptom: agent silent in Telegram, browser channel intermittently unreachable.

Environment

• OpenClaw: v2026.4.24 (npm global install)
• Node: v22.22.2 (NVM)
• OS: Ubuntu 24.04 LTS
• Multi-tenant deployment: 5 instances. Each tenant's ~/openclaw/node_modules is a symlink to a shared /opt/craybot/openclaw-template/node_modules. Plus a self-symlink node_modules/openclaw -> .. (workaround for the upstream self-import bug, issue #71484).
• Plugins enabled in this trace: browser, telegram, openai (+openclaw-weixin declared but skipped due to missing channelConfigs metadata).
• Disabled for this test: claude-mem — to rule out our memory plugin as the trigger.

Reproduction trace (lawong tenant, claude-mem disabled)

19:43:18  systemd starts service
19:43:32  [plugins] browser  staging  (7 missing, 23 install specs)  ← 23 = union of ALL plugin deps
19:43:47  [plugins] browser  installed in 14456ms
19:43:48  [plugins] telegram staging  (5 missing, 23 install specs)
19:43:56  [plugins] telegram installed in 8005ms
19:44:06  [gateway] ready (2 plugins: browser, telegram; 40.0s)
19:44:06  [gateway] starting channels and sidecars...

           ← gateway HTTP becomes UNRESPONSIVE here, log goes silent for ~5:48 ←

19:49:54  [plugins] browser  staging  (7 missing, 23 install specs)  ← SAME 7 it just installed
19:50:04  [plugins] browser  installed in 9110ms
19:50:04  [plugins] openai   staging  (2 missing, 23 install specs)
19:50:14  [plugins] openai   installed in 10456ms
19:50:15  [plugins] telegram staging  (5 missing, 23 install specs)  ← SAME 5 it installed at 19:43
19:50:26  [plugins] telegram installed in 11356ms

Pattern repeats. Cascade also observed before disabling claude-mem, with claude-mem joining the rotation (claude-mem reloads at 19:29:16, 19:36:25, 19:37:46 in an earlier session).

Smoking gun

Every plugin's stage line shows the same pattern:

[plugins] <name> staging bundled runtime deps (N missing, 23 install specs): <only N specs listed>

• N = the deps declared in that plugin's package.json.
• 23 install specs = the union of every enabled plugin/extension's bundled deps.

pstree of the gateway during a stage:

openclaw-gatewa(943287)─┬─npm install @anthropic-ai/[email protected] @anthropic-ai/vertex-sdk@^0.16.0 \
                       │       @aws-sdk/[email protected] @aws-sdk/[email protected] \
                       │       @aws-sdk/[email protected] @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/[email protected] \
                       │       @mariozechner/[email protected] @mariozechner/[email protected] \
                       │       @modelcontextprotocol/[email protected] ajv@^8.18.0 commander@^14.0.3 \
                       │       express@^5.2.1 grammy@^1.42.0 [email protected] [email protected] \
                       │       [email protected] ws@^8.20.0 zod@^4.3.6

So a single plugin's stage runs npm install with the union of every plugin's specs as positional args, in the shared node_modules (which is a symlink chain due to OpenClaw's bundled deps strategy). Modern npm with positional args + --save-default behavior prunes extraneous packages, removing whatever the previous plugin installed.

Net effect: each plugin's install undoes the previous one. The "(N missing, 23 install specs)" wording suggests the installer intends to skip already-present deps but still passes all 23 to npm install, which is what triggers the prune.

Why disabling claude-mem did not help

We initially suspected claude-mem was the trigger because its [claude-mem] reload log lines appeared adjacent to the stuck-session stall recovery. After disabling claude-mem entirely (plugins.entries.claude-mem.enabled = false, removed from plugins.allow, cleared plugins.slots.memory), the cascade still occurred (trace above). claude-mem was an innocent participant, not the cause.

Gateway HTTP behavior during install windows

During each plugin's npm install run:

• Listener 127.0.0.1:18790 keeps LISTENing.
• New connections accepted at TCP layer.
• 6+ inbound connections accumulate in CLOSE-WAIT with 79–115 bytes pending in Recv-Q.
• curl -m 5 http://127.0.0.1:18790/ times out — server reads the request bytes but never writes a response.
• strace of main thread shows it deep in node_modules/openai/auth/, node_modules/openai/_vendor/... directory walks (Node ESM resolution during agent runtime startup).

So the JS event loop is starved by synchronous module resolution work running on the main thread.

Suggested fixes (rank by impact)

1. Don't pass the union as positional args. Run npm install with no positional args (relying on package.json) per plugin, OR with --no-save --no-package-lock so it doesn't rewrite/prune. Even better: use npm ci against a per-plugin lockfile.
2. Coalesce installs. If multiple plugins share a node_modules, install all bundled deps once at gateway startup before any plugin reports "ready", instead of doing it lazily per-plugin.
3. Cache by content hash. Skip the install entirely if the resolved spec set matches a known-good marker file in node_modules/.openclaw-bundled-state.json.
4. Background the install off the JS main thread. Even if the cascade is unavoidable as a transition fix, the event-loop starvation is a separate problem — the gateway should keep serving HTTP / polling Telegram during installs.

Workarounds we tried

Asks

1. Confirm whether the union-of-specs positional install is intended or a regression.
2. Is there a version of OpenClaw we should pin to that doesn't ship this installer behavior? (Some of our other tenants on v2026.4.22 also report the symptom, so the regression may predate v2026.4.24.)
3. If a fix lands quickly, can it be cherry-picked to a v2026.4.x patch release rather than waiting for v2026.5?

We have full systemd journal logs and can reproduce on demand. Happy to run any traces or patches.