openclaw - 💡(How to fix) Fix [Bug]: openclaw memory status --deep hangs indefinitely while basic status reports vector ready [2 comments, 2 participants]

Summary

On Windows 11 with OpenClaw 2026.4.26, openclaw memory status --deep produces no output at all and never returns within a 240-second timeout, even though plain openclaw status returns within ~1s and reports the memory store as vector ready · fts ready · cache on (163).

Steps to reproduce

1. Install OpenClaw 2026.4.26 on Windows 11 (pnpm channel, gateway running locally, auth token set, Node 22.16.0).
2. From a fresh PowerShell, run openclaw status — observe quick return with Memory: 49 files · 98 chunks · plugin memory-core · vector ready · fts ready · cache on (163) and Probes: skipped (use --deep).
3. From the same shell, run openclaw memory status --deep.
4. Observe: zero stdout/stderr output. No partial output. After 2+ minutes, command is still running and was killed manually.
5. Re-running the basic openclaw status immediately after killing --deep continues to return cleanly and still reports vector ready · fts ready.

Expected behavior

openclaw memory status --deep should either complete (returning the per-agent embeddings status) or fail with a parseable error within a reasonable budget. Comparable callers cite 30-60s for cold starts.

Actual behavior

Zero output for 2+ minutes; behaves as if blocked on a load step that never times out internally. No error path is observable from the CLI.

OpenClaw version

2026.4.26 (build be8c246)

Operating system

Windows 11 Pro 10.0.26200 (x64)

Install method

pnpm

Provider / routing chain

Gateway: local · ws://127.0.0.1:18789 (local loopback) · reachable 57ms · auth token.

Additional setup details

• Active runtime-deps tree: `C:\Users\Dan.openclaw\plugin-runtime-deps\openclaw-2026.4.26-323d691b4f87`
• Memory plugin: memory-core. 49 files, 98 chunks. Vector and FTS indexes both reported ready by `openclaw status`.
• MoltGuard (`@openguardrails/moltguard` v6.9.0) is currently disabled in `openclaw.json` (`plugins.entries.moltguard.enabled = false`) due to an unrelated ESM URL bug, so it is not contending for resources.

Logs and evidence

`openclaw status` — returns cleanly:

``` Gateway local · ws://127.0.0.1:18789 (local loopback) · reachable 57ms · auth token · DanWebb-laptop Memory 49 files · 98 chunks · sources memory · plugin memory-core · vector ready · fts ready · cache on (163) Probes skipped (use --deep) ```

`openclaw memory status --deep` — no output at all over 2+ minutes; killed manually.

`openclaw --version` — returns instantly with `OpenClaw 2026.4.26 (be8c246)`. CLI binary itself is healthy; only `--deep` hangs.

Impact and severity

• Affected users/systems: any consumer that uses `openclaw memory status --deep` as its readiness signal. In our case a Flask wrapper for an OpenClaw dashboard surfaces a user-facing "memory search is offline" warning that contradicts the gateway's own healthy self-check.
• Severity: annoying; produces a false-positive "offline" warning.
• Frequency: reproduces on every invocation of `--deep` on this machine (tested 2026-04-29 around 10:58 local).
• Consequence: noise in operator dashboards; users may waste time chasing a phantom outage. Memory search itself appears to keep working for actual queries.

Additional information

Worked around in our wrapper by bumping the timeout to 240s and falling back to plain `openclaw status` Memory line when `--deep` times out. This works around the symptom but does not address the underlying CLI hang.

If a verbose flag or `DEBUG=openclaw:*` capture would help triage, we can rerun.