Summary

On OpenClaw 2026.5.7, plain non-deep openclaw status can take ~20s even when openclaw gateway status returns in ~1.3s. The gateway is not the bottleneck; the CLI status process spends the time repeatedly loading plugin/model metadata while rendering the session summary.

This is related to #79129, but that issue is about status --json and is currently closed. This report is the plain text/default openclaw status path.

Environment

• OpenClaw: 2026.5.7 (eeef486)
• Install method: npm global-style package
• OS: Linux/WSL2 x64
• Gateway: local gateway already running and reachable

Repro

/usr/bin/time -p openclaw status >/dev/null
/usr/bin/time -p openclaw gateway status >/dev/null
/usr/bin/time -p openclaw status --json >/dev/null
/usr/bin/time -p openclaw status --timeout 1 >/dev/null

Observed

Before local patch:

openclaw status              real 20.32
openclaw gateway status      real 1.29
openclaw status --json       ~20s in this environment
openclaw status --timeout 1  ~20s

CPU profiling showed the main thread mostly waiting/idle, while the hot inclusive path was repeated plugin metadata/model normalization work:

• ~86% inclusive under loadPluginMetadataSnapshot
• ~71% through model-ref normalization / manifest model-id normalization
• ~14% through isCliProvider / setup CLI backend discovery

strace also showed egress to Cloudflare during non-deep status, consistent with plugin/model probing or metadata work running in the default status path.

Root cause found locally

The slow path appears to be in the status session summary/model/runtime labeling code:

• src/commands/status.summary.ts
  • Builds per-agent session rows, then rebuilds all session rows again for the global recent list.
• src/commands/status.summary.runtime.ts
  • Status-only parsing already disables plugin normalization, but persisted/configured model parsing still allows manifest model-id normalization.
  • Runtime labeling calls into CLI-provider detection for each row.
• src/agents/model-selection.ts
  • resolvePersistedOverrideModelRef, resolvePersistedModelRef, and resolvePersistedSelectedModelRef expose allowPluginNormalization but not allowManifestNormalization, so status callers cannot keep persisted model parsing on the cheap path.
• src/status/agent-runtime-label.ts
  • Calls isCliProvider(provider, config) repeatedly without a status-scope cache.

Local proof of fix

A small source patch that:

1. threads optional allowManifestNormalization?: boolean through the persisted model resolvers,
2. passes allowManifestNormalization: false from status summary runtime,
3. caches isCliProvider results per OpenClawConfig object for status rendering,
4. reuses the per-agent buildSessionRows results instead of rebuilding every store for allSessions,

reduced the installed stable runtime from:

before: openclaw status          real 20.32
before: openclaw gateway status  real 1.29

to:

after:  openclaw status          real 2.27
after:  openclaw gateway status  real 1.27

A source checkout of v2026.5.7 with the same patch built successfully and produced:

node ./openclaw.mjs status          real 3.60
node ./openclaw.mjs gateway status  real 1.43

Targeted tests added locally passed:

pnpm exec vitest run \
  src/commands/status.summary.test.ts \
  src/commands/status.summary.runtime.test.ts \
  src/status/status-message.test.ts

# Test Files 3 passed
# Tests 21 passed

Suggested fix

Keep the default/non-deep status command on a shallow read-only path:

• status summary model parsing should disable both plugin and manifest normalization;
• persisted model resolver APIs should pass allowManifestNormalization through where callers need cheap parsing;
• isCliProvider should be cached for the duration of a status summary render, or injected as a cached resolver;
• status summary should not rebuild session rows for stores it already read for byAgent.

Expected behavior

openclaw status should be near openclaw gateway status plus bounded local session-summary formatting, not ~20s of repeated plugin metadata discovery. Expensive plugin/channel/model compatibility probes should stay behind --deep, --all, or explicit diagnostic commands.

Related

• Repeated plugin metadata rescans make openclaw status --json take ~27s on 2026.5.7 #79129 — similar status metadata rescan issue for openclaw status --json, but this report is the default text/non-deep status summary path.
• Broader plugin metadata/index performance issues such as [Perf] Cascade: loadInstalledPluginIndex re-walks plugin manifests sync per RPC, blocks event loop 5-30 s under concurrent load #80345 may share underlying discovery costs, but this status path can be fixed narrowly without adding broad process-global caches.