How do I check if qmd memory backend is being used | Friends of the Crustacean 🦞🤝 | Page 1

crystal yoke Apr 21, 2026, 9:53 PM

#

With verbose, I can see my agent keeps using exec Grep instead of using memory.

pure plinthBOT Apr 21, 2026, 9:53 PM

#

formal badgeBOT Apr 21, 2026, 9:53 PM

#

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

pure plinthBOT Apr 21, 2026, 9:53 PM

#

rocky auroraBOT Apr 21, 2026, 9:56 PM

#

Checking the docs/source now so I can answer this without guessing.

#

Short version: seeing exec grep in verbose does not mean QMD is off. It just means the model chose shell search for that turn. QMD only backs memory_search.

First, check your version:

openclaw --version

Then the best check is:

openclaw memory status --deep --agent main

What you want to see:

Provider: qmd (requested: qmd)
store path under ~/.openclaw/agents/<agentId>/qmd/...

#

no warning that qmd is missing/unavailable

Also useful:

openclaw doctor

A couple gotchas:

If exec is available, some models will still reach for grep instead of memory_search.
If this is an ACP agent (Codex/Claude Code), plugin memory tools are not exposed by default. You need:
```
openclaw config set plugins.entries.acpx.config.pluginToolsMcpBridge true
```
If you want memory to happen proactively, look at Active Memory: https://docs.openclaw.ai/concepts/active-memory
QMD docs: https://docs.openclaw.ai/concepts/memory-qmd
Memory CLI: https://docs.openclaw.ai/cli/memory

#

If you paste the output of openclaw --version and openclaw memory status --deep --agent main, I can tell you pretty quickly whether QMD is actually active or if the agent is just ignoring it.

crystal yoke Apr 22, 2026, 1:42 AM

#

totaluser@Total-Hardware:~$ openclaw memory status --deep --agent rush

🦞 OpenClaw 2026.4.15 (041266a)
I speak fluent bash, mild sarcasm, and aggressive tab-completion energy.

│
◇
Memory Search (rush)
Provider: qmd (requested: qmd)
Model: qmd
Sources: memory, sessions
Indexed: 463/11 files · 463 chunks
Dirty: no
Store: ~/.openclaw/agents/rush/qmd/xdg-cache/qmd/index.sqlite
Workspace: ~/.openclaw/rush
Dreaming: off
Embeddings: ready
By source:
memory · 454/7 files · 454 chunks
sessions · 9/4 files · 9 chunks
Vector: ready
Batch: disabled (failures 0/0)
Recall store: 5 entries · 0 promoted · 5 concept-tagged · 0 spaced · scripts=4 latin, 1 other
Recall path: ~/.openclaw/rush/memory/.dreams/short-term-recall.json
Recall updated: 2026-04-13T05:25:24.959Z
QMD audit: ~/.openclaw/agents/rush/qmd/xdg-cache/qmd/index.sqlite · 30015488 bytes · 5 collections
Dreaming artifacts: diary absent · 0 corpus files · ingestion state absent
Dream corpus: ~/.openclaw/rush/memory/.dreams/session-corpus
Dream ingestion: ~/.openclaw/rush/memory/.dreams/session-ingestion.json

totaluser@Total-Hardware:~$

also i think active memory is timing out can we trouble shoot that

rocky auroraBOT Apr 22, 2026, 1:43 AM

#

Let me check the active-memory docs/source quickly so I can give you the right knobs instead of hand-waving.

#

Yep, QMD is definitely active here.

The important bits in your output are:

Provider: qmd (requested: qmd)
Embeddings: ready
Vector: ready
QMD store at ~/.openclaw/agents/rush/qmd/...

So this part is healthy. If the agent still uses exec grep, that is the model choosing shell search, not QMD being off.

For Active Memory timeouts, I’d debug it like this:

Make sure the plugin is actually targeted at rush
Turn on:
- /verbose on
- /trace on
Set plugins.entries.active-memory.config.logging: true

#

Watch logs while reproducing:
```
openclaw logs --follow
```

What to paste back:

the 🧩 Active Memory: ... line
the 🔎 Active Memory Debug: ... line
matching log lines with active-memory: ... start / done

Most likely causes:

queryMode is too heavy, especially full
recent turn/char limits are too large
the recall model is slow
thinking is enabled for active memory
if you are testing in a thread/channel, allowedChatTypes may need "channel" because the default is only "direct"

#

Good first tuning pass for rush is:

agents: ["rush"]
allowedChatTypes: ["direct", "channel"] if you use channel/thread chats
queryMode: "message" for lowest latency
keep logging: true while tuning
keep thinking: "off"

Docs:

If you paste your plugins.entries.active-memory block plus one timeout example, I can probably pinpoint it pretty fast.

crystal yoke Apr 22, 2026, 1:44 AM

#

can you give me the commands to get the info you need

rocky auroraBOT Apr 22, 2026, 1:45 AM

#

Yep, run these in this order.

1) Active Memory config

openclaw config get plugins.entries.active-memory --json

2) Agent config (so I can confirm rush targeting / session shape)

openclaw config get agents.list --json

3) Full quick status

openclaw status --all

#

4) Live logs while you reproduce one timeout

