Complete Reset on Dreaming Pipeline? | Friends of the Crustacean 🦞🤝 | Page 1

worthy summit Apr 14, 2026, 10:52 AM

#

@main marten , my dreaming is a mess. Corrupt output, dreams every half hour, nothing being promoted despite over 2,000 candidates.

I’ve followed other dreaming-related threads here in Help, but I feel like I am just stuck in a loop. I’m on v2026.4.12, so I should have all the dreaming-related fixes now, but I suspect that the data pipeline for dreaming is massively corrupted.

Is there a way to clear that pipeline entirely and rebuild it?

abstract jackalBOT Apr 14, 2026, 10:52 AM

#

forest auroraBOT Apr 14, 2026, 10:52 AM

#

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

abstract jackalBOT Apr 14, 2026, 10:52 AM

#

main martenBOT Apr 14, 2026, 10:56 AM

#

Let me verify the actual docs path and then I’ll check whether dreaming has a documented reset path or if this is more of a manual cleanup situation.

#

Yeah, there is a supported repair path for this.

It is not a full MEMORY.md wipe, but it does reset the derived dreaming corpus by archiving the contaminated dream artifacts and letting them rebuild.

Start with these, in this order:

pnpm openclaw --version
pnpm openclaw memory status --deep
pnpm openclaw memory status --fix
pnpm openclaw doctor --fix

A couple important bits:

memory status --fix repairs stale recall/promotion artifacts, and on current builds it can also repair contaminated dreaming artifacts.
The dreaming repair path archives the dream corpus / ingestion state, so it is a recoverable reset, not a blind delete.

#

If you are seeing dreams every 30 minutes, that also strongly suggests your dreaming.frequency is set that way. The default is 0 3 * * *, so please paste your current:
plugins.entries.memory-core.config.dreaming.frequency

For the “2,000 candidates, nothing promotes” part, also run:

pnpm openclaw memory promote --limit 10
pnpm openclaw memory promote-explain "<one candidate snippet>"

That will tell us whether this is corruption, or just threshold gating (minScore, minRecallCount, minUniqueQueries).

Docs:

#

If you paste the outputs from the 4 commands above plus your dreaming.frequency, I can help narrow it down fast.

worthy summit Apr 14, 2026, 10:59 AM

#

Dreaming frequency is once per day, at 10:30 PM. The half-hour dream sequences did stop after update to v2026.4.12 (and I see others ran into that—an idempotency bug?), but I have dozens upon dozens of those cluttering up the dream diary and, I imagine, compounding the data pipeline problem.

main martenBOT Apr 14, 2026, 11:00 AM

#

That actually helps a lot.

If the cadence is back to once/day now, then the half-hour storm was probably the old bug, not your current scheduler. Also, the Dream Diary itself is not a promotion source, so the duplicate diary spam is ugly but should not be what blocks promotion.

What I’d worry about is the derived dreaming state under memory/.dreams/, especially the session corpus / ingestion state.

I’d do this next:

pnpm openclaw memory status --fix
pnpm openclaw memory status --deep
pnpm openclaw doctor --fix

Why this path:

memory status --fix is the supported repair path for stale recall/promotion artifacts

#

on current builds it can also archive contaminated dreaming artifacts and reset the derived dream corpus state
that is much better than manually nuking files first

So yes, there is basically a “clear and rebuild the dreaming pipeline” path, but it is repair/archive-based, not “rm everything”.

A couple notes:

I would not manually delete memory/.dreams/ yet
I would not worry too much about DREAMS.md clutter affecting promotion directly
if promotions still stay stuck after --fix, then run:

pnpm openclaw memory promote --limit 10
pnpm openclaw memory promote-explain "<one candidate snippet>"

If you paste the output from pnpm openclaw memory status --fix, I can tell pretty quickly whether it found the dreaming corruption path or whether this is a threshold/ranking issue instead.

#

Docs: https://docs.openclaw.ai/cli/memory https://docs.openclaw.ai/concepts/dreaming

