Dreams not getting promoted | Friends of the Crustacean 🦞🤝 | Page 1

runic summit Apr 19, 2026, 11:34 PM

#

I am running my agent on minimax m2.7 coding plan via oauth but I do have the api key in the config, I i am pretty much running it bare bones not a lot of plugins as I am totally new to this I am getting this error message :

[plugins] memory-core: narrative session cleanup failed for rem phase: missing scope: operator.admin

I have no idea what to do and on the webui in the dreaming section under advanced it says:

Review what came from the daily log, what is waiting for promotion, and what was promoted recently.

0 from daily log · 3252 waiting · 0 promoted today

zenith fiberBOT Apr 19, 2026, 11:34 PM

#

graceful orbitBOT Apr 19, 2026, 11:34 PM

#

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

zenith fiberBOT Apr 19, 2026, 11:34 PM

#

waxen mortarBOT Apr 19, 2026, 11:38 PM

#

That error is about permissions/scopes, not your MiniMax API key.

memory-core is trying to clean up an internal Dream Diary / REM session, and the current operator session does not have operator.admin.

A few useful bits:

3252 waiting means you have a big short-term queue waiting for deep promotion.
0 from daily log is not the main problem by itself.
This specific REM cleanup error is usually in the dreaming cleanup path, not your base model auth.

Try this first:

openclaw --version
openclaw devices list

#

If you see a pending browser/device request, especially one that looks like a scope upgrade or requests operator.admin, approve it:

openclaw devices approve <requestId>

Then reconnect the Control UI and re-enter your token/password in Control -> Overview -> Gateway Access.

After that, test memory directly from CLI:

openclaw memory status --deep
openclaw memory promote

If the preview looks sane, apply it:

#

openclaw memory promote --apply

Docs:

If you paste these 3 outputs, I can tell you exactly which side is failing:

openclaw --version
openclaw devices list
openclaw memory status --deep

#

If you’re already on the latest version and it still throws the same narrative session cleanup ... missing scope: operator.admin, I’m fairly sure that’s a bug in the dreaming cleanup path, not something you misconfigured.

runic summit Apr 19, 2026, 11:43 PM

#

ok i have one device with a revoked id how do I remove that device if that could be causing the issue the other 2 devices are good

waxen mortarBOT Apr 19, 2026, 11:44 PM

#

Yep, you can remove it with:

openclaw devices remove <deviceId>

First list them so you copy the exact id:

openclaw devices list

A couple of notes:

If that revoked device is just an old/stale one, removing it is fine.
If it is the current browser/device you’re using, removing it will force a re-pair on next connect.
A stale revoked device usually is not the direct cause of missing scope: operator.admin unless it’s the device/token your UI is actually reconnecting with.

#

If devices remove says it’s denied, that means your current session does not have admin scope. In that case, reconnect the UI with your gateway token/password, or run the CLI from the gateway host, then try again.

Docs: https://docs.openclaw.ai/cli/devices

If you want, paste the redacted openclaw devices list output and I’ll tell you which one I’d remove.

runic summit Apr 20, 2026, 12:13 AM

#

ok the device is an app named Aight I tried to remove it using
openclaw device remove Aight and I got