openclaw logs --follow

Then in the chat session where you're testing:

/verbose on
/trace on

Then send one message that should clearly recall memory.

After that, paste back:

the output of commands 1-3
the 🧩 Active Memory: ... line
the 🔎 Active Memory Debug: ... line

#

the relevant openclaw logs --follow lines from the moment you sent that test message

You already gave the important QMD check, so I mostly need the Active Memory config + one reproduced timeout now.

crystal yoke Apr 22, 2026, 1:46 AM

#

totaluser@Total-Hardware:~$ openclaw config get plugins.entries.active-memory --json
{
"enabled": true,
"config": {
"agents": [
"main",
"forge",
"rush",
"scout",
"vital"
],
"allowedChatTypes": [
"direct",
"channel"
],
"model": "ollama/qwen3:14b",
"queryMode": "recent",
"promptStyle": "balanced",
"timeoutMs": 15000,
"maxSummaryChars": 220,
"logging": true
}
}
totaluser@Total-Hardware:~$ openclaw config get agents.list --json
[
{
"id": "main",
"memorySearch": {
"qmd": {
"extraCollections": [
{
"path": "/home/totaluser/.openclaw/shared/health_research",
"name": "health-research"
}
]
}
},
"heartbeat": {},
"subagents": {
"allowAgents": [
"forge",
"scout",
"vital",
"sentinel",
"alfred"
]
}
},
{
"id": "forge",
"name": "Forge",
"workspace": "/home/totaluser/.openclaw/forge",
"agentDir": "/home/totaluser/.openclaw/agents/forge/agent",
"heartbeat": {
"every": "1h"
}
},
{
"id": "scout",
"name": "Scout",
"workspace": "/home/totaluser/.openclaw/scout",
"agentDir": "/home/totaluser/.openclaw/agents/scout/agent",
"memorySearch": {
"qmd": {
"extraCollections": [
{
"path": "/home/totaluser/.openclaw/shared/health_research",
"name": "health-research"
}
]
}
},
"heartbeat": {
"every": "1h"
}
},
{
"id": "vital",
"name": "vital",
"workspace": "/home/totaluser/.openclaw/vital",
"agentDir": "/home/totaluser/.openclaw/agents/vital/agent",
"memorySearch": {
"qmd": {
"extraCollections": [
{
"path":

this is part 1/2

#

"/home/totaluser/.openclaw/shared/health_research",
"name": "health-research"
}
]
}
},
"heartbeat": {
"every": "6h"
}
},
{
"id": "sentinel",
"name": "sentinel",
"workspace": "/home/totaluser/.openclaw/sentinel",
"agentDir": "/home/totaluser/.openclaw/agents/sentinel/agent",
"heartbeat": {
"every": "1h"
}
},
{
"id": "alfred",
"name": "Alfred",
"workspace": "/home/totaluser/.openclaw/alfred",
"agentDir": "/home/totaluser/.openclaw/agents/alfred/agent",
"heartbeat": {
"every": "15m",
"target": "telegram",
"accountId": "forge"
}
},
{
"id": "rush",
"name": "rush",
"workspace": "/home/totaluser/.openclaw/rush",
"agentDir": "/home/totaluser/.openclaw/agents/rush/agent",
"memorySearch": {
"qmd": {
"extraCollections": [
{
"path": "yr-knowledge"
}
]
}
}
},
{
"id": "cipher",
"name": "Cipher",
"workspace": "/home/totaluser/.openclaw/cipher",
"agentDir": "/home/totaluser/.openclaw/agents/cipher/agent",
"heartbeat": {
"every": "1h"
}
}
]
totaluser@Total-Hardware:~$

rocky auroraBOT Apr 22, 2026, 1:47 AM

#

You resent part 1, but I already have enough for the first fix.

The most likely bottleneck is this line:

"model": "ollama/qwen3:14b"

That makes Active Memory run its own blocking recall pass on a local 14B model, which is a very plausible way to hit timeoutMs: 15000.

Try this first:

openclaw config unset plugins.entries.active-memory.config.model
openclaw config set plugins.entries.active-memory.config.queryMode message
openclaw gateway restart

#

Then test again with:

/verbose on
/trace on

Send one message that should recall memory.

If it still times out after that, paste:

the new 🧩 Active Memory: ... line
the new 🔎 Active Memory Debug: ... line
the relevant openclaw logs --follow lines

I’m pretty confident this is an Active Memory model latency issue, not a QMD issue.

#

Perfect, that confirms the wiring is fine:

rush is targeted by Active Memory
channel chats are allowed
QMD is healthy

So the config problem is probably not targeting/scope. The slow part is still most likely the dedicated Active Memory model.

I’d stop dumping config now and try the fix:

openclaw config unset plugins.entries.active-memory.config.model
openclaw config set plugins.entries.active-memory.config.queryMode message
openclaw gateway restart

Then test once with:

#

/verbose on
/trace on

If it still times out, send me just these 3 things, not the full config again:

🧩 Active Memory: ...
🔎 Active Memory Debug: ...
the matching openclaw logs --follow lines

That should get us to the real failure pretty quickly.

crystal yoke Apr 22, 2026, 1:48 AM

#

how can i check if its able to access ollame?

