openclaw - 💡(How to fix) Fix perf] 2026.4.26: bundled plugin runtime deps staging burns 85-100% CPU continuously after upgrade [2 comments, 3 participants]

Bug type

Behavior bug (incorrect output/state without crash)

Beta release blocker

No

Summary

After upgrading from 2026.4.21 to 2026.4.26, the gateway process pegs 85-100% CPU immediately after startup and never recovers. Chat becomes unresponsive, WebSocket handshakes time out, and the gateway eventually becomes unreachable.

Environment OpenClaw version: 2026.4.26 (be8c246)

Node: v24.14.1

OS: macOS 26.4.1 (ARM64)

Install method: npm install -g openclaw@latest

Steps to reproduce

npm install -g [email protected]

openclaw gateway --port 5757 --verbose

Observe CPU immediately climbs to 85-100% and stays there

sample <pid> 3 confirms fs.Link / unlinkat / string comparison loop in microtask queue

Compounding issues triggered by the CPU starvation Once the gateway is CPU-starved, several secondary failures cascade:

Stale .openclaw-runtime-mirror.lock: If the gateway is killed or suspended during dep staging, the lock is orphaned. Next startup waits 300s (5 min) per channel before timing out: Timed out waiting for bundled runtime deps lock (waited=300035ms, ownerAge=435608ms)

Bonjour mDNS restart loop: The advertiser gets stuck cycling probing → announcing → watchdog restart every few seconds, adding CPU load

WhatsApp Baileys reconnect storm: WhatsApp 408 timeouts trigger retry loops that queue up against the starved event loop

openclaw-node service reconnect flood: The node service (KeepAlive: true, ThrottleInterval: 1) hammers the gateway with WebSocket reconnects that all time out, further starving the event loop

Expected behavior

The runtime deps staging should:

Run once at install/first-boot, not on every startup

Record a completion marker so subsequent boots skip the staging

Not re-enter the staging loop from the microtask queue

Have a bounded iteration count or yield to the event loop between batches

Actual behavior

macOS sample profiling shows the main thread stuck in a tight microtask loop inside the bundled plugin runtime deps staging system (~/.openclaw/plugin-runtime-deps/openclaw-2026.4.26-b1e85c141c58/):

682 uv__work_done → FSReqPromise → MicrotaskQueue::RunMicrotasks → PromiseFulfillReactionJob → AsyncFunctionAwaitResolveClosure → InterpreterEntryTrampoline (deep JS loop) → fs.Link (hardlink) — 430+ samples → fs.RmSync / unlinkat — 150+ samples → StrictEqual / StringAdd (path comparisons) — 200+ samples

Copy The dist/ mirror directory contains 2789 files and the staging loop re-hardlinks them continuously without reaching a terminal state. The .openclaw-runtime-deps.json status file only contains specs — no completion marker.

Clearing the cache (rm -rf ~/.openclaw/plugin-runtime-deps/openclaw-2026.4.26-*) temporarily drops CPU to ~5% for ~60 seconds, then the loop resumes as the staging rebuilds and re-enters the same hot path.

OpenClaw version

2026.4.26

Operating system

macOS 26.4.1

Install method

npm

Model

gpt-5.4-mini

Provider / routing chain

minimax

Additional provider/model setup details

No response

Logs, screenshots, and evidence

Impact and severity

No response

Additional information

No response