Issue Station
Sign In
Tools hereToolbox

openclaw - 💡(How to fix) Fix memory subcommands (status / index / search / promote) hang indefinitely with no output on Linux containers

Official PRs (…)
ON THIS PAGE

Recommended Tools

×6

Utilities matched from this issue’s tags and category — try them while you read without losing context.

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

Helpful · Quick feedback

Loading…

openclaw memory <subcommand> (status / index / search / promote) hangs forever on Linux containers, producing zero bytes of stdout/stderr. The CLI never writes anything, never errors, never exits. openclaw --help and openclaw memory --help work fine — only the actual subcommand handlers hang.

Reproduced on both 2026.4.9 and 2026.4.15 (latest stable) inside a node:22-bookworm-slim container running OpenClaw with the gateway already up and healthy on port 3000.

Error Message

Hangs forever — no output, no error

Root Cause

  • openclaw memory promote cron (0 3 * * *) for dreaming never runs — schedule fires but the spawned process hangs forever
  • /dreaming status slash command depends on the CLI — broken
  • Operators can't manually inspect or reindex memory state from inside the container
  • Hangs aren't caught by typical --timeout flags because the subcommand never registers a SIGALRM handler before it blocks

Fix Action

Fix / Workaround

Workaround for downstream users (us)

Code Example

# Works — returns immediately
openclaw --version
openclaw --help
openclaw memory --help

# Hangs forever — no output, no error
openclaw memory status
openclaw memory status --json
openclaw memory status --verbose
openclaw memory index
openclaw memory search test
DEBUG=openclaw:* openclaw memory status

# Even with explicit timeout + file capture, 0 bytes written:
sh -c "timeout 30 openclaw memory status > /tmp/out 2>&1; echo EXIT=\$?; wc -c /tmp/out"
# → EXIT=124 (timeout fired), 0 bytes
RAW_BUFFERClick to expand / collapse

Summary

openclaw memory <subcommand> (status / index / search / promote) hangs forever on Linux containers, producing zero bytes of stdout/stderr. The CLI never writes anything, never errors, never exits. openclaw --help and openclaw memory --help work fine — only the actual subcommand handlers hang.

Reproduced on both 2026.4.9 and 2026.4.15 (latest stable) inside a node:22-bookworm-slim container running OpenClaw with the gateway already up and healthy on port 3000.

Environment

  • OpenClaw: 2026.4.15 (041266a) (also reproduces on 2026.4.9 (0512059))
  • Node: v22 (matches MIN_NODE_VERSION from openclaw.mjs)
  • Container: node:22-bookworm-slim Debian 12
  • Gateway: live + healthy on 127.0.0.1:3000 (other channels working — Telegram is connected and the bot answers chat completions normally)
  • Env: OPENCLAW_PORT=3000, OPENCLAW_STATE_DIR=/app/workspace/.openclaw, OPENCLAW_CONFIG_PATH=/app/workspace/.openclaw/config.json, HOME=/app/workspace

Repro

# Works — returns immediately
openclaw --version
openclaw --help
openclaw memory --help

# Hangs forever — no output, no error
openclaw memory status
openclaw memory status --json
openclaw memory status --verbose
openclaw memory index
openclaw memory search test
DEBUG=openclaw:* openclaw memory status

# Even with explicit timeout + file capture, 0 bytes written:
sh -c "timeout 30 openclaw memory status > /tmp/out 2>&1; echo EXIT=\$?; wc -c /tmp/out"
# → EXIT=124 (timeout fired), 0 bytes

What we've ruled out

  • ✅ Gateway reachable: curl http://localhost:3000/healthz works
  • ✅ AIL embed provider reachable + returns 1024-dim vectors on POST
  • ✅ Config valid: gateway loads cleanly, [gateway] ready (6 plugins, 4.9s) in logs
  • ✅ memorySearch.provider: "openai" set
  • ✅ memory-core plugin loaded
  • ✅ Bot's day-to-day chat completions work fine through the gateway
  • ✅ CLI bootstrap works (openclaw --help is instant)
  • ✅ Subcommand IS registered (openclaw memory --help lists status/index/search/promote/etc)
  • ❌ Every openclaw memory <subcmd> hangs before emitting a single byte

Why this matters

  • openclaw memory promote cron (0 3 * * *) for dreaming never runs — schedule fires but the spawned process hangs forever
  • /dreaming status slash command depends on the CLI — broken
  • Operators can't manually inspect or reindex memory state from inside the container
  • Hangs aren't caught by typical --timeout flags because the subcommand never registers a SIGALRM handler before it blocks

Suspected source

The subcommand handlers in dist/memory-core-host-status-CZB6ooKA.js and siblings appear to block before reaching their first console.log / writer call. We saw 200+ module loads via NODE_DEBUG=module followed by silence — looks like a promise that never resolves at the top of the handler (plausibly a gateway / lock / embedding handshake that has no timeout).

Happy to add diagnostic output, run a custom build, or strace a hung process if useful.

Workaround for downstream users (us)

We rebuild the agent image weekly with --build-arg OPENCLAW_VERSION=$(npm view openclaw version) to pick up new releases as soon as they land — but the upgrade alone (4.9 → 4.15) didn't fix this. We've shipped our own hybrid memory subsystem that doesn't go through the CLI as a result; happy to switch back the moment this lands.

extent analysis

TL;DR

The openclaw memory subcommands hang indefinitely on Linux containers, likely due to a promise that never resolves at the top of the handler, and a potential workaround is to add diagnostic output or custom logging to identify the blocking point.

Guidance

  • Investigate the dist/memory-core-host-status-CZB6ooKA.js and related files for potential promises or async operations that may be causing the hang, and consider adding logging or debugging statements to identify the blocking point.
  • Use NODE_DEBUG=module to trace module loads and identify if there are any issues with module resolution or loading that may be contributing to the hang.
  • Consider adding a custom timeout or error handling mechanism to the subcommand handlers to prevent indefinite hangs and provide more informative error messages.
  • Run the openclaw memory subcommands with increased verbosity or debugging flags to see if any additional output or errors are produced that may help identify the cause of the hang.

Example

No specific code example is provided, as the issue is more related to debugging and identifying the root cause of the hang, rather than applying a specific code fix.

Notes

The issue appears to be specific to the openclaw memory subcommands and may be related to the interaction with the gateway or other components. Further debugging and investigation are needed to identify the root cause and develop a fix.

Recommendation

Apply a workaround by adding custom logging or debugging statements to the openclaw memory subcommands to help identify the blocking point and provide more informative error messages. This will allow for better understanding of the issue and potentially lead to a more permanent fix.

Vote matrix · Quick signals

Works
Did the solution work? Tap to confirm.
Easy Fix
Was it a quick fix?
Time Saver
Did it save you time?
Blocking
Was it severely blocking?
Common Issue
Are others likely hitting this too?
Flaky / Intermittent
Is it intermittent?
Verified / Reproducible
Can you reproduce it reliably?
Loading…
#dependency conflict#environment setup#docker error#permission error#memory optimization

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

Back to top recommendations

TRENDING

openclaw - 💡(How to fix) Fix memory subcommands (status / index / search / promote) hang indefinitely with no output on Linux containers