rocky auroraBOT Apr 22, 2026, 1:49 AM

#

Yep, quickest checks are these:

1) Check Ollama itself

ollama list

You want to see your model there, especially qwen3:14b.

2) Check OpenClaw can see the Ollama provider

openclaw models list --provider ollama

3) Run a live provider probe from OpenClaw

#

openclaw models status --probe --probe-provider ollama --agent rush

What “good” looks like:

ollama list shows the model
openclaw models list --provider ollama shows Ollama models
openclaw models status --probe --probe-provider ollama --agent rush comes back ok, not timeout, auth, or no_model

4) Check the Ollama config OpenClaw is using

openclaw config get models.providers.ollama --json

If there’s a baseUrl, it should be like:

#

http://127.0.0.1:11434

and not /v1.

5) If you want to catch runtime failures while testing Active Memory

openclaw logs --follow

Then reproduce one turn and look for ollama, active-memory, or timeout lines.

If you paste the outputs of 1, 3, and 4, I can tell you pretty quickly whether OpenClaw can actually reach Ollama or if it’s falling over in the recall step.

crystal yoke Apr 22, 2026, 1:55 AM

#

totaluser@Total-Hardware:~$ ollama list
NAME ID SIZE MODIFIED
qwen3:14b bdbd181c33f2 9.3 GB 5 weeks ago
llama3.2:3b a80c4f17acd5 2.0 GB 2 months ago
totaluser@Total-Hardware:~$ openclaw models list --provider ollama

🦞 OpenClaw 2026.4.15 (041266a)
I can grep it, git blame it, and gently roast it—pick your coping mechanism.

Model Input Ctx Local Auth Tags
ollama/qwen3:14b text 40k yes yes fallback#3
totaluser@Total-Hardware:~$ openclaw models status --probe --probe-provider ollama --agent rush

🦞 OpenClaw 2026.4.15 (041266a)
Shell yeah—I'm here to pinch the toil and leave you the glory.

│
◇
Config : ~/.openclaw/openclaw.json
Agent dir : ~/.openclaw/agents/rush/agent
Default (defaults): minimax-portal/MiniMax-M2.7
Fallbacks (3) (defaults): minimax-portal/MiniMax-M2.7, minimax/MiniMax-M2.7, ollama/qwen3:14b
Image model (defaults): minimax-portal/image-01
Image fallbacks (0) (defaults): -
Aliases (8) : minimax-m2.1 -> minimax-portal/MiniMax-M2.1, minimax-m2.5 -> minimax-portal/MiniMax-M2.5, Minimax -> minimax/MiniMax-M2.5, minimax-m2.7 -> minimax-portal/MiniMax-M2.7, minimax-m2.5-highspeed -> minimax-portal/MiniMax-M2.5-highspeed, minimax-m2.5-lightning -> minimax-portal/MiniMax-M2.5-Lightning, minimax-image -> minimax-portal/image-01, minimax-m2.7-highspeed -> minimax-portal/MiniMax-M2.7-highspeed
Configured models (9): minimax-portal/MiniMax-M2.1, minimax-portal/MiniMax-M2.5, minimax/MiniMax-M2.5, minimax/MiniMax-M2.7, minimax-portal/MiniMax-M2.5-highspeed, minimax-portal/MiniMax-M2.5-Lightning, minimax-portal/image-01, minimax-portal/MiniMax-M2.7, minimax-portal/MiniMax-M2.7-highspeed

part 1 of 3

#

Auth overview
Auth store : ~/.openclaw/agents/rush/agent/auth-profiles.json
Shell env : off
Providers w/ OAuth/tokens (2): minimax-portal (1), openai-codex (1)

minimax effective=profiles:~/.openclaw/agents/main/agent/auth-profiles.json | profiles=1 (oauth=0, token=0, api_key=1) | minimax:default=sk-cp-fX...La8yPx3Q
minimax-portal effective=profiles:~/.openclaw/agents/main/agent/auth-profiles.json | profiles=1 (oauth=1, token=0, api_key=0) | minimax-portal:default=OAuth | models.json=marker(minimax-oauth) | source=models.json: ~/.openclaw/agents/rush/agent/models.json
ollama effective=profiles:~/.openclaw/agents/main/agent/auth-profiles.json | profiles=1 (oauth=0, token=0, api_key=1) | ollama:default=marker(ollama-local) | models.json=OL...EY | source=models.json: ~/.openclaw/agents/rush/agent/models.json
openai-codex effective=profiles:~/.openclaw/agents/main/agent/auth-profiles.json | profiles=1 (oauth=1, token=0, api_key=0) | openai-codex:default=OAuth

OAuth/token status
[openai-codex] Token refresh failed: 401 {
"error": {
"message": "Your refresh token has already been used to generate a new access token. Please try signing in again.",
"type": "invalid_request_error",
"param": null,
"code": "refresh_token_reused"
}
}

minimax-portal
- minimax-portal:default ok expires in 349d
openai-codex
- openai-codex:default ok expires in 0m

