[Bug]: 2026.4.25 openclaw status is slow and shows empty Channels table while Telegram is connected

Bug type

Behavior bug (incorrect output/state without crash)

Beta release blocker

No

Summary

On OpenClaw 2026.4.25 (aa36ee6), openclaw status takes ~52s on a live install, renders an empty Channels table, and runs heavyweight status subchecks by default; openclaw channels status correctly shows Telegram enabled/configured/running/connected.

Steps to reproduce

1. Install/run OpenClaw 2026.4.25 (aa36ee6) with a configured Telegram channel.
2. Run openclaw status.
3. Observe wall time and Channels table.
4. Run openclaw channels status on the same install.
5. Compare channel state and timing.

Expected behavior

openclaw status should remain a fast operator overview and should show configured/running channels consistently with openclaw channels status. Heavy checks such as security audit, plugin compatibility scans, and memory/vector probes should only run when explicitly requested or should be bounded/cached enough not to dominate the default status command.

Actual behavior

Observed on a live OpenClaw 2026.4.25 install:

• openclaw status completed in ~51.85s and rendered an empty Channels table.
• openclaw channels status completed in ~4.21s and reported Telegram default: enabled, configured, running, connected.
• openclaw status --json completed in ~4.25s but returned an empty channelSummary.
• openclaw security audit alone took ~14.18s before local mitigation.
• Source-level timing inside the status path showed:
  • plugin compatibility snapshot: ~25.8s
  • memory status/vector path: ~19.8s
  • status overview/channel table construction: ~4.2s

After applying the local hotfix described below:

• openclaw status completes in ~5.7–7.2s.
• The default Channels table shows Telegram | ON | OK.
• openclaw channels status still reports Telegram running/connected.
• openclaw security audit still works as an explicit command (~10.2s on this host, 0 critical / 2 warn / 2 info).

OpenClaw version

2026.4.25 (aa36ee6)

Operating system

Ubuntu 24.04, Linux 6.8.0-110-generic x64, Node.js 22.22.2

Install method

npm global package, systemd user gateway service

Model

openai-codex/gpt-5.5

Provider / routing chain

OpenClaw gateway local loopback -> OpenAI Codex OAuth profile

Additional provider/model setup details

Telegram is configured and connected. The issue is in CLI status/reporting, not in Telegram delivery: inbound/outbound Telegram continued to function and openclaw channels status reported the channel correctly.

Logs, screenshots, and evidence

$ openclaw --version
OpenClaw 2026.4.25 (aa36ee6)

$ /usr/bin/time -f 'TIME real=%E cpu=%P maxrss=%MKB' openclaw status
# before mitigation
TIME real=0:51.85 cpu=111% maxrss=684512KB
# output included an empty Channels table

$ /usr/bin/time -f 'TIME real=%E cpu=%P maxrss=%MKB' openclaw channels status
TIME real=0:04.21 cpu=126% maxrss=335236KB
Checking channel status…
Gateway reachable.
- Telegram default: enabled, configured, running, connected, in:6m ago, mode:polling, token:*** groups:unmentioned

$ /usr/bin/time -f 'TIME real=%E cpu=%P maxrss=%MKB' openclaw status --json
TIME real=0:04.25 cpu=135% maxrss=332364KB
# JSON keys included channelSummary, but channelSummary was []

# Isolated source of empty Channels table in packaged runtime:
# listReadOnlyChannelPluginsForConfig(... includeSetupRuntimeFallback:false)
# returned:
{
  "plugins": [],
  "configuredChannelIds": ["telegram"],
  "missingConfiguredChannelIds": ["telegram"]
}

# Same resolver with includeSetupRuntimeFallback:true returned:
{
  "plugins": [{"id":"telegram","label":"Telegram"}],
  "configuredChannelIds": ["telegram"],
  "missingConfiguredChannelIds": []
}

# Timed status path before mitigation:
overview: 4.177s
plugins: 25.815s
memory: 19.828s

Impact and severity

• Affected: operators on 2026.4.25 using openclaw status, confirmed with a configured Telegram channel.
• Severity: medium/high operational regression. Runtime messaging still works, but the primary health command is slow and misleading.
• Frequency: reproducible on the tested install.
• Consequence: channel health appears broken when it is not; routine status checks burn ~50s and high CPU/RSS; operators may downgrade unnecessarily or misdiagnose channel failures.

Additional information

I applied and verified a local mitigation against the installed 2026.4.25 package. I can validate an upstream candidate fix or hotfix build on the affected host.

Local mitigation summary:

1. src/commands/status.command.ts
   • Do not run resolveStatusSecurityAudit in normal text openclaw status; reserve it for explicit --all/--deep style paths.
2. src/commands/status.command-report-data.ts
   • When audit is intentionally skipped, show a clear skipped message instead of rendering false 0 critical / 0 warn / 0 info audit results.
3. src/commands/status-all/channels.ts
   • Use includeSetupRuntimeFallback: true for the Channels table so configured bundled channels such as Telegram are discoverable in the status view.
4. src/commands/status.scan.ts
   • Avoid heavyweight plugin compatibility and memory/vector probes in the default text status path. On the tested host these accounted for ~45s of the ~52s runtime.

Suggested release smoke tests:

Given a configured Telegram channel:
- openclaw status completes under a bounded budget, e.g. <10s on a normal host
- openclaw status shows Telegram in the Channels table
- openclaw channels status agrees with openclaw status on enabled/configured/running channel state
- default openclaw status does not run heavyweight audit/memory/plugin scans unless explicitly requested

Attached/referenced patch artifacts:

• Source-level hotfix patch proposal: openclaw-2026.4.25-status-regression-source-hotfix.patch
• Installed-package dist hotfix used on the affected host: openclaw-2026.4.25-status-regression-installed-dist-hotfix.patch