Issue Station
Sign In
Tools hereToolbox

openclaw - 💡(How to fix) Fix [Bug]: 2026.4.27 still consumes ~7-20% idle CPU with event loop blocking up to 35s (mitigated but not fixed from 4.26) [1 comments, 2 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#74728•Fetched 2026-04-30 06:20:38
View on GitHub
Comments
1
Participants
2
Timeline
5
Reactions
3
Author
leo-afk-sudoleo-afk-sudo
Participants
clawsweeper[bot]clawsweeper[bot]leo-afk-sudoleo-afk-sudo
Timeline (top)
closed ×1commented ×1cross-referenced ×1mentioned ×1

2026.4.27 still consumes ~7-20% idle CPU with periodic event loop blocking up to 35s (mitigated but not fixed from 4.26)

v2026.4.26's 100% CPU spin bug (#73647, now duplicate of #73532) was partially mitigated in v2026.4.27. The infinite runtime-deps directory loop is gone, and CPU dropped from ~100% to ~7-20%. However, the diagnostic subsystem continues to fire event_loop_delay liveness warnings, the process CPU never settles below ~7% at idle, and RSS memory drifts upward (from ~400MB to ~1.4GB within ~10 minutes).

For comparison: v2026.4.25 idle CPU ≈ 1%, v2026.4.27 idle CPU ≈ 7-20%.

Root Cause

2026.4.27 still consumes ~7-20% idle CPU with periodic event loop blocking up to 35s (mitigated but not fixed from 4.26)

v2026.4.26's 100% CPU spin bug (#73647, now duplicate of #73532) was partially mitigated in v2026.4.27. The infinite runtime-deps directory loop is gone, and CPU dropped from ~100% to ~7-20%. However, the diagnostic subsystem continues to fire event_loop_delay liveness warnings, the process CPU never settles below ~7% at idle, and RSS memory drifts upward (from ~400MB to ~1.4GB within ~10 minutes).

For comparison: v2026.4.25 idle CPU ≈ 1%, v2026.4.27 idle CPU ≈ 7-20%.

Fix Action

Fix / Workaround

  • #73647 (closed as duplicate of #73532) — original 4.26 100% CPU spin report
  • #73532 (still open) — main tracker: channel runtime / staged runtime deps hot loop
  • PR #74246 (merged in 4.27) — fix(plugins): simplify bundled runtime deps staging
  • #shakkernerd manifest caching (merged in 4.27) — plugin metadata manifest-first loading

Code Example

# 1. Install v2026.4.27
npm install -g openclaw@2026.4.27

# 2. Clean old runtime deps
rm -rf ~/.openclaw/plugin-runtime-deps/

# 3. Start gateway
systemctl --user restart openclaw-gateway.service

# 4. Wait 5 minutes for cold start to settle

# 5. Sample idle CPU over 15 seconds
ps -p $(pgrep -f 'openclaw.*gateway' | head -1) -o %cpu --no-headers
sleep 5
ps -p $(pgrep -f 'openclaw.*gateway' | head -1) -o %cpu --no-headers
sleep 5
ps -p $(pgrep -f 'openclaw.*gateway' | head -1) -o %cpu --no-headers

# 6. Check liveness diagnostics
grep 'liveness warning' /tmp/openclaw/openclaw-$(date +%F).log | tail -3
RAW_BUFFERClick to expand / collapse

Bug type

Regression (worked before, now fails)

Beta release blocker

No

Summary

2026.4.27 still consumes ~7-20% idle CPU with periodic event loop blocking up to 35s (mitigated but not fixed from 4.26)

v2026.4.26's 100% CPU spin bug (#73647, now duplicate of #73532) was partially mitigated in v2026.4.27. The infinite runtime-deps directory loop is gone, and CPU dropped from ~100% to ~7-20%. However, the diagnostic subsystem continues to fire event_loop_delay liveness warnings, the process CPU never settles below ~7% at idle, and RSS memory drifts upward (from ~400MB to ~1.4GB within ~10 minutes).

For comparison: v2026.4.25 idle CPU ≈ 1%, v2026.4.27 idle CPU ≈ 7-20%.

Environment

  • OpenClaw: 2026.4.27 (commit cbc2ba0)
  • Node: v22.22.2
  • OS: Ubuntu 26.04 LTS (noble)
  • Kernel: Linux 7.0.0-14-generic (x64)
  • Install: npm global (/home/claw/.npm-global/bin/openclaw)
  • Service: systemd --user service (loopback, port 18789)
  • CPU: 4 cores, Intel (no GPU)
  • RAM: 15 GB total
  • Plugins (9): acpx, bonjour, browser, device-pair, feishu (x5 bots), memory-core, phone-control, qqbot, talk-voice

Steps to reproduce

# 1. Install v2026.4.27
npm install -g [email protected]

# 2. Clean old runtime deps
rm -rf ~/.openclaw/plugin-runtime-deps/

# 3. Start gateway
systemctl --user restart openclaw-gateway.service

# 4. Wait 5 minutes for cold start to settle

# 5. Sample idle CPU over 15 seconds
ps -p $(pgrep -f 'openclaw.*gateway' | head -1) -o %cpu --no-headers
sleep 5
ps -p $(pgrep -f 'openclaw.*gateway' | head -1) -o %cpu --no-headers
sleep 5
ps -p $(pgrep -f 'openclaw.*gateway' | head -1) -o %cpu --no-headers

# 6. Check liveness diagnostics
grep 'liveness warning' /tmp/openclaw/openclaw-$(date +%F).log | tail -3

Observed behavior

Idle CPU samples (3 samples, 5s apart, ~6 min after cold start)

SampleProcess CPU
Sample 119.2%
Sample 219.6%
Sample 320.7%

After fresh restart (4 min uptime):

MetricValue
Process CPU7.6%
System load avg0.06 / 0.24 / 0.32
Process stateS (sleeping)
Threads11
RSS~408 MB (fresh)

Liveness warning time series (same session, ~12 min window)

Timestamp (relative)eventLoopDelayMaxMscpuCoreRatioContext
+3 min3,489 ms0.331cold-start staging
+5 min82,946 ms0.521peak
+7 min5,322 ms0.232
+10 min35,165 ms0.375
+1 min (after restart)3,368 ms0.305clean restart

QQBot reconnect pattern

WebSocket connected: 4 times in 13 minutes (~every 2-3 min).

Runtime deps

  • Only 1 directory: openclaw-2026.4.27-c6d8e67505cb
  • File count: 29,819 (normal — no infinite loop)

Expected behavior

Idle gateway should consume < 1-2% CPU. Event loop delay should remain under 100ms at idle.

Actual behavior

  • Idle CPU stabilizes at 7-20% (roughly half a core continuously busy)
  • Event loop spikes to 35-83 seconds periodically
  • RSS grows from 400MB → ~1.4GB within ~10 minutes
  • Contrast: v2026.4.25 idle CPU < 1%, no event loop delay spikes

OpenClaw version

2026.4.26 (be8c246) → 2026.4.27 (cbc2ba0) — both exhibit this behavior

Operating system

Ubuntu 26.04 LTS, Linux 7.0.0-14-generic x86_64

Install method

npm global install, systemd --user service

Model

MiniMax-M2.7 (via MiniMax anthropic-messages API), Doubao Seed 1.8 (via 火山引擎 openai-completions API)

Provider / routing chain

OpenClaw gateway loopback → MiniMax (api.minimaxi.com/anthropic) + 火山引擎 (ark.cn-beijing.volces.com/api/v3)

Related issues

  • #73647 (closed as duplicate of #73532) — original 4.26 100% CPU spin report
  • #73532 (still open) — main tracker: channel runtime / staged runtime deps hot loop
  • PR #74246 (merged in 4.27) — fix(plugins): simplify bundled runtime deps staging
  • #shakkernerd manifest caching (merged in 4.27) — plugin metadata manifest-first loading

What v2026.4.27 fixes vs what remains

Issuev4.26v4.27Fix
100% CPU spin❌⚠️ Reduced to 7-20%PR #74246
Infinite runtime-deps loop❌✅ FixedPR #74246
Repeated manifest parsing❌✅ Cachedmanifest-first changes
Event loop blocking (35-83s)❌❌ Still present#73532 not fixed
RSS memory growth❌❌ Still present#73532 not fixed
QQBot periodic disconnect❌❌ Still presentpossibly related

Impact and severity

Medium. Production gateways consume ~20% CPU continuously at idle. On lower-end hardware (4 cores, 15GB RAM as tested), this is noticeable. RSS growth over time risks OOM on longer-running instances.

Additional information

First observed by @mattmcintyre on Telegram-only config (#73647). Tested here with 9 plugins (feishu x5, qqbot, acpx, bonjour, browser, device-pair, memory-core, phone-control, talk-voice). The QQBot periodic WebSocket reconnection (~every 2-3 minutes) may be a downstream symptom of the same event loop blocking rather than a separate issue.

extent analysis

TL;DR

The issue can be mitigated by investigating and addressing the event loop blocking, which is likely caused by a plugin or dependency issue, and optimizing the runtime dependencies staging.

Guidance

  1. Investigate event loop blocking: Analyze the event_loop_delay liveness warnings and the periodic spikes in event loop delay to identify the root cause.
  2. Review plugin dependencies: Examine the plugins used, especially qqbot and feishu, to determine if they are contributing to the event loop blocking or RSS memory growth.
  3. Optimize runtime dependencies staging: Build upon the fixes introduced in PR #74246 to further simplify and optimize the runtime dependencies staging process.
  4. Monitor RSS memory growth: Keep a close eye on the RSS memory usage to prevent out-of-memory issues and identify potential memory leaks.
  5. Test with minimal plugins: Try running the gateway with a minimal set of plugins to isolate the issue and determine if it's plugin-specific.

Example

No specific code snippet can be provided without further investigation, but the event_loop_delay warnings and RSS memory growth should be monitored and analyzed to identify the root cause.

Notes

The issue is complex and may require a combination of fixes. The provided guidance is a starting point for investigation and mitigation. Further analysis and testing are necessary to fully resolve the issue.

Recommendation

Apply workaround: Investigate and address the event loop blocking, and optimize the runtime dependencies staging, as these are likely the primary causes of the issue.

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

Idle gateway should consume < 1-2% CPU. Event loop delay should remain under 100ms at idle.

#api#response parsing#generation error#database connection#vector store

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 - 💡(How to fix) Fix [Bug]: 2026.4.27 still consumes ~7-20% idle CPU with event loop blocking up to 35s (mitigated but not fixed from 4.26) [1 comments, 2 participants]