Issue Station
Sign In
Tools hereToolbox

openclaw - ✅(Solved) Fix v2026.4.5 regression: worker processes load all plugins, causing CPU saturation [1 pull requests, 1 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#62051•Fetched 2026-04-08 03:09:42
View on GitHub
Comments
0
Participants
1
Timeline
6
Reactions
2
Author
bryangauvinbryangauvin
Participants
bryangauvinbryangauvin
Timeline (top)
cross-referenced ×4subscribed ×2

Upgrading from v2026.4.2 to v2026.4.5 causes every worker child process (openclaw, openclaw-cron, openclaw-approvals) to independently register all plugins (BlockRun, partner tools, etc.), creating massive CPU overhead. On a Mac Mini with 8-10 cores, the gateway spawns 87+ child processes each consuming 20-50% CPU, saturating all cores and rendering the system unusable.

Root Cause

Upgrading from v2026.4.2 to v2026.4.5 causes every worker child process (openclaw, openclaw-cron, openclaw-approvals) to independently register all plugins (BlockRun, partner tools, etc.), creating massive CPU overhead. On a Mac Mini with 8-10 cores, the gateway spawns 87+ child processes each consuming 20-50% CPU, saturating all cores and rendering the system unusable.

Fix Action

Workaround

Downgrade to v2026.4.2:

npm install -g [email protected]
launchctl kickstart -k gui/$(id -u)/ai.openclaw.gateway

PR fix notes

PR #65497: fix: reuse gateway provider registry in worker sessions (#62051)

Description (problem / solution / changelog)

Problem

resolvePluginProviders() is called on every LLM turn for every agent session. Each session has a unique workspaceDir (e.g., workspace-agent1, workspace-agent2), and the plugin registry cache key includes workspaceDir. This means the gateway's active registry (loaded once at startup) never cache-hits for sessions with different workspace dirs, triggering a full loadOpenClawPlugins() call on every turn — disk scanning, manifest parsing, jiti module loading.

On a system with 6+ agents and multiple concurrent sessions, this creates dozens of redundant plugin initialization cycles, saturating CPU and memory. See #62051 for the original report (87+ child processes, 888% CPU on 8-core machine).

Root Cause

The registry cache key includes workspaceDir, but provider plugins are workspace-independent — their registration output does not vary with the caller's workspace dir or agent context. The cache miss is a false negative.

Fix

Add tryResolveProvidersFromActiveRegistry() fast path in resolvePluginProviders(): when the gateway's active plugin registry already contains all requested provider plugin IDs, return them directly instead of triggering a fresh loadOpenClawPlugins() call.

Why only this path needs fixing

Call pathStatus
resolvePluginProviders (providers.runtime.ts)❌ workspace-dir mismatch → reload every turn → this fix
resolvePluginTools (tools.ts)✅ Has allowGatewaySubagentBinding fast path
resolvePluginCapabilityProviders (capability-provider-runtime.ts)✅ Returns active registry by default
ensureMemoryRuntime (memory-runtime.ts)✅ One-time init with short-circuit
resolveRuntimeWebProviders (web-provider-runtime-shared.ts)⚠️ Can miss but has snapshot cache + lower frequency

Tests

  • Added 2 tests in providers.test.ts covering fast path hit and fallback
  • All 4 related test files pass: providers.test.ts (48/48), provider-runtime.test.ts (18/18), capability-provider-runtime.test.ts (12/12), web-provider-runtime-shared.test.ts (3/3)

Impact

Eliminates per-turn plugin reload for multi-agent setups. Expected to reduce CPU from ~888% to baseline (~2%) and process count from 87+ to ~8 on the reporter's configuration.

Fixes #62051

Changed files

  • src/plugins/providers.runtime.ts (modified, +25/-0)
  • src/plugins/providers.test.ts (modified, +46/-0)

Code Example

[plugins] BlockRun provider registered (55+ models via x402)
[plugins] Registered 1 partner tool(s): blockrun_x_users_lookup
[plugins] Not in gateway mode — proxy will start when gateway runs

---

npm install -g openclaw@2026.4.2
launchctl kickstart -k gui/$(id -u)/ai.openclaw.gateway
RAW_BUFFERClick to expand / collapse

Bug Report: v2026.4.5 Plugin Loading Regression

Summary

Upgrading from v2026.4.2 to v2026.4.5 causes every worker child process (openclaw, openclaw-cron, openclaw-approvals) to independently register all plugins (BlockRun, partner tools, etc.), creating massive CPU overhead. On a Mac Mini with 8-10 cores, the gateway spawns 87+ child processes each consuming 20-50% CPU, saturating all cores and rendering the system unusable.

Environment

  • Platform: macOS arm64, Mac Mini
  • Node: v22.22.1
  • OpenClaw: v2026.4.5 (3e72c03) — regressed from v2026.4.2 (d74a122)
  • Config: 12 agents, 19 enabled cron jobs, Discord + iMessage channels

Steps to Reproduce

  1. Install [email protected] globally
  2. Start gateway via launchd with existing v2026.4.2 config
  3. Wait 2-3 minutes for plugins to initialize

Expected Behavior

Plugin registration happens once in the gateway process. Worker processes inherit the registered providers without re-initializing.

Actual Behavior

Every child worker process independently loads and registers all plugins:

[plugins] BlockRun provider registered (55+ models via x402)
[plugins] Registered 1 partner tool(s): blockrun_x_users_lookup
[plugins] Not in gateway mode — proxy will start when gateway runs

This message repeats for each of 87+ spawned worker processes. Observable effects:

  • 103 total openclaw processes (vs ~8 on v2026.4.2)
  • 888% total CPU across all processes (vs ~2% on v2026.4.2)
  • Load average 17.77 on 8-10 core machine
  • Paperclip API response time >2 minutes (vs 10ms on v2026.4.2)
  • fseventsd also spikes to 27% CPU from filesystem watchers across all processes
  • Log shows infinite loop of "BlockRun provider registered" / "Not in gateway mode" messages

Additional Observations

  • The dingtalk extension also fails repeatedly on v2026.4.5 with: Cannot find module '/opt/homebrew/lib/node_modules/openclaw/dist/plugin-sdk/root-alias.cjs/telegram-core' — the plugin-sdk module paths appear to have changed.
  • Config keys added in v2026.4.5 (plugins.entries.memory-core.config.dreaming, agents.defaults.memorySearch) cause v2026.4.2 to reject config on downgrade: "must NOT have additional properties"

Workaround

Downgrade to v2026.4.2:

npm install -g [email protected]
launchctl kickstart -k gui/$(id -u)/ai.openclaw.gateway

Suggested Fix

Plugin registration should be gated to the gateway process only. Worker/child processes should either:

  1. Skip plugin initialization entirely (inherit from parent)
  2. Check process.env.OPENCLAW_SERVICE_KIND === 'gateway' before registering providers
  3. Use a shared plugin registry instead of per-process initialization

extent analysis

TL;DR

Downgrade to [email protected] or modify the plugin registration to only occur in the gateway process.

Guidance

  • Verify that the issue is resolved by downgrading to [email protected] using the provided workaround command: npm install -g [email protected] and launchctl kickstart -k gui/$(id -u)/ai.openclaw.gateway.
  • To fix the issue in v2026.4.5, modify the plugin registration code to check process.env.OPENCLAW_SERVICE_KIND === 'gateway' before registering providers.
  • Consider using a shared plugin registry to avoid per-process initialization and reduce CPU overhead.
  • Review the config keys added in v2026.4.5 and ensure they are compatible with the desired version of openclaw.

Example

if (process.env.OPENCLAW_SERVICE_KIND === 'gateway') {
  // Register plugins here
  registerBlockRunProvider();
  registerPartnerTools();
}

Notes

The issue appears to be specific to v2026.4.5 and is caused by the changed plugin registration behavior. Downgrading to v2026.4.2 is a temporary workaround, but a permanent fix requires modifying the plugin registration code.

Recommendation

Apply the workaround by downgrading to [email protected] until a permanent fix is available, as it is a known stable version that does not exhibit the plugin registration 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…
#api#orchestration issue#cache issue#memory leak#API versioning

Still need to ship something?

×6

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

Back to top recommendations

TRENDING