Summary

• Problem: openclaw status --json --timeout 1000 could take about 27s because the lean JSON path still used manifest-backed configured-channel policy.
• Why it matters: a read-only status command should not repeatedly scan bundled plugin metadata before returning machine-readable health output.
• What changed: lean JSON status now uses cheap channel config/env presence detection for the cold-start boolean and skips manifest-backed channel discovery.
• What did NOT change (scope boundary): text status, status --all, channel detail rendering, plugin manifest policy, and plugin activation semantics are unchanged.

Change Type (select all)

• Bug fix
• Feature
• Refactor required for the fix
• Docs
• Security hardening
• Chore/infra

Scope (select all touched areas)

• Gateway / orchestration
• Skills / tool execution
• Auth / tokens
• Memory / storage
• Integrations
• API / contracts
• UI / DX
• CI/CD / infra

Linked Issue/PR

• Closes Repeated plugin metadata rescans make openclaw status --json take ~27s on 2026.5.7 #79129
• This PR fixes a bug or regression

Real behavior proof (required for external PRs)

• Behavior or issue addressed: openclaw status --json --timeout 1000 should stay on the lean read-only path and return promptly instead of spending tens of seconds in repeated plugin metadata discovery.
• Real environment tested: macOS 26.4.1 arm64, Node from the local OpenClaw dev checkout, branch issue-79129 at e7a18379177c5293e75bdea92886f03f63da358d, built dist/entry.js invoked directly to avoid source-launcher rebuild timing noise.
• Exact steps or command run after this patch: /usr/bin/time -p node dist/entry.js status --timeout 1000 --json
• Evidence after fix (screenshot, recording, terminal capture, console output, redacted runtime log, linked artifact, or copied live output):

$ /usr/bin/time -p node dist/entry.js status --timeout 1000 --json
[tasks/registry] Failed to restore task registry
{
  "runtimeVersion": "2026.5.6",
  "update": {
    "git": {
      "sha": "e7a18379177c5293e75bdea92886f03f63da358d",
      "branch": "issue-79129",
      "dirty": false
    }
  },
  "memory": null,
  "gateway": {
    "mode": "local",
    "reachable": false,
    "error": "connect EPERM 127.0.0.1:18789 - Local (0.0.0.0:0)"
  },
  "secretDiagnostics": []
}
real 2.06
user 1.97
sys 0.80

• Observed result after fix: the real CLI status JSON path completed successfully in 2.06s from the built entrypoint and produced valid JSON status output on the patched branch.
• What was not tested: I did not reproduce the reporter's Linux strace syscall counts locally, and the local gateway socket probe was blocked by sandbox network policy (EPERM), so this proof covers command completion and the patched branch behavior rather than a reachable gateway.
• Before evidence (optional but encouraged): issue Repeated plugin metadata rescans make openclaw status --json take ~27s on 2026.5.7 #79129 reports elapsed=27.19 on 2026.5.7 and a partial trace with 59,078 openclaw.plugin.json references from repeated plugin metadata scanning.

Root Cause (if applicable)

• Root cause: lean JSON status called hasConfiguredChannelsForReadOnlyScope, which can load installed channel manifest records and build plugin manifest registry data even though status --json does not render channel/plugin details.
• Missing detection / guardrail: existing fast JSON tests asserted no runtime plugin preload, but did not assert that manifest-backed configured-channel policy stayed out of the lean JSON path.
• Contributing context (if known): prior status performance fixes covered adjacent plugin snapshot paths, but this configured-channel boolean remained manifest-backed.

Regression Test Plan (if applicable)

• Coverage level that should have caught this:
  • Unit test
  • Seam / integration test
  • End-to-end test
  • Existing coverage already sufficient
• Target test or file: src/commands/status.scan.fast-json.test.ts
• Scenario the test should lock in: lean scanStatusJsonFast uses cheap channel presence detection and does not call manifest-backed configured-channel policy or preload plugin registries.
• Why this is the smallest reliable guardrail: the regression was a single fast-path dependency choice, so a focused unit test catches the exact forbidden call without requiring slow filesystem tracing.
• Existing test that already covers this (if any): the existing fast JSON tests covered no runtime plugin preload and no compatibility notices, but not this manifest-policy call.
• If no new test is added, why not: N/A

User-visible / Behavior Changes

openclaw status --json avoids unnecessary plugin manifest discovery during lean status scans and should return faster on installs with many bundled plugin manifests.

Diagram (if applicable)

Before:
status --json -> configured-channel policy -> installed channel manifest records -> plugin manifest registry scan

After:
status --json -> cheap channel config/env presence check -> status JSON result

Security Impact (required)

• New permissions/capabilities? (Yes/No) No
• Secrets/tokens handling changed? (Yes/No) No
• New/changed network calls? (Yes/No) No
• Command/tool execution surface changed? (Yes/No) No
• Data access scope changed? (Yes/No) No
• If any Yes, explain risk + mitigation: N/A

Repro + Verification

Environment

• OS: macOS 26.4.1 arm64
• Runtime/container: local Node / built OpenClaw dist/entry.js
• Model/provider: N/A
• Integration/channel (if any): status CLI
• Relevant config (redacted): local dev checkout; no secrets printed

Steps

1. Run /usr/bin/time -p node dist/entry.js status --timeout 1000 --json.
2. Run focused status tests.
3. Run targeted formatter check and whitespace check.

Expected

• Lean JSON status returns valid JSON promptly and does not require manifest-backed channel discovery.

Actual

• Command completed with valid JSON in real 2.06.

Evidence

• Trace/log snippets
• Perf numbers (if relevant)

Supplemental checks:

pnpm test src/commands/status.scan.fast-json.test.ts src/commands/status.scan.test.ts src/commands/status.scan-overview.test.ts
pnpm exec oxfmt --check --threads=1 src/commands/status.scan.fast-json.ts src/commands/status.scan.fast-json.test.ts src/commands/status.scan.test-helpers.ts
git diff --check

Human Verification (required)

What I personally verified (not just CI), and how:

• Verified scenarios: command-level status --json run from the built CLI entry; focused regression tests for the fast JSON status path.
• Edge cases checked: --all memory inspection coverage remains in the existing fast JSON test suite.
• What you did not verify: reporter's exact Linux global npm install and syscall trace counts.

Review Conversations

• I replied to or resolved every bot review conversation I addressed in this PR.
• I left unresolved only the conversations that still need reviewer or maintainer judgment.

Compatibility / Migration

• Backward compatible? (Yes/No) Yes
• Config/env changes? (Yes/No) No
• Migration needed? (Yes/No) No
• If yes, exact upgrade steps: N/A

Risks and Mitigations

• Risk: lean JSON status may no longer treat manifest-only env declarations as configured-channel signals for cold-start network-check gating.
  • Mitigation: this path does not render channel details; status --all and full channel/plugin paths still use manifest-backed policy when they need reason-rich channel/plugin answers.