qmd error

[astral saddle]

I get this error starting openclaw, but what is weird is when I do qmd status it shows no collections.

07:05:29-04:00 [memory] qmd collection add skipped for memory-alt-gamer: qmd collection add /home/node/.openclaw/workspace/gamer --name memory-alt-gamer --glob memory.md failed (
Name: memory-root-gamer (qmd://memory-root-gamer/)
Pattern: **/*.md

Use 'qmd update' to re-index it, or remove it first with 'qmd collection remove memory-root-gamer'

07:05:29-04:00 [gateway] qmd memory startup initialization armed for agent "gamer"

[indigo sinew]

To help others find answers, you can mark your question as solved via Right click solution message -> Apps -> ✅ Mark Solution

[astral saddle]

@nova wyvern do you have any ideas?

[nova wyvern]

Let me check the docs/code path for qmd so I don’t make up the fix.

Yeah, I think that’s probably two different QMD homes.

OpenClaw’s QMD backend uses an agent-local home under ~/.openclaw/agents/gamer/qmd/, so plain qmd status can show no collections while the gateway still sees a stale collection there.

The clue is this part:

• existing collection: memory-root-gamer
• old pattern: **/*.md
• new add attempt: memory-alt-gamer for memory.md

So this smells like a stale/older collection definition inside the gamer agent’s QMD state.

First, can you paste:

openclaw --version

openclaw memory status --agent gamer
openclaw status --all

openclaw memory status --agent gamer is the better check here than bare qmd status.

If that confirms it, the likely fix is just to rebuild the gamer agent’s QMD state under ~/.openclaw/agents/gamer/qmd/, not your actual memory files.

Docs:

• https://docs.openclaw.ai/help/faq
• https://docs.openclaw.ai/concepts/memory-qmd
• https://docs.openclaw.ai/cli/memory

Paste those outputs and I’ll help narrow it down.

[astral saddle]

openclaw memory status --agent gamer

🦞 OpenClaw 2026.4.11 (unknown) — If it's repetitive, I'll automate it; if it's hard, I'll bring jokes and a rollback plan.

Memory Search (gamer)
Provider: qmd (requested: qmd)
Model: qmd
Sources: memory
Indexed: 466/2 files · 466 chunks
Dirty: no
Store: ~/.openclaw/agents/gamer/qmd/xdg-cache/qmd/index.sqlite
Workspace: ~/.openclaw/workspace/gamer
Dreaming: 0 3 * * * · limit=10 · minScore=0.8 · minRecallCount=3 · minUniqueQueries=3 · recencyHalfLifeDays=14 · maxAgeDays=30
By source:
memory · 466/2 files · 466 chunks
Vector: ready
Batch: disabled (failures 0/0)
Recall store: 71 entries · 0 promoted · 71 concept-tagged · 26 spaced · scripts=71 latin
Recall path: ~/.openclaw/workspace/gamer/memory/.dreams/short-term-recall.json
Recall updated: 2026-04-12T22:17:22.467Z
QMD audit: ~/.openclaw/agents/gamer/qmd/xdg-cache/qmd/index.sqlite · 21303296 bytes · 5 collections

[nova wyvern]

I’ve got enough signal now, let me verify whether this is just a noisy stale collection or an actual broken index.

Yep, that confirms it: your memory index is healthy. This is mostly a stale QMD collection warning, not a broken memory setup.

What your output says:

• QMD is active
• Vector: ready
• Dirty: no
• QMD audit ... 5 collections

So the weird part is just:

• OpenClaw sees a stale old collection like memory-root-gamer in its agent-local QMD home
• bare qmd status is looking somewhere else, so it reports nothing

OpenClaw is using this store, not your shell’s default QMD home:

• ~/.openclaw/agents/gamer/qmd/xdg-cache/qmd/index.sqlite

Docs for that behavior:

• https://docs.openclaw.ai/concepts/memory-qmd
• https://docs.openclaw.ai/cli/memory

If you just want the truth

You can probably ignore the warning for now, since memory is working.

If you want to clean it up

Safest reset

This rebuilds only the QMD index state for that agent:

openclaw gateway stop
mv ~/.openclaw/agents/gamer/qmd ~/.openclaw/agents/gamer/qmd.bak

openclaw gateway start
openclaw memory status --agent gamer

Surgical fix

If you want to inspect/remove the stale collection in the same QMD home OpenClaw uses:

QMDROOT=~/.openclaw/agents/gamer/qmd

XDG_CONFIG_HOME="$QMDROOT/xdg-config" \
XDG_CACHE_HOME="$QMDROOT/xdg-cache" \
QMD_CONFIG_DIR="$QMDROOT/xdg-config/qmd" \
qmd status

and then:

QMDROOT=~/.openclaw/agents/gamer/qmd

XDG_CONFIG_HOME="$QMDROOT/xdg-config" \
XDG_CACHE_HOME="$QMDROOT/xdg-cache" \
QMD_CONFIG_DIR="$QMDROOT/xdg-config/qmd" \
qmd collection remove memory-root-gamer

openclaw gateway restart

If you want, paste the output of that qmd status with the env vars, and I can sanity check it before you remove anything.

[astral saddle]

Here is gamer qmd collections

Index: /home/node/.openclaw/agents/gamer/qmd/xdg-cache/qmd/index.sqlite
Size: 20.3 MB

Documents
Total: 466 files indexed
Vectors: 2579 embedded
Updated: 13h ago

AST Chunking
Status: active
Languages: typescript, tsx, javascript, python, go, rust

Collections
memory-dir-gamer (qmd://memory-dir-gamer/)
Pattern: **/.md
Files: 2 (updated 14h ago)
openclaw-docs (qmd://openclaw-docs/)
Pattern: **/.md
Files: 419 (updated 1d ago)
obsidian-memory (qmd://obsidian-memory/)
Pattern: **/.md
Files: 2 (updated 2d ago)
ceo-memory (qmd://ceo-memory/)
Pattern: **/.md
Files: 34 (updated 1d ago)
memory-root-gamer (qmd://memory-root-gamer/)
Pattern: **/*.md
Files: 9 (updated 13h ago)

[nova wyvern]

Nice, that gives the answer.

memory-root-gamer is definitely the stale one. It should not still be **/*.md.

Current OpenClaw defaults are split like this:

• memory-root-gamer → MEMORY.md
• memory-alt-gamer → memory.md
• memory-dir-gamer → memory/**/*.md

Your old memory-root-gamer is still indexing the whole workspace with **/*.md, so it grabs memory.md too, and then QMD refuses to add memory-alt-gamer.

Fix

Remove the stale collection, then restart OpenClaw:

QMDROOT=~/.openclaw/agents/gamer/qmd

XDG_CONFIG_HOME="$QMDROOT/xdg-config" \
XDG_CACHE_HOME="$QMDROOT/xdg-cache" \
QMD_CONFIG_DIR="$QMDROOT/xdg-config/qmd" \
qmd collection remove memory-root-gamer

openclaw gateway restart
openclaw memory status --agent gamer

If you want to force a fresh pass after that:

openclaw memory index --agent gamer --force

What you should expect after

You should see:

• memory-root-gamer with MEMORY.md
• memory-alt-gamer with memory.md (if that file exists)
• memory-dir-gamer still covering memory/**/*.md

If that remove fails or the warning comes back, then I’d do the bigger but safe reset by moving ~/.openclaw/agents/gamer/qmd aside and letting OpenClaw rebuild it.

[astral saddle]

ok I did what you said and deleted memory-root-gamer and restarted, and still got the same error. I think just did rm -Rf agents/gamer/qmd and restarted and again the same error. So there must be something wrong in config or somewhere else?

[nova wyvern]

That’s useful, and yeah, if it comes back after nuking agents/gamer/qmd, then it’s almost certainly being recreated from current config, not leftover index state.

Yeah, you were right. If deleting ~/.openclaw/agents/gamer/qmd still recreates the bad collection, then this is not stale DB state anymore, it’s being rebuilt from current config.

The suspicious thing is very specific:

• memory-root-gamer
• pattern **/*.md

OpenClaw’s default memory-root-* should be the root memory file, not the whole workspace. So something in config is probably creating a custom collection with that same scoped name.

Please paste these

openclaw config get memory.qmd
openclaw config get agents.defaults.memorySearch
openclaw config get agents.list

What I’m looking for

Any of these:

• memory.qmd.paths
• agents.defaults.memorySearch.qmd.extraCollections
• agents.list[].memorySearch.qmd.extraCollections
• agents.defaults.memorySearch.extraPaths
• agents.list[].memorySearch.extraPaths

Especially an entry that points at the gamer workspace root, like:

• ~/.openclaw/workspace/gamer
• .
• ~/.../workspace/gamer

with:

• pattern: "**/*.md"
• and/or name: "memory-root"

That would explain why memory-root-gamer keeps coming back after a full rebuild.

Docs: https://docs.openclaw.ai/reference/memory-config

Paste those config bits and I’ll help spot the bad entry.

[astral saddle]

$ openclaw config get memory.qmd

🦞 OpenClaw 2026.4.11 (unknown) — I'm not magic—I'm just extremely persistent with retries and coping strategies.

{
"command": "/usr/local/bin/qmd",
"paths": [
{
"path": "/app/docs",
"name": "openclaw-docs",
"pattern": "/*.md"
},
{
"path": "/home/node/obsidian/jim-ceo",
"name": "ceo-memory",
"pattern": "/*.md"
}
],
"update": {
"commandTimeoutMs": 600000,
"updateTimeoutMs": 600000,
"embedTimeoutMs": 6000000
},
"limits": {
"maxResults": 6,
"timeoutMs": 15000
},
"scope": {
"default": "allow"
}
}

$ openclaw config get agents.defaults.memorySearch

🦞 OpenClaw 2026.4.11 (unknown) — If it's repetitive, I'll automate it; if it's hard, I'll bring jokes and a rollback plan.

{
"provider": "openai",
"remote": {
"baseUrl": "https://openrouter.ai/api/v1/",
"apiKey": "OPENCLAW_REDACTED"
},
"model": "nvidia/llama-nemotron-embed-vl-1b-v2:free"
}

$ openclaw config get agents.list | grep memory
"memory_search",
"memory_get",

[nova wyvern]

Aha, global memory.qmd looks fine.

The giveaway is this: you had an obsidian-memory collection earlier, but it is not in memory.qmd.paths. So the bad collection is almost certainly coming from the gamer agent config, not the global memory config.

grep memory hid the useful part.

Can you paste the actual gamer agent block, or run this and paste the output:

openclaw config get agents.list | rg -n -C 8 '"id": "gamer"|memorySearch|extraPaths|extraCollections|obsidian-memory|memory-root'

If you don’t have rg:

openclaw config get agents.list | grep -n -A 8 -B 8 '"id": "gamer"\|"memorySearch"\|"extraPaths"\|"extraCollections"\|"obsidian-memory"\|"memory-root"'

What I expect to find is something under the gamer agent like:

• memorySearch.extraPaths
• or memorySearch.qmd.extraCollections

pointing at the gamer workspace root with **/*.md, probably with a name that ends up as memory-root-gamer.

So, good news, this is looking more like one bad agent config entry than some weird hidden QMD state.

[astral saddle]

The agent config is very simple for gamer

{
"id": "gamer",
"name": "gamer",
"workspace": "/home/node/.openclaw/workspace/gamer",
"agentDir": "/home/node/.openclaw/agents/gamer/agent"
}

[nova wyvern]

Let me verify one thing in the code, because with that minimal config I’m now suspicious this is a QMD CLI/version behavior, not your OpenClaw config.

Yeah, at this point I don’t think it’s your config.

With:

• a clean gamer agent config
• clean global memory.qmd
• deleting ~/.openclaw/agents/gamer/qmd
• and the same collision coming back

this looks like the known QMD boot collision bug/regression, not a bad local setup.

Very similar reports:

• https://github.com/openclaw/openclaw/issues/58618
• https://github.com/openclaw/openclaw/issues/58643

Next thing to check

qmd --version
/usr/local/bin/qmd --version

I want to see whether your QMD binary is old, because OpenClaw 2026.4.11 should not still be blaming config here.

Short answer

• No, this does not look like a config mistake anymore
• it’s either:
  1. an older QMD binary
  2. or a real regression/known bug

If qmd --version is not current, update QMD first.

If it is current, I’d treat this as a bug and add your repro to one of those GitHub issues, because you already ruled out the normal causes really well.

If you want, paste qmd --version next, and I’ll tell you which side of that fork you’re on.

[astral saddle]

$ qmd --version
/usr/local/bin/qmd --version
qmd 2.1.0
qmd 2.1.0

Note I have multiple agents, and none have any specific memory items set. But gamer agent is the last agent, so maybe that matters?

[nova wyvern]

Yep, with OpenClaw 2026.4.11 + qmd 2.1.0 + minimal config, I’m pretty confident this is not your mistake.

I also don’t think “last agent in the list” is the real trigger. Multi-agent probably matters, but “last” specifically sounds incidental.

So the current read is:

• not stale QMD state
• not hidden config
• not old QMD
• very likely a real bug/regression in the QMD boot collection handling

These look like the matching issues:

• https://github.com/openclaw/openclaw/issues/58618
• https://github.com/openclaw/openclaw/issues/58643

If you file/comment there, include exactly this: