Summary

openclaw status --json is still taking ~27s on a live 2026.5.7 install, and the slow path appears to repeatedly rescan bundled plugin metadata/manifests. This looks related to the broader plugin metadata snapshot reuse / installed-index issues, but I did not find an existing open issue that specifically covers the CLI status --json path on current releases.

Environment

• OpenClaw: 2026.5.7 (eeef486)
• Node: v25.6.0
• OS: Linux x64 (6.8.0-110-generic)
• Install path: global npm-style install under ~/.nvm/versions/node/v25.6.0/lib/node_modules/openclaw

Repro

/usr/bin/time -f 'elapsed=%e' \
  openclaw status --timeout 1000 --json >/tmp/openclaw-status.json

Observed

The command completed successfully, but took 27s:

elapsed=27.19

The JSON payload was valid and showed the local gateway was reachable:

{
  "runtimeVersion": "2026.5.7",
  "gateway": {
    "mode": "local",
    "reachable": true,
    "connectLatencyMs": 132
  }
}

To see what the process was doing, I ran a file-syscall trace of the same command. The trace itself was killed after 90s because strace overhead made the command exceed the outer timeout, so these numbers are from an incomplete trace. Even so, it produced a 78 MiB / 375,908-line trace with:

openclaw.plugin.json references: 59,078
package.json references:          17,768
dist/extensions references:      150,074
plugins/installs.json refs:          105
unique bundled plugin manifests:      97

Example unique manifest paths in the partial trace:

~/.nvm/versions/node/v25.6.0/lib/node_modules/openclaw/dist/extensions/active-memory/openclaw.plugin.json
~/.nvm/versions/node/v25.6.0/lib/node_modules/openclaw/dist/extensions/alibaba/openclaw.plugin.json
~/.nvm/versions/node/v25.6.0/lib/node_modules/openclaw/dist/extensions/amazon-bedrock/openclaw.plugin.json
~/.nvm/versions/node/v25.6.0/lib/node_modules/openclaw/dist/extensions/anthropic/openclaw.plugin.json
~/.nvm/versions/node/v25.6.0/lib/node_modules/openclaw/dist/extensions/browser/openclaw.plugin.json

That seems far above a single bounded manifest read pass for a status command, and matches the visible symptom: status --json spends a long time before producing output even with --timeout 1000.

Related issues I found

• Gateway re-scans plugin metadata during model normalization #78461 covers gateway-side metadata snapshot misses during model normalization, but not the CLI openclaw status --json path.
• CLI openclaw status text mode extremely slow (~20-30s) due to cache: false hardcoded in manifest registry loader #73291 covered openclaw status text mode slowness on 2026.4.25 and is closed; that issue also said JSON mode was faster (~8s). This repro is JSON mode on 2026.5.7.
• loadInstalledPluginIndexInstallRecordsSync runs on every resolvePluginTools call, including LRU cache hits #77348 and Gateway sync-FS plugin discovery blocks event loop on every channels.status / channel restart #78100 cover related sync installed-index / plugin discovery hot paths, but not this specific CLI status repro.

Expected

openclaw status --json --timeout 1000 should avoid repeated plugin registry/manifest discovery, reuse an already-valid installed plugin index / metadata snapshot where possible, and complete in a small bounded time (ideally a few seconds or less for a local reachable gateway).

Notes / possible direction

The status path likely needs the same kind of metadata/index reuse guardrails as the gateway model-normalization fix: avoid calling plugin registry snapshot / manifest metadata loaders multiple times inside one status invocation, and ensure any compatibility/reporting scans are behind --all/--deep or use a cached installed-index view.