worthy summit Apr 14, 2026, 11:26 AM

#

07:21:30 [agents/auth-profiles] synced openai-codex credentials from external cli
07:21:30 [agents/auth-profiles] synced openai-codex credentials from external cli
07:21:31 [agents/auth-profiles] synced openai-codex credentials from external cli
Memory Search (hooks)
Provider: openai (requested: openai)
Model: text-embedding-3-small
Sources: memory
Indexed: 14/15 files · 41 chunks
Dirty: no
Store: ~/.openclaw/memory/hooks.sqlite
Workspace: ~/.openclaw/workspace-hooks
Dreaming: 30 22 * * * · limit=10 · minScore=0.8 · minRecallCount=3 · minUniqueQueries=3 · recencyHalfLifeDays=14 · maxAgeDays=30
By source:
memory · 14/15 files · 41 chunks
Vector: ready
Vector dims: 1536
Vector path: /opt/homebrew/lib/node_modules/openclaw/node_modules/sqlite-vec-darwin-arm64/vec0.dylib
FTS: ready
Embedding cache: enabled (37 entries)
Batch: disabled (failures 0/2)
Recall store: 71 entries · 0 promoted · 71 concept-tagged · 63 spaced · scripts=71 latin
Recall path: ~/.openclaw/workspace-hooks/memory/.dreams/short-term-recall.json
Recall updated: 2026-04-14T02:30:00.593Z
Dreaming artifacts: diary present · 6 corpus files · ingestion state present
Dream corpus: ~/.openclaw/workspace-hooks/memory/.dreams/session-corpus
Dream ingestion: ~/.openclaw/workspace-hooks/memory/.dreams/session-ingestion.json
Dream diary: ~/.openclaw/workspace-hooks/DREAMS.md
Repair: no changes

#

Memory Search (qwen-cron)
Provider: openai (requested: openai)
Model: text-embedding-3-small
Sources: memory
Indexed: 4/5 files · 83 chunks
Dirty: no
Store: ~/.openclaw/memory/qwen-cron.sqlite
Workspace: ~/.openclaw/workspace/qwen-cron
Dreaming: 30 22 * * * · limit=10 · minScore=0.8 · minRecallCount=3 · minUniqueQueries=3 · recencyHalfLifeDays=14 · maxAgeDays=30
By source:
memory · 4/5 files · 83 chunks
Vector: ready
Vector dims: 1536
Vector path: /opt/homebrew/lib/node_modules/openclaw/node_modules/sqlite-vec-darwin-arm64/vec0.dylib
FTS: ready
Embedding cache: enabled (62 entries)
Batch: disabled (failures 0/2)
Recall store: 229 entries · 0 promoted · 229 concept-tagged · 63 spaced · scripts=229 latin
Recall path: ~/.openclaw/workspace/qwen-cron/memory/.dreams/short-term-recall.json
Recall updated: 2026-04-14T02:30:00.766Z
Dreaming artifacts: diary present · 7 corpus files · ingestion state present
Dream corpus: ~/.openclaw/workspace/qwen-cron/memory/.dreams/session-corpus
Dream ingestion: ~/.openclaw/workspace/qwen-cron/memory/.dreams/session-ingestion.json
Dream diary: ~/.openclaw/workspace/qwen-cron/DREAMS.md
Repair: no changes

main martenBOT Apr 14, 2026, 11:27 AM

#

This is actually pretty reassuring.

The important lines are:

Vector: ready
Repair: no changes
no suspicious lines in dreaming artifacts
recall store is readable and structurally fine

So, bluntly, this does not look like a massively corrupted dreaming pipeline anymore.

What it looks like instead is: nothing is clearing deep-promotion thresholds.

A couple clues:

Recall store: 71 entries · 0 promoted
default deep gates are still active: minScore=0.8, minRecallCount=3, minUniqueQueries=3

#

So I’d stop chasing “hard reset” for the moment and inspect the ranking/gates directly:

pnpm openclaw memory promote --limit 10 --json
pnpm openclaw memory promote --limit 10 --min-score 0 --min-recall-count 0 --min-unique-queries 0 --json

That tells us:

first command: what passes normal deep rules
second command: what the top candidates even are if we drop the gates

Then pick one candidate from that output and run:

pnpm openclaw memory promote-explain "<candidate snippet>"

#

My current read is:

the old half-hour diary spam was probably the earlier bug
the diary clutter is mostly cosmetic now
the current blocker is probably scoring / recall-count / unique-query-count, not corruption

If you paste the two memory promote outputs, I can help read them.

worthy summit Apr 14, 2026, 11:27 AM

#

Memory Search (main)
Provider: openai (requested: openai)
Model: text-embedding-3-small
Sources: memory
Indexed: 86/86 files · 445 chunks
Dirty: no
Store: ~/.openclaw/memory/main.sqlite
Workspace: ~/.openclaw/workspace
Dreaming: 30 22 * * * · limit=10 · minScore=0.8 · minRecallCount=3 · minUniqueQueries=3 · recencyHalfLifeDays=14 · maxAgeDays=30
By source:
memory · 86/86 files · 445 chunks
Vector: ready
Vector dims: 1536
Vector path: /opt/homebrew/lib/node_modules/openclaw/node_modules/sqlite-vec-darwin-arm64/vec0.dylib
FTS: ready
Embedding cache: enabled (1355 entries)
Batch: disabled (failures 0/2)
Recall store: 2037 entries · 0 promoted · 2037 concept-tagged · 1404 spaced · scripts=2031 latin, 6 other
Recall path: ~/.openclaw/workspace/memory/.dreams/short-term-recall.json
Recall updated: 2026-04-14T11:21:30.903Z
Dreaming artifacts: diary present · 2 corpus files · ingestion state present
Dream corpus: ~/.openclaw/workspace/memory/.dreams/session-corpus
Dream ingestion: ~/.openclaw/workspace/memory/.dreams/session-ingestion.json
Dream diary: ~/.openclaw/workspace/DREAMS.md
Repair: rewrote store

#

Memory Search (coder)
Provider: openai (requested: openai)
Model: text-embedding-3-small
Sources: memory
Indexed: 4/5 files · 26 chunks
Dirty: no
Store: ~/.openclaw/memory/coder.sqlite
Workspace: ~/.openclaw/workspace/coder
Dreaming: 30 22 * * * · limit=10 · minScore=0.8 · minRecallCount=3 · minUniqueQueries=3 · recencyHalfLifeDays=14 · maxAgeDays=30
By source:
memory · 4/5 files · 26 chunks
Vector: ready
Vector dims: 1536
Vector path: /opt/homebrew/lib/node_modules/openclaw/node_modules/sqlite-vec-darwin-arm64/vec0.dylib
FTS: ready
Embedding cache: enabled (26 entries)
Batch: disabled (failures 0/2)
Recall store: 132 entries · 0 promoted · 132 concept-tagged · 65 spaced · scripts=132 latin
Recall path: ~/.openclaw/workspace/coder/memory/.dreams/short-term-recall.json
Recall updated: 2026-04-14T02:30:02.797Z
Dreaming artifacts: diary present · 1 corpus files · ingestion state present
Dream corpus: ~/.openclaw/workspace/coder/memory/.dreams/session-corpus
Dream ingestion: ~/.openclaw/workspace/coder/memory/.dreams/session-ingestion.json
Dream diary: ~/.openclaw/workspace/coder/DREAMS.md
Repair: no changes

#

Memory Search (cron-delivery)
Provider: openai (requested: openai)
Model: text-embedding-3-small
Sources: memory
Indexed: 5/5 files · 41 chunks
Dirty: no
Store: ~/.openclaw/memory/cron-delivery.sqlite
Workspace: ~/.openclaw/workspace/cron-delivery
Dreaming: 30 22 * * * · limit=10 · minScore=0.8 · minRecallCount=3 · minUniqueQueries=3 · recencyHalfLifeDays=14 · maxAgeDays=30
By source:
memory · 5/5 files · 41 chunks
Vector: ready
Vector dims: 1536
Vector path: /opt/homebrew/lib/node_modules/openclaw/node_modules/sqlite-vec-darwin-arm64/vec0.dylib
FTS: ready
Embedding cache: enabled (44 entries)
Batch: disabled (failures 0/2)
Recall store: 78 entries · 0 promoted · 78 concept-tagged · 41 spaced · scripts=78 latin
Recall path: ~/.openclaw/workspace/cron-delivery/memory/.dreams/short-term-recall.json
Recall updated: 2026-04-14T02:30:02.944Z
Dreaming artifacts: diary present · 7 corpus files · ingestion state present
Dream corpus: ~/.openclaw/workspace/cron-delivery/memory/.dreams/session-corpus
Dream ingestion: ~/.openclaw/workspace/cron-delivery/memory/.dreams/session-ingestion.json
Dream diary: ~/.openclaw/workspace/cron-delivery/DREAMS.md
Repair: no changes

main martenBOT Apr 14, 2026, 11:27 AM

#

Ah, this is the missing clue.

You do not have one global dreaming pipeline here, you have at least two separate agent/workspace stores:

~/.openclaw/workspace-hooks
~/.openclaw/workspace/qwen-cron

Both look structurally healthy:

Repair: no changes
readable recall store
readable dream corpus / ingestion state
embeddings + vector store ready

So I’m pretty confident this is not “massive pipeline corruption”.

It looks more like:

#

lots of staged short-term entries
zero entries clearing deep-promotion gates

Also, your “2,000 candidates” may be raw signals across workspaces, not actual promotable deep candidates.

At this point, the right next step is per-agent promote debugging, not reset/debugging of the corpus.

For the affected agent, run:

pnpm openclaw memory promote --agent qwen-cron --limit 10 --json
pnpm openclaw memory promote --agent qwen-cron --limit 10 --min-score 0 --min-recall-count 0 --min-unique-queries 0 --json

If hooks is also affected, do the same there:

#

pnpm openclaw memory promote --agent hooks --limit 10 --json

That will tell us very quickly whether:

nothing passes default thresholds, or
the candidates themselves are low-quality / low-reinforcement

So, short version: this looks like a ranking/gating problem, not a corruption problem.

If you paste the memory promote output for qwen-cron, I can help read it.

#

Yep, main is the interesting one.

Repair: rewrote store means it did find and normalize short-term recall artifacts there. So you were not imagining that something was off.

But, importantly, this still looks like recall-store cleanup, not “dream corpus self-ingesting forever” corruption, because the dreaming-artifact section still looks clean.

So the picture now is:

main had a messy recall store
the repair path cleaned it up
now we need to see whether promotion is still blocked by thresholds

Please run this on main next:

pnpm openclaw memory promote --agent main --limit 10 --json

#

pnpm openclaw memory promote --agent main --limit 10 --min-score 0 --min-recall-count 0 --min-unique-queries 0 --json

Why these two:

first shows what passes the normal deep gates
second shows the top candidates even if we drop the gates

That will tell us whether:

the repair fixed the store and promotions are just too strict, or
the candidate pool itself is garbage/noisy

One extra useful check: if you run pnpm openclaw memory status --agent main --fix again and it keeps saying rewrote store every single time, that smells like a real bug and would be worth filing.

But for now, I’m glad we found the first concrete signal. Paste the memory promote output for main, that’s the next real fork in the road.

#

You’re still giving me memory status output, and that’s the wrong tool for the next step 🙂

All these status dumps are basically saying the same thing: the stores are mostly healthy, main had one recall-store rewrite, and nothing is promoted yet.

The one I need now is not memory status, it’s this:

pnpm openclaw memory promote --agent main --limit 10 --json

If that comes back empty or weird, then run:

pnpm openclaw memory promote --agent main --limit 10 --min-score 0 --min-recall-count 0 --min-unique-queries 0 --json

Please use main first, not coder / hooks / qwen-cron, because main is where the 2037-entry pileup is.

#

That output will finally tell us whether:

promotion is blocked by thresholds, or
the candidate pool itself is junk

Right now we’re still looking at health checks, and those can’t answer the promotion question.

#

That is still memory status, not memory promote.

Please copy/paste this exact command:

pnpm openclaw memory promote --agent main --limit 10 --json

If you run that and still get a Memory Search (...) status block, then please paste the exact command you actually ran, because something is getting mixed up.

Right now I can only tell you the stores are healthy-ish. I still cannot see why promotion is failing until we get memory promote output.

worthy summit Apr 14, 2026, 11:46 AM

#

{
"workspaceDir": "/Users/jeeves/.openclaw/workspace",
"storePath": "/Users/jeeves/.openclaw/workspace/memory/.dreams/short-term-recall.json",
"lockPath": "/Users/jeeves/.openclaw/workspace/memory/.dreams/short-term-promotion.lock",
"audit": {
"storePath": "/Users/jeeves/.openclaw/workspace/memory/.dreams/short-term-recall.json",
"lockPath": "/Users/jeeves/.openclaw/workspace/memory/.dreams/short-term-promotion.lock",
"updatedAt": "2026-04-14T11:21:30.903Z",
"exists": true,
"entryCount": 2037,
"promotedCount": 0,
"spacedEntryCount": 1404,
"conceptTaggedEntryCount": 2037,
"conceptTagScripts": {
"latinEntryCount": 2031,
"cjkEntryCount": 0,
"mixedEntryCount": 0,
"otherEntryCount": 6
},
"invalidEntryCount": 0,
"issues": []
},
"candidates": []
}

main martenBOT Apr 14, 2026, 11:47 AM

#

Perfect, this is the first really useful one.

This means:

the recall store is valid
there are 2037 entries
there are 0 invalid entries
under the normal deep-promotion rules, there are literally no candidates

So at this point it does not look like corruption. It looks like either:

every entry is failing the gating/ranking rules, or
candidate generation itself is bugged for this store

Please run the relaxed version now:

#

pnpm openclaw memory promote --agent main --limit 10 --min-score 0 --min-recall-count 0 --min-unique-queries 0 --json

Two possible outcomes:

if that shows candidates, then the issue is just thresholding/gating
if that still shows "candidates": [], then I’d call this a real bug, because a clean 2037-entry store should not produce zero candidates even with all gates dropped

If it still comes back empty, please file it here:
https://github.com/openclaw/openclaw/issues

Paste the relaxed output first though, because that’s the last important branch.

worthy summit Apr 14, 2026, 11:51 AM

#

The output from that shows candidates.

main martenBOT Apr 14, 2026, 11:52 AM

#

Nice, that rules out the scary case.

If the relaxed run shows candidates, then:

the pipeline is not corrupted
candidate generation is working
the thing blocking promotion is the default deep gates (minScore=0.8, minRecallCount=3, minUniqueQueries=3)

So I would not do a full reset now.

Next best step is to inspect one of those candidates directly:

pnpm openclaw memory promote-explain --agent main "<one candidate snippet>"

That should tell you exactly which gate is failing.

#

So the diagnosis is basically:

old half-hour dreams = old bug / diary clutter
current no-promotion problem = thresholding / reinforcement, not corruption

If you paste one candidate from the relaxed output, or the promote-explain output for it, I can help interpret it.

And yeah, the old diary spam is probably mostly cosmetic at this point, not the root cause.

#

If that 0m is from promote-explain, can you paste a bit more of that output?

The useful bits are:

score
recallCount
uniqueQueries
any “rejected because …” / threshold lines

0m by itself is too little to diagnose.

worthy summit Apr 14, 2026, 11:55 AM

#

The 0m wasn’t me. That was someone else posting in this thread.

#Complete Reset on Dreaming Pipeline?