My QMD memory config not working

[grave salmon]

This is my QMD config
"memory": { "backend": "qmd", "citations": "auto", "qmd": { "includeDefaultMemory": true, "paths": [ { "name": "workspace", "path": "/root/.openclaw/workspace", "pattern": "**/*.md" }, { "name": "memory", "path": "/root/.openclaw/workspace/memory", "pattern": "*.md" } ], "update": { "interval": "5m", "embedInterval": "30m", "onBoot": true, "debounceMs": 15000, "waitForBootSync": false }, "limits": { "maxResults": 5, "maxInjectedChars": 3000, "timeoutMs": 300000 } } }

It shows that the interval of auto indexing and auto embed is 5m and 30m
But actually it do not happen (i ask Claw to test it in the log)
tail -f ~/.openclaw/logs/openclaw.log | grep -i "memory\|qmd"

And it keeps asking me to use cronjob or manual update to achieve this

Where did I do wrong ?
Please help @deep elk

[hollow glade]

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

[deep elk]

A couple things are going on here — your config is basically fine, but your test method makes it look like “nothing happens”.

1) Successful QMD updates don’t log anything

In the current implementation, the gateway only logs QMD failures (warn), not “qmd update ran successfully”. So:

tail -f ~/.openclaw/logs/openclaw.log | grep -i "memory\|qmd"

will often show nothing even if the 5m interval is working perfectly.

2) You’re likely tailing the wrong log file

The recommended way is:

openclaw logs --follow

File locations differ depending on service/daemon vs foreground runs (docs call this out).

3) Verify QMD is actually active (and not silently falling back)

Run:

openclaw status --all

Look for the Memory section and confirm it says backend: qmd (and ideally shows a lastUpdateAt timestamp).
If it says builtin / fallback, then QMD didn’t start (most common cause: qmd binary not found in the gateway service PATH).

If QMD isn’t on the daemon PATH, fix by either:

• setting memory.qmd.command to the absolute path of qmd, or
• ensuring the service environment PATH includes wherever you installed qmd (often ~/.bun/bin).

4) “Interval doesn’t happen” — how to prove it without logs

Check the QMD index file timestamp instead (it should change after updates):

ls -la ~/.openclaw/agents/main/qmd/index.sqlite
# or:
stat ~/.openclaw/agents/main/qmd/index.sqlite

If you paste these three, I can tell you exactly which case you’re in

openclaw --version
openclaw gateway status
openclaw status --all

Relevant docs: https://docs.openclaw.ai/concepts/memory#qmd-backend-experimental

[grave salmon]

`openclaw --version
openclaw gateway status
openclaw status --all
2026.2.9

🦞 OpenClaw 2026.2.9 (33c75cb) — Ship fast, log faster.

│
◇
Service: systemd (enabled)
File logs: ~/.openclaw/logs/openclaw.log
Command: /usr/bin/node /usr/lib/node_modules/openclaw/dist/index.js gateway --port <PORT>
Service file: ~/.config/systemd/user/openclaw-gateway.service
Service env: OPENCLAW_GATEWAY_PORT=<PORT>

Config (cli): ~/.openclaw/openclaw.json
Config (service): ~/.openclaw/openclaw.json

Gateway: bind=loopback (127.0.0.1), port=<PORT> (service args)
Probe target: ws://127.0.0.1:<PORT>
Dashboard: http://127.0.0.1:<PORT>/
Probe note: Loopback-only gateway; only local clients can connect.

Runtime: running (pid <PID>, state active, sub running, last exit 0, reason 0)
RPC probe: ok

Listening: 127.0.0.1:<PORT>
Troubles: run openclaw status
Troubleshooting: https://docs.openclaw.ai/troubleshooting

🦞 OpenClaw 2026.2.9 (33c75cb) — curl for conversations.

│
OpenClaw status --all

Overview

┌─────────────────┬──────────────────────────────────────────────────────────────────────────────┐
│ Item │ Value │
├─────────────────┼──────────────────────────────────────────────────────────────────────────────┤
│ Version │ 2026.2.9 │
│ OS │ linux <KERNEL_VERSION> (x64) │
│ Node │ <NODE_VERSION> │
│ Config │ ~/.openclaw/openclaw.json │
│ Dashboard │ http://127.0.0.1:<PORT>/ │
│ Tailscale │ serve · Running · <REDACTED_HOST>.ts.net · https://<REDACTED_HOST>.ts.net │
│ Channel │ stable (default) │
│ Update │ pnpm · npm latest 2026.2.9 │
│ Gateway │ local · ws://127.0.0.1:<PORT> · reachable <LATENCY> · auth token │
│ Security │ Run: openclaw security audit --deep │
│ Gateway self │ <REDACTED_MACHINE_NAME> (<REDACTED_IP>) app unknown linux <KERNEL_VERSION> │
│ Gateway service │ systemd installed · enabled · running (pid <PID>) │
│ Node service │ systemd not installed │
│ Agents │ 3 total · 0 bootstrapping · 1 active · 20 sessions │
└─────────────────┴──────────────────────────────────────────────────────────────────────────────┘

Channels
┌──────────┬─────────┬────────┬──────────────────────────────────────────────────────────────┐
│ Channel │ Enabled │ State │ Detail │
├──────────┼─────────┼────────┼──────────────────────────────────────────────────────────────┤
│ Telegram │ ON │ OK │ token config×3 (sha256:<REDACTED_HASH> · len <LEN>) │
└──────────┴─────────┴────────┴──────────────────────────────────────────────────────────────┘

Telegram accounts
┌──────────┬──────────┬──────────────────────────────────────────────┐
│ Account │ Status │ Notes │
├──────────┼──────────┼──────────────────────────────────────────────┤
│ account1 │ OK │ token:config │
│ account2 │ OK │ token:config │
│ account3 │ OK │ token:config │
└──────────┴──────────┴──────────────────────────────────────────────┘

Agents
┌────────────┬───────────┬──────────┬──────────┬──────────────────────────────────────────────┐
│ Agent │ Bootstrap │ Sessions │ Active │ Store │
├────────────┼───────────┼──────────┼──────────┼──────────────────────────────────────────────┤
│ agent1 │ OK │ 14 │ 1m ago │ ~/.openclaw/agents/agent1/... │
│ agent2 │ OK │ 3 │ 2d ago │ ~/.openclaw/agents/agent2/... │
│ agent3 │ OK │ 3 │ 2d ago │ ~/.openclaw/agents/agent3/... │
└────────────┴───────────┴──────────┴──────────┴──────────────────────────────────────────────┘

Diagnosis (read-only)

Gateway connection details:
Gateway target: ws://127.0.0.1:<PORT>
Source: local loopback
Config: /root/.openclaw/openclaw.json
Bind: loopback

✓ Config: /root/.openclaw/openclaw.json
✓ Restart sentinel: none
! Port <PORT>
Port <PORT> is already in use.

• pid <PID> root: openclaw-gateway (127.0.0.1:<PORT>)
• Gateway already running locally.
  ✓ Tailscale: serve · Running · <REDACTED_HOST>.ts.net
  ips: <REDACTED_IPv4>, <REDACTED_IPv6>
  https: https://<REDACTED_HOST>.ts.net
  ✓ Skills: 12 eligible · 0 missing · /root/.openclaw/workspace
  ✓ Channel issues (none)

Pasteable debug report. Auth tokens redacted.`

📊 ANALYSIS:

🔍 REALITY STATE:

Check	Result
QMD Binary	✅ Yes (/usr/bin/qmd)
Index File	✅ yes (508 KB)
Collections	✅ 7 collections created
Files Indexed	✅ 77 files
Last Update	❌ 17h ago (auto-update not running!)
Vectors	❌ 0 embedded (embed not running!)
Pending	⚠️ 52 files need embedding

🎯 CAUSE:

You were right! Auto-update not running, this is real issue:

1. ✅ QMD installed
2. ✅ Collections created
3. ✅ Files indexed
4. ❌ Auto-update interval (5m) no trigger
5. ❌ Auto-embed (30m) no trigger

📋 EVIDENCE for BUG REPORT:

$ qmd status
Updated: 17h ago ← Auto-update not running!
Vectors: 0 embedded ← Auto-embed not running!
Pending: 52 need embedding

💡 TEMPORARY FIX:

Run this manually to fix:

export XDG_CONFIG_HOME="$HOME/.openclaw/agents/main/qmd/xdg-config"
export XDG_CACHE_HOME="$HOME/.openclaw/agents/main/qmd/xdg-cache"
qmd update && qmd embed

🐛 BUG REPORT UPDATE:

Issue: interval: "5m" and embedInterval: "30m" not trigger despite right config .

Evidence:

• Index last updated: 17 hours ago
• 0 vectors embedded (52 pending)
• Manual qmd update && qmd embed works

@deep elk

[deep elk]

Your gateway/service looks healthy (RPC probe ok, config path matches). The missing piece is: we still haven’t confirmed whether the gateway is actually running the QMD backend or silently falling back to builtin.

Also: grepping the log for qmd won’t show anything on success — QMD only logs on warnings/failures, not “update ran”.

1) Check what backend you’re really on

Please run this and paste the output:

openclaw memory status --agent main --json

You’re looking for:

• status.backend: "qmd" ✅ means QMD is active
• or a fallback field / not-qmd backend ❌ means it couldn’t start QMD and switched to builtin

If you want it to actively try an index run (and surface errors), do:

openclaw memory status --agent main --deep --index --verbose

2) Most common cause: qmd not on PATH for the systemd service

When you install qmd via bun it usually lands in ~/.bun/bin/qmd, which systemd services often don’t have in PATH.

Check in your shell:

command -v qmd
qmd --version

If command -v qmd prints something like /root/.bun/bin/qmd, then add this to your OpenClaw config:

memory: {
  backend: "qmd",
  qmd: {
    command: "/root/.bun/bin/qmd",
    // ...the rest of your qmd config...
  }
}

Then restart:

openclaw gateway restart

3) Prove the 5m timer is working (without relying on logs)

After you’ve confirmed backend=qmd, watch the index DB mtime:

stat ~/.openclaw/agents/main/qmd/index.sqlite

Wait >5 minutes, run stat again — the mtime should advance if interval updates are firing.

Docs reference (QMD backend): https://docs.openclaw.ai/concepts/memory#qmd-backend-experimental

If you paste the openclaw memory status --agent main --json output, I can tell you immediately whether this is a PATH/fallback issue or something else (collections/paths/permissions/timeouts).

[deep elk]

The output you pasted is only the Overview table from openclaw status --all — it doesn’t include the Memory Search section, which is the part that tells us whether QMD is actually active.

Two important gotchas with QMD:

1. You won’t see “qmd update ran” in logs when it succeeds.
   The gateway only logs QMD on warnings/failures (e.g. “qmd update failed”, “qmd memory unavailable; falling back…”). So grepping the logs for qmd|memory often shows nothing even when it’s working.

2. The QMD “interval/onBoot” timers only exist once the QMD manager is initialized in the gateway process (i.e. once memory search is actually being used/initialized). If nothing ever instantiates the QMD manager, there’s nothing running the interval loop — which is why you get advice like “use cron/manual update”.

Next step (this will immediately reveal what’s wrong)

Run and paste:

openclaw memory status --agent main --json

What we’re looking for:

• backend: "qmd" → QMD is active
• If you see builtin provider and/or a fallback reason → QMD didn’t start (most commonly: qmd not found on the systemd service PATH)

If it’s a PATH issue (most common)

Check where qmd is:

command -v qmd
qmd --version

If it’s something like ~/.bun/bin/qmd, systemd often can’t see that. Fix by setting an absolute path:

memory: {
  backend: "qmd",

  qmd: {
    command: "/root/.bun/bin/qmd",
    // …
  }
}

then:

openclaw gateway restart

If QMD is active but you’re “not seeing it run”

That’s expected (no success logs). To prove it’s updating, we can either:

• check the QMD status field (custom.qmd.lastUpdateAt in the --json output), or

• watch the index file timestamp:

  stat ~/.openclaw/agents/main/qmd/index.sqlite
  

Paste the openclaw memory status --agent main --json output and I’ll tell you exactly which branch you’re in.

[grave salmon]

openclaw memory status --agent main --json
[
{
"agentId": "main",
"status": {
"backend": "qmd",
"provider": "qmd",
"model": "qmd",
"requestedProvider": "qmd",
"files": 79,
"chunks": 79,
"dirty": false,
"workspaceDir": "/root/.openclaw/workspace",
"dbPath": "/root/.openclaw/agents/main/qmd/xdg-cache/qmd/index.sqlite",
"sources": [
"memory"
],
"sourceCounts": [
{
"source": "memory",
"files": 79,
"chunks": 79
}
],
"vector": {
"enabled": true,
"available": true
},
"batch": {
"enabled": false,
"failures": 0,
"limit": 0,
"wait": false,
"concurrency": 0,
"pollIntervalMs": 0,
"timeoutMs": 0
},
"custom": {
"qmd": {
"collections": 7,
"lastUpdateAt": null
}
}
},
"scan": {
"sources": [
{
"source": "memory",
"totalFiles": 16,
"issues": []
}
],
"totalFiles": 16,
"issues": []
}
}
]

[deep elk]

That paste still doesn’t show the Memory Search section (which is the only part that tells us if QMD is active or if you’re silently on builtin/fallback).

Let’s force an unambiguous answer.

1) Show which backend you’re actually running

Run:

openclaw memory status --agent agent1

(or --json if you prefer)

You should see Provider: qmd / backend: qmd if QMD is actually in use.

If it shows builtin (or a fallback reason), QMD never started → the interval timers won’t run.

2) Force a QMD run (and surface the real error if any)

This will actively try qmd update/qmd embed and print progress:

openclaw memory status --agent agent1 --deep --index --verbose

If QMD isn’t reachable, you’ll get the concrete error (missing binary, PATH, permission, bad collection path, timeout, etc).

3) Likely config issue: your paths point at /root/... but you’re on a systemd --user service

Your service is systemd user, so it’s usually not running as root. In that case, indexing /root/.openclaw/workspace will fail (or be empty/unreadable).

Also: with includeDefaultMemory: true, you do not need to add the workspace+memory paths at all — OpenClaw already creates QMD collections for:

• WORKSPACE/MEMORY.md
• WORKSPACE/memory.md
• WORKSPACE/memory/**/*.md

So as a test, remove those custom paths entries (or change them to ~/.openclaw/workspace), restart the gateway, then run the openclaw memory status ... --index command above.

4) Most common cause: qmd not on PATH for systemd

If the index command reports it can’t run qmd, check:

command -v qmd
qmd --version

If it lives in something like ~/.bun/bin/qmd, systemd often won’t see it. Fix by setting:

memory: { qmd: { command: "/home/<you>/.bun/bin/qmd" } }

(and restart gateway)

---

Paste the output of either:

• openclaw memory status --agent agent1
• or openclaw memory status --agent agent1 --deep --index --verbose

…and I’ll tell you exactly what’s preventing the interval updates.

[grave salmon]

Results:

1. QMD Location:

   • Shell: /usr/bin/qmd
   • Systemd PATH: includes /usr/bin ✅
   • Binary: /usr/bin/qmd (symlink to ../lib/node_modules/qmd/qmd)

2. Index Mtime Test:

   • Last manual update: 03:05:17
   • Current time: 03:18:36
   • Elapsed: 13 minutes
   • Expected: 2 auto-updates (5m interval)
   • Actual: 0 auto-updates (mtime unchanged)

Conclusion: Auto-update not firing despite QMD being in PATH and config being correct. Manual updates work perfectly. @deep elk

[deep elk]

That openclaw memory status --json output is the key:

• ✅ backend: "qmd" / provider: "qmd" → QMD is enabled and working
• dbPath: /root/.openclaw/agents/main/qmd/xdg-cache/qmd/index.sqlite → this is the real index DB location
• custom.qmd.lastUpdateAt: null is not proof that updates never run — it’s just an in-memory field for that one manager instance. The openclaw memory status command spins up a fresh manager, prints status, then exits, so you’ll often see null.

Why it looks like the 5m / 30m timers “don’t happen”

Two gotchas in the current design:

1. Successful QMD updates are silent in logs
   You’ll only see log lines when something fails (qmd update failed, qmd boot update failed, qmd embed failed).

2. The QMD interval loop only starts after the QMD manager is initialized inside the running gateway
   That usually happens the first time the gateway executes memory_search (or anything that calls the memory manager).
   If you restart the gateway and then never hit memory_search, nothing “boot/interval” runs because nothing created the QMD manager yet.

How to “kick” QMD on gateway boot (no cron needed, just a one-time warmup)

Call memory_search once via the Gateway’s Tools Invoke API (this runs inside the gateway process, unlike openclaw memory … which is a separate CLI process):

curl -sS http://127.0.0.1:<PORT>/tools/invoke \
  -H "Authorization: Bearer <YOUR_GATEWAY_TOKEN>" \
  -H "Content-Type: application/json" \
  -d '{"tool":"memory_search","args":{"query":"warmup"}}'

Docs: https://docs.openclaw.ai/gateway/tools-invoke-http-api

After that, the gateway process should have the QMD manager alive, and the interval / embedInterval timers can actually run.

How to prove the interval is working

1. Append a unique marker to a file that QMD indexes (e.g. WORKSPACE/MEMORY.md)
2. Wait > 5 minutes
3. Query that marker via memory_search (again via tools/invoke or by asking the bot a question that forces recall)

If it shows up without manually running openclaw memory index, the interval is working.

Small config note

With includeDefaultMemory: true, you don’t need to add workspace+memory again in paths unless you’re trying to index extra folders beyond MEMORY.md + memory/**/*.md. Not wrong, just redundant.

If you want QMD to always start its timers immediately on gateway startup without needing a first memory_search, that’s likely an OpenClaw behavior/docs mismatch worth filing as an issue: https://github.com/openclaw/openclaw/issues

[grave salmon]

openclaw memory status --agent agent1

🦞 OpenClaw 2026.2.9 (33c75cb) — I'm like tmux: confusing at first, then suddenly you can't live without me.

03:21:16 [memory] qmd collection add failed for memory-root: spawn qmd ENOENT
03:21:16 [memory] qmd collection add failed for memory-alt: spawn qmd ENOENT
03:21:16 [memory] qmd collection add failed for memory-dir: spawn qmd ENOENT
03:21:16 [memory] qmd collection add failed for workspace: spawn qmd ENOENT
03:21:16 [memory] qmd collection add failed for memory: spawn qmd ENOENT
03:21:16 [memory] qmd collection add failed for memory: spawn qmd ENOENT
03:21:16 [memory] qmd collection add failed for memory: spawn qmd ENOENT
03:21:16 [memory] failed to read qmd index stats: Error: unable to open database file
03:21:16 [memory] qmd boot update failed: Error: spawn qmd ENOENT
Memory Search (agent1)
Provider: qmd (requested: qmd)
Model: qmd
Sources: memory
Indexed: 0/0 files · 0 chunks
Dirty: no
Store: ~/.openclaw/agents/agent1/qmd/xdg-cache/qmd/index.sqlite
Workspace: ~/.openclaw/workspace-agent1
By source:
memory · 0/0 files · 0 chunks
Vector: ready
Batch: disabled (failures 0/0)
Issues:
memory directory missing (~/.openclaw/workspace-agent1/memory)

[deep elk]

Your openclaw memory status --json proves the important part:

• backend: "qmd" and it has indexed docs (files: 79) → QMD is enabled and usable.
• The lastUpdateAt: null there is expected in your case because waitForBootSync=false means the boot update is fire-and-forget; the CLI command prints status and exits before the background boot update would ever finish (in that CLI process).

Why your “mtime unchanged ⇒ no auto-updates” test can be misleading

qmd update is incremental. If no Markdown files changed, it may do essentially nothing and not touch index.sqlite, so the mtime can stay unchanged even if the timer fired.

Also, your embedInterval=30m, and you only waited ~13m — so “no embed activity” is normal.

A reliable test (forces a change and doesn’t rely on logs/mtime)

1. Create a brand new memory file with a unique string (don’t run any manual update after this):

echo "qmd-autotest-$(date +%s)" >> /root/.openclaw/workspace/memory/qmd_autotest.md

2. Wait 6+ minutes (longer than your interval: 5m).

3. Search for that exact string:

openclaw memory search "qmd-autotest-" --agent main

If it shows up without you running qmd update / openclaw memory index, then the auto-update timer is working.

The real gotcha: QMD “interval” is an in-process timer

The 5m/30m schedule is implemented as a setInterval inside the QmdMemoryManager. That timer only exists in a long-lived process that created the manager.

• The CLI (openclaw memory status/index/search) starts a manager, then exits → timers die with the process.
• The Gateway will only have that timer if something in the running gateway actually instantiates the memory manager (typically via memory_search tool usage).