Auth probes
┌──────────────────┬────────────────────────┬──────────────────────────────────┐
│ Model │ Profile │ Status │
├──────────────────┼────────────────────────┼──────────────────────────────────┤
│ ollama/qwen3:14b │ ollama:default (api_ │ timeout · 33.9s │
│ │ key) │ ↳ LLM request timed out. │
└──────────────────┴────────────────────────┴──────────────────────────────────┘
Probed 1 target in 46.5s
totaluser@Total-Hardware:~$

sorry actually this is the last part so just 2

rocky auroraBOT Apr 22, 2026, 1:55 AM

#

So far this looks good. OpenClaw can see Ollama and it can see ollama/qwen3:14b.

That means the problem is probably not “Ollama is invisible to OpenClaw”.

Send parts 2 and 3, especially the bottom of:

openclaw models status --probe --probe-provider ollama --agent rush

I mainly want the actual probe result / status lines, because that’s where it’ll say ok, timeout, no_model, etc.

#

Nice, that’s the smoking gun.

Diagnosis:

OpenClaw can discover Ollama and the model.
But actual inference against ollama/qwen3:14b is timing out.
Your probe took 33.9s, while Active Memory is set to 15s, so Active Memory timing out makes perfect sense.

So this is not a QMD problem. It’s Ollama model latency in the Active Memory path.

Best next step, recommended

Let Active Memory stop using the slow local 14B model:

openclaw config unset plugins.entries.active-memory.config.model
openclaw config set plugins.entries.active-memory.config.queryMode message
openclaw gateway restart

#

That makes Active Memory much lighter.

If you want to keep Ollama for Active Memory

You have two knobs:

Option A, smaller local model

Point Active Memory at your smaller Ollama model instead of the 14B one.

Option B, longer timeout

openclaw config set plugins.entries.active-memory.config.timeoutMs 45000 --strict-json
openclaw gateway restart

I’d only do this if you’re okay with slower replies.

One unrelated thing

#

This part is separate from the Active Memory timeout:

openai-codex ... refresh_token_reused

That is an auth issue for Codex, but it is not the cause of the Ollama timeout.

So at this point, I’d recommend:

unset the dedicated Active Memory model
set queryMode to message
restart
retest with /verbose on and /trace on

Docs:

#

If that fixes it, please right-click the solution message → Apps → ✅ Mark Solution so Answer Overflow can index it.

crystal yoke Apr 22, 2026, 1:57 AM

#

but earlier it was running perfectly fine. so does this mean that openclaw is able to actually use ollama? or is ollama entirely timing out

rocky auroraBOT Apr 22, 2026, 1:57 AM

#

It means OpenClaw can reach and use Ollama, but this specific live inference call timed out.

So the situation is:

Not totally broken: OpenClaw can discover Ollama, see qwen3:14b, and try to call it.
Currently too slow/unresponsive: the actual probe request to qwen3:14b timed out.
Active Memory is stricter: your Active Memory timeout is only 15s, so even a slow but eventually successful Ollama response would still look like a timeout there.

So I would describe it as:

Ollama is accessible, but current inference latency is bad enough to break Active Memory.

That also explains why it may have worked earlier. Common reasons:

model was warm earlier, cold now
host is under more load now
Ollama unloaded the model and had to reload it
another local task is competing for CPU/RAM

#

Quick sanity check:

ollama ps
ollama run qwen3:14b "Reply with only OK"

Then rerun:

openclaw models status --probe --probe-provider ollama --agent rush

If it works after that, it’s probably a warmup / latency issue, not “Ollama is unusable”.

crystal yoke Apr 22, 2026, 2:32 AM

#

so would the error be fixed if i ran a smaller model?

rocky auroraBOT Apr 22, 2026, 2:32 AM

#

Probably, yes, if the timeout is mainly inference latency from qwen3:14b.

A smaller model often fixes this kind of Active Memory timeout because that path is blocking and only has 15s to finish.

I’d phrase it like this:

If the problem is “14B is too slow” → a smaller model likely fixes it
If the problem is “Ollama itself is hung / overloaded” → a smaller model might still fail

A very clean test is:

openclaw config set plugins.entries.active-memory.config.model "ollama/llama3.2:3b"
openclaw config set plugins.entries.active-memory.config.queryMode message
openclaw gateway restart

#

Then retest with /verbose on and /trace on.

If that works, you’ve basically confirmed the issue was model size / latency.

If you want the safest option overall, I still slightly prefer:

openclaw config unset plugins.entries.active-memory.config.model
openclaw config set plugins.entries.active-memory.config.queryMode message
openclaw gateway restart

That removes the local Ollama bottleneck from Active Memory entirely.

crystal yoke Apr 22, 2026, 2:34 AM

#

but that was causing api request timeouts cause it was too much for active memory to be doing all the time

rocky auroraBOT Apr 22, 2026, 2:34 AM

#

Yep, that makes sense.

So the tradeoff is basically:

unset model → Active Memory falls back to your normal provider, but now it makes more remote API calls
big local model → fewer remote calls, but local inference is too slow and times out
small local model → usually the best middle ground

In your case, I’d try exactly that middle ground:

openclaw config set plugins.entries.active-memory.config.model "ollama/llama3.2:3b"
openclaw config set plugins.entries.active-memory.config.queryMode message
openclaw config set plugins.entries.active-memory.config.timeoutMs 20000 --strict-json
openclaw gateway restart

#

Why:

llama3.2:3b should be much lighter than qwen3:14b
queryMode: "message" reduces work per turn
20000ms gives a little breathing room without making replies feel too sluggish

If that still feels too heavy, the next step is not “bigger timeout forever”, it’s reducing how often Active Memory runs, for example only on the agent(s) that actually need it.

If this 3B test works, you’ve found the sweet spot.

crystal yoke Apr 22, 2026, 2:36 AM

#

can we try to manually trigger active memory and trace where it fails?

rocky auroraBOT Apr 22, 2026, 2:37 AM

#

Yep, and this is the best way to trace it cleanly.

1) Turn on Active Memory transcript persistence

openclaw config set plugins.entries.active-memory.config.persistTranscripts true --strict-json
openclaw config set plugins.entries.active-memory.config.logging true --strict-json
openclaw config set plugins.entries.active-memory.config.queryMode message
openclaw gateway restart

2) In the chat session, turn on tracing

/verbose on
/trace on
/trace raw

#

3) Watch logs in a terminal

openclaw logs --follow

4) Send one message that should clearly trigger memory

For example, something that obviously refers to prior preferences/history.

5) Inspect the latest Active Memory transcript

latest="$(ls -t ~/.openclaw/agents/rush/sessions/active-memory/*.jsonl | head -1)"
echo "$latest"
tail -n 120 "$latest"

What I want from that run:

#

the 🧩 Active Memory: ... line
the 🔎 Active Memory Debug: ... line
the relevant openclaw logs --follow lines
the last ~120 lines of the latest Active Memory transcript

That should show us whether it fails at:

model call startup
memory_search
memory_get
timeout before tool completion
or bad model output

After debugging, I’d turn transcript persistence back off so it doesn’t pile up:

openclaw config set plugins.entries.active-memory.config.persistTranscripts false --strict-json

#

openclaw gateway restart

crystal yoke Apr 22, 2026, 2:47 AM

#

both rush and main say htis

totaluser@Total-Hardware:~$ latest="$(ls -t ~/.openclaw/agents/main/sessions/active-memory/.jsonl | head -1)"
echo "$latest"
tail -n 120 "$latest"
ls: cannot access '/home/totaluser/.openclaw/agents/main/sessions/active-memory/.jsonl': No such file or directory

tail: cannot open '' for reading: No such file or directory
totaluser@Total-Hardware:~$

rocky auroraBOT Apr 22, 2026, 2:48 AM

#

That error actually tells us something useful: there is no persisted Active Memory transcript there yet.

So one of these is true:

persistTranscripts is not actually enabled
the gateway was not restarted after enabling it
Active Memory did not run after the restart

Check it in this order:

1) Verify the flag is really on

openclaw config get plugins.entries.active-memory.config.persistTranscripts --json

It should print:

#

true

2) Restart the gateway

openclaw gateway restart

3) Watch logs

openclaw logs --follow

4) In chat, force one fresh test

#

/verbose on
/trace on
/trace raw

Then send one message that should clearly hit memory.

5) Search for any persisted transcript more robustly

find ~/.openclaw/agents/rush/sessions -maxdepth 2 -type f -name '*.jsonl' | sort | tail -20

If Active Memory really ran with persistence on, you should see something under:

#

~/.openclaw/agents/rush/sessions/active-memory/

Key interpretation

If logs show active-memory: ... start / done, but no file appears, then persistence isn’t being applied.
If there are no active-memory log lines and no <active_memory_plugin> block in /trace raw, then Active Memory never ran on that turn.

If you want, paste the output of:

openclaw config get plugins.entries.active-memory.config.persistTranscripts --json

and the first active-memory log lines after a fresh test. That should narrow it down fast.

crystal yoke Apr 22, 2026, 2:52 AM

#

totaluser@Total-Hardware:~$ find ~/.openclaw/agents/rush/sessions -maxdepth 2 -type f -name '*.jsonl' | sort | tail -20
/home/totaluser/.openclaw/agents/rush/sessions/37fb7e01-4f79-4985-9c53-57c9205f199c.jsonl
/home/totaluser/.openclaw/agents/rush/sessions/4a6378e9-1b13-48de-b9d3-81409050a8de.jsonl
/home/totaluser/.openclaw/agents/rush/sessions/92bcb0ce-2d05-4144-8896-60ab98f5a5cb.jsonl
/home/totaluser/.openclaw/agents/rush/sessions/a98e222f-945e-4540-ae8a-9bc01bf0d885.jsonl
totaluser@Total-Hardware:~$

rocky auroraBOT Apr 22, 2026, 2:52 AM

#

Yep, those are just the normal session transcripts.

What I wanted to see was something like:

~/.openclaw/agents/rush/sessions/active-memory/<id>.jsonl

Since there’s no active-memory/ subfolder at all, transcript persistence is still not taking effect.

Run these next:

openclaw config get plugins.entries.active-memory.config.persistTranscripts --json
openclaw config get plugins.entries.active-memory.config.transcriptDir --json

#

Then:

openclaw gateway restart

After one fresh test message, check again with:

find ~/.openclaw/agents/rush/sessions -maxdepth 2 -type f -name '*.jsonl' | sort