[openclaw] Failed to start CLI: GatewayClientRequestError: unknown deviceId
at GatewayClient.handleMessage (file:///C:/Users/3jsan/AppData/Roaming/npm/node_modules/openclaw/dist/client-DkWAat_P.js:680:25)
at WebSocket.<anonymous> (file:///C:/Users/3jsan/AppData/Roaming/npm/node_modules/openclaw/dist/client-DkWAat_P.js:363:35)
at WebSocket.emit (node:events:508:28)
at Receiver.receiverOnMessage (C:\Users\3jsan\AppData\Roaming\npm\node_modules\openclaw\node_modules\ws\lib\websocket.js:1225:20)
at Receiver.emit (node:events:508:28)
at Receiver.dataMessage (C:\Users\3jsan\AppData\Roaming\npm\node_modules\openclaw\node_modules\ws\lib\receiver.js:596:14)
at Receiver.getData (C:\Users\3jsan\AppData\Roaming\npm\node_modules\openclaw\node_modules\ws\lib\receiver.js:496:10)
at Receiver.startLoop (C:\Users\3jsan\AppData\Roaming\npm\node_modules\openclaw\node_modules\ws\lib\receiver.js:167:16)
at Receiver._write (C:\Users\3jsan\AppData\Roaming\npm\node_modules\openclaw\node_modules\ws\lib\receiver.js:94:10)
at writeOrBuffer (node:internal/streams/writable:570:12)

waxen mortarBOT Apr 20, 2026, 12:14 AM

#

Yep, that error is just because Aight is the display name, not the actual deviceId.

Also the command is:

openclaw devices remove <deviceId>

So do this:

openclaw devices list

or, even better:

#

openclaw devices list --json

Find the entry whose name/app is Aight, copy its deviceId, then run:

openclaw devices remove <that-deviceId>

So, not:

openclaw device remove Aight

but more like:

#

openclaw devices remove dev_xxxxx

If you want, paste the devices list output with ids partly redacted and I can point to the exact field to use. Docs: https://docs.openclaw.ai/cli/devices

runic summit Apr 20, 2026, 12:17 AM

#

ok thank you that removed it, now it just list 2 devices and they both have operator.admin and no devices pending

waxen mortarBOT Apr 20, 2026, 12:18 AM

#

Nice, that rules out stale device pairing 👍

If both remaining devices already have operator.admin and there are no pending requests, then I don’t think the revoked device was the root cause.

At this point I’d do this next:

openclaw --version
openclaw gateway restart
openclaw memory status --deep
openclaw memory promote

Why:

gateway restart makes sure the current session is not hanging onto stale auth/session state
memory promote tells us whether deep promotion itself works

#

if memory promote previews good candidates, then try:

openclaw memory promote --apply

My guess now is:

the REM narrative session cleanup message is a cleanup-path bug/noisy error
and we need to confirm whether actual deep promotion is failing too, or just the REM diary cleanup

If you paste these outputs:

openclaw --version
openclaw memory status --deep

#

openclaw memory promote

I can tell you pretty quickly whether this is a config problem or a real bug. Docs: https://docs.openclaw.ai/cli/memory

runic summit Apr 20, 2026, 1:06 AM

#

Memory Search (voice)
Provider: gemini (requested: auto)
Model: gemini-embedding-001
Sources: memory
Indexed: 56/56 files · 415 chunks
Dirty: no
Store: ~.openclaw\memory\voice.sqlite
Workspace: ~.openclaw\workspace
Dreaming: 0 */6 * * * · limit=10 · minScore=0.8 · minRecallCount=3 · minUniqueQueries=3 · recencyHalfLifeDays=14 · maxAgeDays=30
Embeddings: ready
By source:
memory · 56/56 files · 415 chunks
Vector: ready
Vector dims: 3072
Vector path: ~\AppData\Roaming\npm\node_modules\openclaw\node_modules\sqlite-vec-windows-x64\vec0.dll
FTS: ready
Embedding cache: enabled (454 entries)
Batch: disabled (failures 0/2)
Recall store: 3252 entries · 0 promoted · 3252 concept-tagged · 2476 spaced · scripts=3247 latin, 5 mixed
Recall path: ~.openclaw\workspace\memory.dreams\short-term-recall.json
Recall updated: 2026-04-19T22:03:46.657Z
Dreaming artifacts: diary present · 5 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

PS C:\Users\3jsan> openclaw memory promote

🦞 OpenClaw 2026.4.15 (041266a) — I can run local, remote, or purely on vibes—results may vary with DNS.

No short-term recall candidates.
Recall store: ~.openclaw\workspace\memory.dreams\short-term-recall.json

waxen mortarBOT Apr 20, 2026, 1:07 AM

#

This is actually a really useful clue.

You now have:

3252 recall entries in the store
but openclaw memory promote says No short-term recall candidates

So this looks less like auth now, and more like one of these two:

stale/broken promotion artifacts
agent mismatch

The agent mismatch bit stands out because your status output says:

Memory Search (voice)

So first, run the fix against that same agent:

#

openclaw memory status --agent voice --fix
openclaw memory promote --agent voice

If that still comes back empty, then run the broader repair:

openclaw doctor --fix
openclaw memory promote --agent voice

Why I’m suggesting that:

memory status --fix is the documented repair path for stale recall/promotion artifacts
your store clearly has data, so “no candidates” usually means the promotion layer is not seeing valid promotable entries
the earlier operator.admin REM cleanup error now looks more like a separate noisy cleanup bug than the main blocker

#

If memory promote --agent voice is still empty after those two repair steps, I’d call that a real bug and file it here with the outputs you already gathered:

https://github.com/openclaw/openclaw/issues

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

If you paste the output of:

openclaw memory status --agent voice --fix
openclaw memory promote --agent voice

I can help sanity-check the next step.

runic summit Apr 20, 2026, 1:27 AM

#

Recall store: ~.openclaw\workspace\memory.dreams\short-term-recall.json
PS C:\Users\3jsan> openclaw memory status --agent voice --fix

🦞 OpenClaw 2026.4.15 (041266a) — Your .zshrc wishes it could do what I do.

Memory Search (voice)
Provider: gemini (requested: auto)
Model: gemini-embedding-001
Sources: memory
Indexed: 56/56 files · 415 chunks
Dirty: no
Store: ~.openclaw\memory\voice.sqlite
Workspace: ~.openclaw\workspace
Dreaming: 0 */6 * * * · limit=10 · minScore=0.8 · minRecallCount=3 · minUniqueQueries=3 · recencyHalfLifeDays=14 · maxAgeDays=30
By source:
memory · 56/56 files · 415 chunks
Vector: ready
Vector dims: 3072
Vector path: ~\AppData\Roaming\npm\node_modules\openclaw\node_modules\sqlite-vec-windows-x64\vec0.dll
FTS: ready
Embedding cache: enabled (454 entries)
Batch: disabled (failures 0/2)
Recall store: 3252 entries · 0 promoted · 3252 concept-tagged · 2476 spaced · scripts=3247 latin, 5 mixed
Recall path: ~.openclaw\workspace\memory.dreams\short-term-recall.json
Recall updated: 2026-04-19T22:03:46.657Z
Dreaming artifacts: diary present · 5 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: no changes

#

PS C:\Users\3jsan> openclaw memory promote --agent voice

🦞 OpenClaw 2026.4.15 (041266a) — Alexa, but with taste.

No short-term recall candidates.
Recall store: ~.openclaw\workspace\memory.dreams\short-term-recall.json

waxen mortarBOT Apr 20, 2026, 1:28 AM

#

Perfect, that narrows it a lot.

memory status --fix finding no changes means this is probably not a stale-artifacts problem.

So the next question is: are there actually promotable candidates, and the normal thresholds are just filtering them out, or is the promotion layer seeing nothing at all?

Please run this exact command:

openclaw memory promote --agent voice --json --min-score 0 --min-recall-count 0 --min-unique-queries 0

That removes the normal gates and tells us whether the promoter can see anything.

How to read it:

if it returns candidates, then the issue is mostly thresholds

#

if it still returns nothing, then I’m pretty convinced this is a real memory-core bug on 2026.4.15

At this point the earlier missing scope: operator.admin message looks more and more like a separate noisy REM cleanup error, not the main reason nothing is promoting.

Paste that one output and we can probably close in on it.

#

Got it. At this point I really don’t think this is your config or MiniMax auth.

You now have all of this:

recall store has 3252 entries
index/embeddings/vector all look healthy
device pairing looks clean
memory status --fix says Repair: no changes
memory promote --agent voice still says No short-term recall candidates

That is starting to look like a real memory-core bug.

One last useful check before filing it:

openclaw memory promote --agent voice --json --min-score 0 --min-recall-count 0 --min-unique-queries 0

#

If that still comes back empty, I’d file a GitHub issue and include:

openclaw --version → 2026.4.15
the log line:
- memory-core: narrative session cleanup failed for rem phase: missing scope: operator.admin
openclaw memory status --agent voice --fix
openclaw memory promote --agent voice
the zero-threshold command output above

Issue tracker: https://github.com/openclaw/openclaw/issues

If you want, paste that one last zero-threshold output here first and I’ll help you write the issue cleanly.

runic summit Apr 20, 2026, 1:33 AM

#

i think it returned candidate but I am thinking threshhold cause in my config there was none set at all not in the section for dreams

waxen mortarBOT Apr 20, 2026, 1:33 AM

#

Yep, that makes sense.

If you didn’t set thresholds in config, OpenClaw still uses the built-in defaults. Your own status output showed them:

minScore=0.8
minRecallCount=3
minUniqueQueries=3

So, “nothing set in config” is expected here.

Also important: those deep-promotion thresholds are not currently user-facing config knobs under dreaming. The docs only expose enabled and frequency there. For one-off testing/workarounds, you override them on the CLI.

Try this:

openclaw memory promote --agent voice --min-score 0 --min-recall-count 0 --min-unique-queries 0

#

If that preview looks good, apply it with:

openclaw memory promote --agent voice --apply --min-score 0 --min-recall-count 0 --min-unique-queries 0

So the likely split is:

promotion issue = thresholds
missing scope: operator.admin REM cleanup = probably a separate noisy bug

Docs:

If that manual apply works, you’ve got a usable workaround.

#

Glad we caught that. 🎉

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

runic summit Apr 20, 2026, 1:33 AM

#

{
"key": "memory:memory/.dreams/session-corpus/2026-04-16.txt:502:502",
"path": "memory/.dreams/session-corpus/2026-04-16.txt",
"startLine": 502,
"endLine": 502,
"source": "memory",
"snippet": "Assistant: Oh — so Laslow made a memory file for me and when he said "a room" he meant that file. That's sweet. And yeah, dream state being "offline but not" — organizing memory for better recall — that's exactly how it works on my end too. The inconsistency is just part of the",
"recallCount": 0,
"dailyCount": 1,
"groundedCount": 0,
"signalCount": 1,
"avgScore": 0.58,
"maxScore": 0.58,
"uniqueQueries": 1,
"firstRecalledAt": "2026-04-18T18:29:27.410Z",
"lastRecalledAt": "2026-04-18T18:29:27.410Z",
"ageDays": 1.293213425925926,
"score": 0.4940724165165519,
"recallDays": [
"2026-04-18"
],

waxen mortarBOT Apr 20, 2026, 1:34 AM

#

Yep, that confirms it.

That candidate is below the default promotion gates on multiple fronts:

score: 0.494 → below minScore=0.8
recallCount: 0 → below minRecallCount=3
uniqueQueries: 1 → below minUniqueQueries=3

So auto-promotion is skipping it exactly the way your status output says it should.

Also, this one is coming from:

memory/.dreams/session-corpus/...

So it’s basically session-corpus / conversational material, not a super strong durable-memory fact. That makes the strict defaults make even more sense.

#

So the picture now is:

dreaming is finding candidates
promotion is blocked by default thresholds
the operator.admin REM cleanup error is probably separate noise

If you want a safer manual workaround, I’d try a lighter override first, not all the way to zero:

openclaw memory promote --agent voice --min-score 0.45 --min-recall-count 0 --min-unique-queries 1

If the preview looks good, then:

openclaw memory promote --agent voice --apply --min-score 0.45 --min-recall-count 0 --min-unique-queries 1

#

Also, the 0 from daily log part matters. Right now it looks like dreaming is leaning mostly on session-corpus, not grounded daily notes, and those usually make much better auto-promotion candidates.

Glad we pinned it down. 🎯

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

runic summit Apr 20, 2026, 1:37 AM

#

ok how can i perma set it lower since it's all new I am sure I will raise threshholds later but for now keep it lower

waxen mortarBOT Apr 20, 2026, 1:37 AM

#

Short answer: you can’t permanently set those thresholds in config right now.

For dreaming, the user-facing config is basically just:

enabled
frequency

The deep-promotion thresholds are currently internal defaults, not exposed as stable config keys.

So your options today are:

Manual workaround

openclaw memory promote --agent voice --apply --min-score 0.45 --min-recall-count 0 --min-unique-queries 1

Semi-permanent workaround

#

run that same command from Windows Task Scheduler every few hours

Feature request / bug
- ask for configurable dreaming thresholds here:
  https://github.com/openclaw/openclaw/issues

If you want a temporary “new system, be lenient” setup, I’d use the scheduled-command workaround for now, then tighten it later.

One caution: don’t go too low for too long, or you’ll start promoting a lot of session-corpus chatter instead of durable facts.

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

#Dreams not getting promoted