If you want to guarantee the gateway has instantiated it after restart, do a one-time warmup call inside the gateway (HTTP tools invoke):

curl -sS http://127.0.0.1:<PORT>/tools/invoke \
  -H "Authorization: Bearer <YOUR_GATEWAY_TOKEN>" \
  -H "Content-Type: application/json" \
  -d '{"tool":"memory_search","args":{"query":"warmup"}}'

Docs: https://docs.openclaw.ai/gateway/tools-invoke-http-api

About “openclaw memory status hangs”

When that happens it’s usually QMD being blocked on something (db lock / long-running qmd process). Quick checks:

pgrep -af qmd
lsof /root/.openclaw/agents/main/qmd/xdg-cache/qmd/index.sqlite | head

If you paste those outputs + whether the “autotest” search works after 6 minutes, we can pin down if it’s (A) timers never started in the gateway, or (B) timers started but a stuck QMD subprocess blocks further updates.

Those spawn qmd ENOENT lines are a big clue — and it’s not necessarily “qmd not in PATH”.

In OpenClaw’s QMD manager, every qmd … call is spawned with:

• command = memory.qmd.command (default "qmd")
• cwd = agent workspaceDir

So you also get ENOENT if the cwd directory doesn’t exist.

What’s happening for agent1

Your output shows:

• Workspace: ~/.openclaw/workspace-agent1
• Issues: memory directory missing (~/.openclaw/workspace-agent1/memory)
• and then every QMD spawn fails with ENOENT

That strongly suggests ~/.openclaw/workspace-agent1 (or its parent) is missing/not accessible, so Node can’t spawn the process with that cwd.

Fix

Create the agent workspace + memory dir (safe):

mkdir -p ~/.openclaw/workspace-agent1/memory
touch ~/.openclaw/workspace-agent1/MEMORY.md

Then re-run:

openclaw memory status --agent agent1

If that was the issue, the spawn qmd ENOENT warnings should disappear immediately.

Why main looked fine

Your earlier --agent main --json showed an existing index under /root/.openclaw/agents/main/..., so main’s workspace /root/.openclaw/workspace exists and QMD can run there. agent1 is a different workspace, and right now it’s not set up.

About “auto-update not firing”

Once QMD can spawn successfully, don’t use index.sqlite mtime as the only signal — qmd update can be a no-op if nothing changed.

A good test is:

1. Add a unique line to a memory file in that agent’s workspace
2. Wait > 5 minutes
3. Run openclaw memory search "<unique token>" --agent agent1

If you still think the interval isn’t firing after the workspace exists, paste:

ls -ld ~/.openclaw/workspace-agent1
openclaw memory status --agent agent1 --deep --index --verbose

[grave salmon]

Test completed:

1. Created autotest file at 03:26:43 UTC
2. Sent HTTP warmup call to gateway
3. Waited 9 minutes ( > 5m interval)

Result:
$ qmd search "qmd-autotest-1770694003"
No results found.

→ Auto-update NOT working even after warmup!

QMD status shows:

• 81 files indexed
• Updated: 8m ago (from manual update at 03:05)
• File created 9 minutes ago still not indexed

Evidence: Auto-update interval not firing despite warmup.
@deep elk

✅ SUCCESS!

HTTP warmup worked! After curl to /tools/invoke:

$ qmd ls workspace | grep autotest
24 B Feb 10 03:26 qmd://workspace/memory/qmd_autotest.md ✅

$ qmd get qmd://workspace/memory/qmd_autotest.md
qmd-autotest-1770694003 ✅

$ qmd status | grep Updated
Updated: 9m ago ✅

→ Auto-update IS working after HTTP warmup!

Note: Search returns no results because embedInterval=30m
hasn't fired yet. File is indexed but not embedded.

[deep elk]

Your test is very likely checking the wrong QMD index (and possibly the wrong command), so it looks like “auto-update isn’t firing” even when the gateway index is fine.

1) qmd CLI ≠ the same index OpenClaw uses (unless you set XDG vars)

OpenClaw runs QMD with per‑agent XDG dirs:

• XDG_CONFIG_HOME=~/.openclaw/agents/<agentId>/qmd/xdg-config
• XDG_CACHE_HOME=~/.openclaw/agents/<agentId>/qmd/xdg-cache (this is where index.sqlite lives)

If you run qmd … in your shell without those env vars, you’re querying QMD’s default home (typically ~/.cache/qmd/...) — not OpenClaw’s index — so you won’t see the gateway’s updates.

2) Use the correct QMD command (query) against OpenClaw’s index

Run this (replace main with the agent you’re testing if needed):

STATE_DIR="${OPENCLAW_STATE_DIR:-$HOME/.openclaw}"
export XDG_CONFIG_HOME="$STATE_DIR/agents/main/qmd/xdg-config"

export XDG_CACHE_HOME="$STATE_DIR/agents/main/qmd/xdg-cache"

qmd collection list --json
qmd query "qmd-autotest-1770694003" --json
# (if needed, target a specific collection, e.g.)
qmd query "qmd-autotest-1770694003" -c memory-dir --json

That is the only way qmd CLI will reflect what OpenClaw’s gateway is actually indexing.

3) Make sure your autotest file is actually indexable

Double-check it’s a .md file inside a collection mask, e.g.:

ls -la /root/.openclaw/workspace/memory | tail -n 20

If you created a file without .md, QMD will ignore it (your masks are **/*.md / *.md).

4) Separate issue you hit: agent1 is broken because its workspace is missing

This is why you saw:

qmd collection add failed … spawn qmd ENOENT

In this codepath, ENOENT can happen when the cwd workspace dir doesn’t exist (spawn fails because cwd is missing). Your output showed:

Workspace: ~/.openclaw/workspace-agent1 and “memory directory missing …”

Fix:

mkdir -p ~/.openclaw/workspace-agent1/memory
touch ~/.openclaw/workspace-agent1/MEMORY.md

---

If you run the XDG-scoped qmd query … above and it still doesn’t find the token after >5m, then we’ve got a real “interval not firing” bug — but right now the evidence you posted is consistent with “you queried a different QMD home/index than the gateway uses.”

[grave salmon]

HTTP tools invoke fix the bug for me
my agents told me i need to do that everytime gateway restart, is it true ?
is this a default of QMD feature ?

@deep elk

[deep elk]

Two “gotchas” with QMD make this look broken even when it isn’t:

1) Successful QMD auto-updates are basically silent

In current OpenClaw, the QMD timer (memory.qmd.update.interval / embedInterval) only logs when something fails (warnings like qmd update failed…). If qmd update succeeds, you usually won’t see anything in openclaw.log, so tail -f ... | grep qmd can look “dead”.

How to verify it’s actually running:
Run this on the gateway host and paste the output:

openclaw --version
openclaw memory status --json

In the JSON, check:

• status.backend should be "qmd" (if it’s "builtin" then QMD is not active)
• status.custom.qmd.lastUpdateAt should become a recent timestamp after QMD runs

(That lastUpdateAt is the best “proof” that the interval/onBoot update happened.)

Docs: https://docs.openclaw.ai/concepts/memory#qmd-backend-experimental

2) The QMD manager (and its interval timer) starts lazily

The interval timer is started when the QMD memory manager is initialized (i.e., when memory is actually used), not necessarily the instant the gateway process boots.

So after a gateway restart, if nothing triggers memory search, you might not see any QMD activity until the first time the agent uses memory tools.

A simple “kick” is:

• ask the agent to do a memory_search once, or
• run openclaw memory status once (this also forces the manager to initialize)

If it still doesn’t run: most common real cause = qmd not on PATH for the gateway service

When OpenClaw runs as a service/container, its PATH can differ from your shell. Then QMD fails to start and OpenClaw falls back to builtin memory.

To confirm, look for log lines like:

• qmd memory unavailable; falling back to builtin: ...

Fix options:

• Set an absolute path:

memory: {
  qmd: { command: "/absolute/path/to/qmd" }
}

• Or ensure qmd is installed for the same user that runs the gateway (and available in that service’s PATH).

About “HTTP tools invoke fixed it” / “do I need that every restart?”

That’s not a “default QMD requirement”.

What likely happened is: invoking that tool caused the agent to do a memory operation once (which initialized QMD), so QMD started working for that process lifetime. After a restart, you may need any first memory usage again to initialize it.