Cold-Load Bottleneck in openclaw tools --help / tools effective / status --usage (2026.4.23)

Summary

Even after pruning disabled bundled plugins and clearing the runtime-deps cache, openclaw tools --help, openclaw tools effective, and openclaw status --usage still time out after ~12 seconds. The bottleneck is not the discovery phase itself, but the plugin registry load/tool resolution path.

Environment

• OpenClaw Version: 2026.4.23 (a979721)
• Runtime: Docker container on Synology NAS
• Config: plugins.entries.* explicitly disabled for ~96 plugins, only 7 kept enabled (openai, browser, memory-core, whatsapp, codex, acpx, active-memory)

Reproduction Steps

1. Disable plugins in config (only 7 kept enabled)
2. Physically move bundled plugin dirs to remove from discovery:

   sudo mv /usr/local/lib/node_modules/openclaw/dist/extensions/\{anthropic,moonshot,…\} \
     /usr/local/lib/node_modules/openclaw/dist/extensions-disabled-2026-04-28/

3. Clear runtime-deps cache:

   sudo rm -rf /home/node/.openclaw/plugin-runtime-deps/*

4. Restart OpenClaw:

   openclaw gateway restart

5. Measure cold-load times:

   time openclaw tools --help
   time openclaw tools effective
   time openclaw status --usage
   time openclaw status --json  # control (fast)

Observed Behavior

Internal measurements:

• Discovery: 7 candidates ✅
• Registry load: ~9 s (down from ~18 s, but still high)
• Tools resolution: ~12 s timeout (no improvement)

Expected Behavior

After disabling 96/102 plugins and clearing caches, cold-load times should be near-instant (<2 s) for CLI commands, especially tools --help.

Root Cause Analysis

The bottleneck is not the discoverOpenClawPlugins() call itself (now only 7 candidates). Instead, the tools and effective commands force a full runtime plugin registry load via resolveRuntimePluginRegistry(), which:

1. Iterates all discovery candidates (even disabled ones) in loadPluginManifestRegistry()
2. Loads manifests for each candidate
3. Resolves enable state after the manifest loop (resolveEffectiveEnableState)

Key code paths:

• tools-BDzuLs8q.js:33-45 → resolvePluginTools() → resolveRuntimePluginRegistry()
• loader-DeOtDUYt.js:2687-2700 → discoverOpenClawPlugins() + loadPluginManifestRegistry() (runs before enable filter)
• manifest-registry-D5n47dku.js:574-600 → Manifest loading loop over all candidates
• loader-DeOtDUYt.js:2738-2788 → Enable check happens after discovery & manifest load

Impact

• CLI commands (tools --help, tools effective, status --usage) are unusably slow
• Active users perceive hangs on every fresh CLI invocation
• Workaround (pruning config) only partially helps; physical plugin removal still leaves manifest-loading overhead

Proposed Solutions

1. Early pruning: Filter enabled: false plugin IDs before discoverOpenClawPlugins() or loadPluginManifestRegistry() to avoid work entirely.
2. Separate fast path: Provide a lightweight tools --help mode that skips full registry load and uses cached tool metadata.
3. Lazy manifest loading: Only load plugin manifests when enabled: true (or when explicitly requested for validation).

Additional Context

• Related issue patterns: #72365 ("Control UI unresponsive during chat runs"), #64004 ("slow CLI"), #72384, #72383 (plugin SDK changes)
• This is reproducible across sessions and persists after clearing all caches and pruning config down to 7 plugins.

Reported by: @oromeis (OpenClaw instance on Docker/Synology) Logs available on request.