Also, since we’re not getting the persisted sub-agent transcript yet, grab the latest normal session file and see whether Active Memory even ran:

latest="$(find ~/.openclaw/agents/rush/sessions -maxdepth 1 -type f -name '*.jsonl' | sort | tail -1)"

#

echo "$latest"
grep -nE 'Active Memory|active_memory_plugin|memory_search|timeout' "$latest" | tail -40

At this point I’m trying to answer one binary question first:

Did Active Memory actually run?
or is the persistence config just not applying?

Paste those 3 outputs and we should be able to pin it down.

crystal yoke Apr 22, 2026, 2:54 AM

#

totaluser@Total-Hardware:~$ openclaw config get plugins.entries.active-memory.config.persistTranscripts --json
openclaw config get plugins.entries.active-memory.config.transcriptDir --json
true
Config path not found: plugins.entries.active-memory.config.transcriptDir
totaluser@Total-Hardware:~$

rocky auroraBOT Apr 22, 2026, 2:55 AM

#

Good, that actually helps:

persistTranscripts = true ✅
missing transcriptDir is fine here, it just means it should use the default active-memory directory

So the next question is not config anymore, it’s:

Did Active Memory actually run on the last turn?

Run this next:

latest="$(find ~/.openclaw/agents/rush/sessions -maxdepth 1 -type f -name '*.jsonl' | sort | tail -1)"
echo "$latest"
grep -nE 'Active Memory|active_memory_plugin|memory_search|timeout' "$latest" | tail -40

#

And also, to remove any ambiguity, set the transcript dir explicitly and restart:

openclaw config set plugins.entries.active-memory.config.transcriptDir "active-memory"
openclaw gateway restart

Then do one fresh test message, and check again with:

find ~/.openclaw/agents/rush/sessions -maxdepth 2 -type f -name '*.jsonl' | sort

If we still don’t get an active-memory/ file after that, then we’re probably looking at:

Active Memory never running on that turn, or
a bug in transcript persistence for the plugin

#

Paste the grep ... "$latest" output next, that should tell us a lot.

astral birch Apr 22, 2026, 3:02 AM

#

That exec grep fallback is a known QMD gotcha — it means the memory hook isn't intercepting the session properly. A few things to check:

Run openclaw plugins list and confirm QMD shows as active (not just installed)
Check your agent config — QMD needs memory: { backend: "qmd" } explicitly set, it won't auto-activate from install
Look at the gateway logs during a session — you should see QMD intercept calls if it's working

If you've verified all three and it's still grenading to grep, you might be hitting the hook ordering issue where another plugin is eating the memory invocation first.

For what it's worth — I switched to mr-memory a while back partly because this exact ambiguity was killing me. It stores explicitly per-message and you can query it directly, so there's no "is it actually running?" guessing. Different philosophy (cloud vs local) but at least you know when it's working: openclaw plugins install mr-memory

Not saying abandon QMD if local is your priority, just — the silent fallback problem is real and worth knowing your options.

rocky auroraBOT Apr 22, 2026, 3:02 AM

#

Tiny correction so this thread doesn’t go sideways:

QMD is already active here. We have openclaw memory status --deep --agent rush showing Provider: qmd (requested: qmd), plus healthy QMD index/audit output.
QMD is a memory backend, not a standalone plugin you verify via openclaw plugins list.
The current failure we traced is not “QMD isn’t intercepting”. It’s this:

openclaw models status --probe --probe-provider ollama --agent rush
→ ollama/qwen3:14b ... timeout · 33.9s

So the thing actually timing out is the Active Memory model call to Ollama, while Active Memory itself is set to 15s.

So for this thread, the likely fix is still:

use a smaller/faster Active Memory model, or
unset the dedicated Active Memory model and reduce queryMode

#

Not swap memory backends.

Docs:

crystal yoke Apr 22, 2026, 3:03 AM

#

after all that im not getting files for active memory

totaluser@Total-Hardware:~$ find ~/.openclaw/agents/rush/sessions -maxdepth 2 -type f -name '*.jsonl' | sort
/home/totaluser/.openclaw/agents/rush/sessions/37fb7e01-4f79-4985-9c53-57c9205f199c.jsonl
/home/totaluser/.openclaw/agents/rush/sessions/4a6378e9-1b13-48de-b9d3-81409050a8de.jsonl
/home/totaluser/.openclaw/agents/rush/sessions/92bcb0ce-2d05-4144-8896-60ab98f5a5cb.jsonl
/home/totaluser/.openclaw/agents/rush/sessions/a98e222f-945e-4540-ae8a-9bc01bf0d885.jsonl
totaluser@Total-Hardware:~$

rocky auroraBOT Apr 22, 2026, 3:04 AM

#

Yeah, at this point I’d stop chasing the file path.

Given:

persistTranscripts = true
no sessions/active-memory/*.jsonl
and you’ve already restarted / retested

this is now most likely one of these:

Active Memory is not actually running on the turn
Active Memory is running, but transcript persistence is bugged on 2026.4.15

The clean discriminator is:

if you see a chat line like 🧩 Active Memory: ... or /trace raw shows an <active_memory_plugin> block, then Active Memory did run
if it ran and still no files are written, that’s bug territory

#

So I’d do one last minimal check:

/verbose on
/trace raw

Send one message that should clearly trigger memory.

Then:

If you get 🧩 Active Memory: but still no files, I’d call that a bug and file it here: https://github.com/openclaw/openclaw/issues
If you do not get 🧩 Active Memory: at all, then the problem is that Active Memory is not firing, not transcript persistence

Honestly, with everything you’ve already gathered, I think you’ve got enough to file a solid issue if you want:

QMD backend confirmed active
Ollama provider visible
Ollama live probe timing out

#

persistTranscripts=true
no active-memory/ transcript files being created

If this thread is solved enough for now, please right-click the solution message → Apps → ✅ Mark Solution so Answer Overflow can index it.

crystal yoke Apr 22, 2026, 3:05 AM

#

it is running its just timing out. i get the active memory message, it just says timed out

rocky auroraBOT Apr 22, 2026, 3:05 AM

#

Perfect, that closes the loop.

So the situation is now pretty clear:

Active Memory is running
QMD is fine
the failure is just the Active Memory model timing out
the missing persisted transcript files are a separate quirk/bug, not the root cause of this issue

So I would stop debugging “is it running?” and just treat this as a latency problem.

Best next test

openclaw config set plugins.entries.active-memory.config.model "ollama/llama3.2:3b"
openclaw config set plugins.entries.active-memory.config.queryMode message

#

openclaw config set plugins.entries.active-memory.config.timeoutMs 20000 --strict-json
openclaw gateway restart

Why:

smaller model
less context per Active Memory run
slightly more timeout headroom

If that still says timed out, then the conclusion is basically:

local Ollama is too slow for your current Active Memory setup on this machine

At that point your options are:

keep a smaller local model
increase timeout more

#

reduce how often Active Memory runs
stop using a dedicated local Active Memory model

So yes, you’ve narrowed it down pretty well now 👍

If this fixed it or got you unstuck, please right-click the solution message → Apps → ✅ Mark Solution so Answer Overflow can index it.

crystal yoke Apr 22, 2026, 3:06 AM

#

can we move it to qwen3 4b

#

i need to add it to global models though right?

rocky auroraBOT Apr 22, 2026, 3:06 AM

#

Yep, assuming the Ollama tag is qwen3:4b, try this:

ollama pull qwen3:4b
ollama list
openclaw config set plugins.entries.active-memory.config.model "ollama/qwen3:4b"
openclaw config set plugins.entries.active-memory.config.queryMode message
openclaw config set plugins.entries.active-memory.config.timeoutMs 20000 --strict-json
openclaw gateway restart

Then test again with:

/verbose on
/trace on

#

If ollama pull qwen3:4b fails, Ollama will usually tell you the exact tag it expects, and then just swap that into the config set command.

If this works, please right-click the solution message → Apps → ✅ Mark Solution so Answer Overflow can index it.

#

Probably not.

In your setup, OpenClaw already looks like it’s auto-discovering local Ollama models, so the normal flow is just:

ollama pull qwen3:4b
openclaw models list --provider ollama

If ollama/qwen3:4b shows up there, you can use it directly in:

openclaw config set plugins.entries.active-memory.config.model "ollama/qwen3:4b"

You only need to add it manually to global models if you’ve configured an explicit models.providers.ollama block that disables auto-discovery.

#

So I’d do this first:

ollama pull qwen3:4b
openclaw models list --provider ollama

If it appears, you’re good. If it does not appear, then yeah, we should check whether your Ollama models are being manually defined.

crystal yoke Apr 22, 2026, 4:21 AM

#

can i disable active memory for now

rocky auroraBOT Apr 22, 2026, 4:21 AM

#

Yep.

Just for the current chat/session:

/active-memory off

Globally, for all sessions:

/active-memory off --global

If you want to do it from CLI instead:

openclaw config set plugins.entries.active-memory.config.enabled false --strict-json

#

openclaw gateway restart

That disables Active Memory, but it does not disable QMD itself. Your normal memory backend can still stay on.

crystal yoke Apr 22, 2026, 4:27 AM

#

how do i ensure that my agent uses qmd memory instead of exec tools to search

rocky auroraBOT Apr 22, 2026, 4:32 AM

#

Short version: QMD does not replace exec. It powers memory_search.

So if exec is available, the model can still decide to use grep unless you constrain it.

If you want a soft preference

Keep QMD enabled, and add guidance in the agent instructions like:

When searching prior notes or memory, use memory_search/memory_get first.
Only use exec grep for workspace files when memory_search is not appropriate.

That helps, but it is not a guarantee.

If you want a hard guarantee

Deny exec for that agent, so it can’t fall back to grep at all.

#

Docs-confirmed pattern is:

{
  agents: {
    list: [
      {
        id: "rush",
        tools: {
          deny: ["exec"],
        },
      },
    ],
  },
}

crystal yoke Apr 22, 2026, 4:45 AM

#

but when im asking it to search for something that i KNOW is in memory, it still uses exec.

rocky auroraBOT Apr 22, 2026, 4:46 AM

#

Yeah, that’s the frustrating part.

“It’s in memory” and “the model chooses memory_search” are two different things.

So I’d split it cleanly:

1) Prove QMD can find it

Run this with a phrase you know exists:

openclaw memory search --agent rush --query "exact thing you expect" --max-results 5

If that returns the memory

Then QMD/indexing is fine, and the problem is tool choice.
In that case, the model is still choosing exec even though memory works.

#

If that does not return the memory

Then this is actually a memory retrieval/indexing issue, not just tool-choice.

2) If it’s tool-choice, the honest answer is:

You cannot fully guarantee “use QMD instead of grep” while leaving exec available.

Your options are:

Soft preference: tell the agent to use memory_search first
Hard guarantee: deny exec for that agent
Most reliable automatic path: use Active Memory with a fast enough model

So if openclaw memory search finds it, but the agent still greps, that means:

QMD is working, the model is just making a bad tool decision.

If you paste one openclaw memory search --agent rush --query "..." result, I can tell you immediately which side of the line you’re on.

crystal yoke Apr 22, 2026, 4:54 AM

#

yeah grep worked

rocky auroraBOT Apr 22, 2026, 4:55 AM

#

grep working only proves the text exists on disk, not that QMD retrieval found it.

The decisive check is still:

openclaw memory search --agent rush --query "the thing you expect" --max-results 5

If that finds it, QMD is working and the model is just choosing exec
If that does not find it, then the issue is memory retrieval/indexing

So I need the openclaw memory search ... result, not the grep result.

crystal yoke Apr 22, 2026, 4:55 AM

#

sorry not grep the memory search worked. so are you saying that i should just use a soft preference?

rocky auroraBOT Apr 22, 2026, 4:56 AM

#

Yep, I’d start with a soft preference.

Since openclaw memory search worked, that means:

QMD is working
the issue is just tool choice

So if you still want the agent to keep exec for normal tasks, a soft rule is the best first move:

When searching for prior notes, remembered facts, or past session context, use memory_search/memory_get first.
Use exec-based search only for live workspace files or when memory_search clearly does not fit.

I’d only move to a hard deny on exec if you really want to force memory behavior, because that can make the agent worse at other tasks.

So my recommendation is:

#

soft preference first
if it still ignores memory too often, then
deny exec for rush

That’s the cleanest path now that we know QMD itself is fine.

crystal yoke Apr 22, 2026, 4:58 AM

#

can you make the prompt say that for ALL references to files or info, use memory search to find the file or info, then continue from there. but memory search should be used as the default for everything. grep is LAST minute basically.

rocky auroraBOT Apr 22, 2026, 4:58 AM

#

Yep, I’d put something like this in the agent instructions / AGENTS.md:

## Memory-first retrieval policy

Use `memory_search` as the default starting point for all requests involving files, notes, remembered facts, prior conversations, paths, configs, code snippets, IDs, or other stored information.

Workflow:
1. Start with `memory_search` for any request that may refer to previously seen or indexed information.
2. If `memory_search` returns relevant results, use `memory_get` or the returned file references to continue.
3. Only use exec-based search tools (`grep`, `rg`, `find`, `ls`, etc.) as a fallback when:
   - `memory_search` returns nothing relevant,
   - the user explicitly asks for a live workspace/filesystem search,
   - or the task requires current on-disk state that memory may not contain.

Rules:

#

- Prefer memory over shell search by default.
- Do not start with `grep`/`rg` when the request could plausibly be answered from memory.
- Treat exec-based search as a last resort for retrieval, not the first step.

I’d maybe add one more line to make it really blunt:

When in doubt, search memory first.

That should bias it pretty hard without breaking normal file work.

One important caveat though: this is still a preference, not hard enforcement. If you want I can help you turn that into a stricter version too.

crystal yoke Apr 22, 2026, 5:05 AM

#

can you phrase is as not a request but a requirement really

rocky auroraBOT Apr 22, 2026, 5:05 AM

#

Yep, make it explicit like this:

## Mandatory memory-first retrieval policy

This is a requirement, not a preference.

For any request involving files, notes, remembered facts, prior conversations, paths, configs, code snippets, IDs, or other stored information, you MUST start with `memory_search`.

Required workflow:
1. First call `memory_search`.
2. If relevant results are returned, use `memory_get` or the returned references to continue.
3. Only use exec-based search tools (`grep`, `rg`, `find`, `ls`, etc.) if and only if:
   - `memory_search` returned no relevant results,
   - the user explicitly requested a live filesystem/workspace search,
   - or the task requires current on-disk state that memory cannot provide.

#How do I check if qmd memory backend is being used

Best next step, recommended

If you want to keep Ollama for Active Memory

Option A, smaller local model

Option B, longer timeout

One unrelated thing

1) Turn on Active Memory transcript persistence

2) In the chat session, turn on tracing

3) Watch logs in a terminal

4) Send one message that should clearly trigger memory

5) Inspect the latest Active Memory transcript

1) Verify the flag is really on

2) Restart the gateway

3) Watch logs

4) In chat, force one fresh test

5) Search for any persisted transcript more robustly

Key interpretation

Best next test

If you want a soft preference

If you want a hard guarantee

1) Prove QMD can find it

If that returns the memory

If that does not return the memory

2) If it’s tool-choice, the honest answer is: