openclaw - 💡(How to fix) Fix [perf/bug] openclaw status: slow plugin scan, missing channels, security audit CLI hang [1 comments, 2 participants]

Summary

Three related issues in openclaw status and openclaw security audit CLI on v2026.4.26, all stemming from synchronous per-plugin metadata loading at CLI startup.

Environment: Linux VPS (1 vCPU, limited disk I/O), 118 bundled plugins, Node.js v22.22.0, OpenClaw v2026.4.26.

Bug 1: openclaw status Channels table missing Discord/Telegram

Severity: Medium — channels are running but not shown in the primary status output.

buildChannelsTable() in status.scan.runtime-*.js calls:

listReadOnlyChannelPluginsForConfig(cfg, {
  activationSourceConfig: sourceConfig,
  includeSetupRuntimeFallback: false   // <-- this causes the miss
})

With includeSetupRuntimeFallback: false, only feishu resolves. With true, discord, feishu, and telegram all resolve correctly. Meanwhile openclaw channels status (which uses Gateway runtime data) shows all three connected and healthy.

Expected: openclaw status Channels table should show all configured and running channels.

Suggested fix: Use includeSetupRuntimeFallback: true, or populate the Channels table from the Gateway channels.status RPC result that collectStatusScanOverview already fetches.

Bug 2: buildPluginCompatibilitySnapshotNotices has O(N x loadContext) performance

Severity: High on low-I/O machines — makes openclaw status unusable.

Profiling shows buildPluginCompatibilitySnapshotNotices takes ~92s with 118 bundled plugins. Each per-plugin buildPluginInspectReport call re-invokes resolvePluginRuntimeLoadContext, which re-reads the full manifest registry from disk (~0.75s per plugin on this VPS).

Breakdown:

For comparison, openclaw status --json (which skips plugin compatibility and channel summary) completes in ~10s.

Suggested fix: Call resolvePluginRuntimeLoadContext once and pass the result to all N inspect calls, or cache the manifest registry across the scan.

Bug 3: openclaw security audit CLI effectively hangs on machines with many plugins

Severity: High — the command never completes within a reasonable timeout.

runSecurityAudit() itself completes in ~6s. resolveCommandSecretRefsViaGateway returns in <2ms (no configured secret refs). But the full CLI path via entry.js triggers synchronous plugin metadata I/O during registerCoreCliByName that takes >50s on this machine (strace confirms sequential reads of openclaw.plugin.json + package.json for all 118 plugin directories).

Calling runCli() directly from a Node script (bypassing entry.js) completes in ~18s. The difference is the additional plugin metadata scan triggered by the entry.js code path.

Workaround: None found for the CLI; direct runSecurityAudit() invocation works.

Suggested fix: For builtin commands like security audit, skip or defer the full plugin metadata scan; or make the plugin scan asynchronous/parallel instead of synchronous sequential disk reads.

Reproduction

# Bug 1: Channels table
openclaw status  # Only shows feishu, missing discord/telegram
openclaw channels status  # Shows all three correctly

# Bug 2: Slow status
time openclaw status  # ~77-133s depending on version
time openclaw status --json  # ~10s (fast path skips plugin scan)

# Bug 3: Security audit hang
timeout 60s openclaw security audit --json  # Times out, 0 bytes stdout

System info

• OpenClaw v2026.4.26
• Node.js v22.22.0
• Linux 5.15.0, 1 vCPU VPS
• 118 bundled plugins, 3 channel plugins (discord, telegram, feishu)