Summary
openclaw memory search can still target stale/missing managed QMD collection names even when the live QMD config and index are healthy. When this happens, memory recall still works via builtin fallback, but the command emits noisy repair/failure output and can trip failure-only canaries.
Version
- OpenClaw:
2026.4.11
- Channel: stable
- OS: macOS 26.3.1 arm64
- Node: 22.22.0
- Memory backend: QMD
What I expected
openclaw memory search --query "placeholder" --max-results 1 should use the currently managed QMD collections and return results without trying to create/search missing collection names.
What happened
The command tried to use stale collection names memory-alt-main and custom-1-main, even though the live QMD config contained different collections:
memory-dir-main
custom-2-main
memory-root-main
Because memory-alt-main did not exist, OpenClaw failed the QMD search, then fell back to builtin/local search and returned results anyway.
Repro
On a system with QMD enabled for memory, run:
openclaw memory search --query "placeholder" --max-results 1
Observed output includes:
t-main --glob memory.md failed (code 1): A collection already exists for this path and pattern:
Name: memory-root-main (qmd://memory-root-main/)
Pattern: **/*.md
Use 'qmd update' to re-index it, or remove it first with 'qmd collection remove memory-root-main'
[memory] qmd collection add skipped for custom-1-main: EEXIST: file already exists, mkdir '/Users/scout/Documents/OpenClawMemory/MEMORY.md'
[memory] qmd search failed because a managed collection is missing; repairing collections and retrying once
[memory] qmd collection add skipped for memory-alt-main: qmd collection add /Users/scout/clawd --name memory-alt-main --glob memory.md failed (code 1): A collection already exists for this path and pattern:
Name: memory-root-main (qmd://memory-root-main/)
Pattern: **/*.md
Use 'qmd update' to re-index it, or remove it first with 'qmd collection remove memory-root-main'
[memory] qmd collection add skipped for custom-1-main: EEXIST: file already exists, mkdir '/Users/scout/Documents/OpenClawMemory/MEMORY.md'
[memory] qmd search failed: Error: qmd search placeholder --json -n 1 -c memory-alt-main failed (code 1): Collection not found: memory-alt-main
[memory] qmd memory failed; switching to builtin index: qmd search placeholder --json -n 1 -c memory-alt-main failed (code 1): Collection not found: memory-alt-main
Then builtin fallback still returns a valid result.
Current live state on the affected machine
openclaw memory status / QMD state is healthy:
- provider: qmd
- indexed: 56 chunks
- vector: ready
QMD collections from the active OpenClaw XDG config:
memory-dir-main | /Users/scout/clawd/memory | **/*.md
custom-2-main | /Users/scout/Documents/OpenClawMemory/memory | **/*.md
memory-root-main| /Users/scout/clawd | **/*.md
Also confirmed directly with:
XDG_CONFIG_HOME=/Users/scout/.openclaw/agents/main/qmd/xdg-config \
XDG_CACHE_HOME=/Users/scout/.openclaw/agents/main/qmd/xdg-cache \
QMD_CONFIG_DIR=/Users/scout/.openclaw/agents/main/qmd/xdg-config/qmd \
qmd collection list
which showed the same 3 collections above, and not memory-alt-main / custom-1-main.
Likely issue
There seems to be stale managed-collection name state somewhere in the memory repair/search path. The runtime/index is healthy, but openclaw memory search still references old generated collection names and then searches one that does not exist.
There may be two related bugs here:
- stale collection-name bookkeeping (
memory-alt-main vs live memory-root-main)
- custom memory path handling trying to
mkdir a file path (.../OpenClawMemory/MEMORY.md) for custom-1-main
Impact
- noisy stderr/logs
- false-positive monitoring/canary failures
- unnecessary fallback to builtin search even though QMD is available
Notes
Upgrading to 2026.4.11 did not resolve the issue.
Summary
openclaw memory searchcan still target stale/missing managed QMD collection names even when the live QMD config and index are healthy. When this happens, memory recall still works via builtin fallback, but the command emits noisy repair/failure output and can trip failure-only canaries.Version
2026.4.11What I expected
openclaw memory search --query "placeholder" --max-results 1should use the currently managed QMD collections and return results without trying to create/search missing collection names.What happened
The command tried to use stale collection names
memory-alt-mainandcustom-1-main, even though the live QMD config contained different collections:memory-dir-maincustom-2-mainmemory-root-mainBecause
memory-alt-maindid not exist, OpenClaw failed the QMD search, then fell back to builtin/local search and returned results anyway.Repro
On a system with QMD enabled for memory, run:
openclaw memory search --query "placeholder" --max-results 1Observed output includes:
Then builtin fallback still returns a valid result.
Current live state on the affected machine
openclaw memory status/ QMD state is healthy:QMD collections from the active OpenClaw XDG config:
Also confirmed directly with:
which showed the same 3 collections above, and not
memory-alt-main/custom-1-main.Likely issue
There seems to be stale managed-collection name state somewhere in the memory repair/search path. The runtime/index is healthy, but
openclaw memory searchstill references old generated collection names and then searches one that does not exist.There may be two related bugs here:
memory-alt-mainvs livememory-root-main)mkdira file path (.../OpenClawMemory/MEMORY.md) forcustom-1-mainImpact
Notes
Upgrading to
2026.4.11did not resolve the issue.