Skip to content

memory search still targets stale QMD collections (memory-alt-main/custom-1-main) and falls back to builtin #65908

@KZMSolutions

Description

@KZMSolutions

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:

  1. stale collection-name bookkeeping (memory-alt-main vs live memory-root-main)
  2. 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.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type
    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions