#08:48:28 [plugins] memory-core: narrative session cleanup failed for rem phase: missing scope: opera

1 messages · Page 1 of 1 (latest)

wooden spear Apr 21, 2026, 4:38 AM

08:46:41 [plugins] memory-core: narrative generation ended with status=timeout for rem phase.
08:46:46 [plugins] memory-core: narrative session cleanup failed for rem phase: missing scope: operator.admin

spare tartanBOT Apr 21, 2026, 4:38 AM

scenic coveBOT Apr 21, 2026, 4:38 AM

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

spare tartanBOT Apr 21, 2026, 4:38 AM

weary cradleBOT Apr 21, 2026, 4:41 AM

That looks like two separate things:

narrative generation ended with status=timeout for rem phase
- the REM dream-diary subagent timed out
- this is best-effort, it should not fail the actual memory/dreaming sweep
narrative session cleanup failed ... missing scope: operator.admin
- cleanup calls sessions.delete
- sessions.delete is admin-scoped, so the client/session that triggered this does not have operator.admin

First, please paste:

openclaw --version
openclaw status --all
openclaw devices list

Most likely fixes:

If devices list shows a pending scope upgrade, approve it:
```
openclaw devices approve <requestId>
```
If this is coming from a paired browser/device session, reconnect with a full gateway token/password session, or rotate/re-pair that device so it has operator.admin.
If you are on an older build, update first. If you are below v2026.4.2, I’d definitely upgrade before chasing this further.

Docs:

If you paste those 3 outputs, I can tell you pretty quickly whether this is harmless dream-diary cleanup noise or a real pairing/scope problem.

wooden spear Apr 21, 2026, 6:46 AM

08:48:28 [plugins] memory-core: dream diary entry written for rem phase [workspace=C:\Users\prapunsak.openclaw\workspace-aemeath].
08:48:28 [plugins] memory-core: narrative session cleanup failed for rem phase: missing scope: operator.admin
08:48:28 The night had the feel of a ledger left open by a window, pages stirred by warm wind. I kept finding empty margins where a note should have lived, only to discover a small alert tucked beneath the lamp glow, stale as yesterday’s tea. Four clean receipts sat like pebbles in a bowl, while three scraps of handwriting had gone out of step, their dates and tokens mismatched like socks after laundry day. I laughed softly at that, then felt the hush behind it, the way a system can be tidy and still ask for care. A little watchfulness, a little mercy. Across the room, one theme kept returning like a moth to light, persistent and oddly familiar. I drew a tiny lighthouse in the corner of the page and wrote beneath it: if the sea is noisy, still count the stars.

it does have this kind of log at the end.

OpenClaw 2026.4.15 (041266a)

Channels
+----------+---------+--------+----------------------------------------------------------------------------------------+
| Channel | Enabled | State | Detail |
+----------+---------+--------+----------------------------------------------------------------------------------------+
| Discord | ON | OK | token config×2 (sha256:890430de · len 72) · accounts 2/2 |
+----------+---------+--------+----------------------------------------------------------------------------------------+

Diagnosis (read-only)

Gateway connection details:
Gateway target: ws://127.0.0.1:18789
Source: local loopback
Config: C:\Users\prapunsak.openclaw\openclaw.json
Bind: loopback

✓ Config: C:\Users\prapunsak.openclaw\openclaw.json
✓ Secret diagnostics (0)
✓ Restart sentinel: none
! Port 18789
Port 18789 is already in use.

pid 15592: node.exe (127.0.0.1:18789)
Another process is listening on this port.
! Tailscale: off · unknown
✓ Skills: 21 eligible · 0 missing · C:\Users\prapunsak.openclaw\workspace
✓ Plugin compatibility (none)
✓ Channel issues (none)

PS C:\WINDOWS\System32> openclaw devices list

🦞 OpenClaw 2026.4.15 (041266a) — Runs on a Raspberry Pi. Dreams of a rack in Iceland.

weary cradleBOT Apr 21, 2026, 6:48 AM

Yep, that confirms it.

The important line is:

dream diary entry written for rem phase

So the REM narrative did succeed. What failed was only the cleanup of the temporary helper session afterward.

In other words:

dream diary write: ✅
temp session delete: ❌ (operator.admin missing)

So this is usually harmless log noise, not a failed dreaming pass. The main side effect is that a temporary narrative session/transcript may stick around a bit longer than intended.

If you want to clean those up manually, these are the safest things to try:

openclaw sessions cleanup
openclaw doctor --repair

If you want to stop the warning from appearing, the session/client that triggers dreaming needs admin scope. Common causes:

paired device/browser session does not have operator.admin
pending scope upgrade was never approved

Worth checking:

openclaw devices list

If there is a pending upgrade request:

openclaw devices approve <requestId>

Docs:

So short version, I would not treat this as a real memory-core failure unless you also start seeing leftover sessions pile up or other dreaming phases fail.

Nice, that version is recent enough, so this is not just “please update” 🙂

Given 2026.4.15, my read is:

the REM diary write succeeded
the cleanup call still ran from a session/client without operator.admin
so this is an auth/scope-path issue, not an old-version issue

What matters now is what triggered the dreaming run:

If this came from a paired device / Control UI / chat-triggered run, the warning makes sense. That client likely does not have admin scope for sessions.delete.
If this came from the automatic scheduled dreaming sweep, that feels more like a real bug.

So I’d check this next:

openclaw devices list
openclaw gateway status

And one clarifier from you would help a lot:

was this from a scheduled/background dream run
or from something you manually triggered in UI/chat/CLI?

If it was a manual or paired-client path, I’d mostly treat it as harmless cleanup noise.

If it was the scheduled sweep, I’d lean toward calling it a bug and filing it here:
https://github.com/openclaw/openclaw/issues

If you want, paste the few log lines right before this block too. That usually reveals which path launched the REM narrative helper.

This helps a lot.

With that setup, I don’t think this is a bad local config on your side.

Why I’m leaning that way:

you’re current (2026.4.15)
gateway is local, reachable, token-authenticated
the diary entry is successfully written
only the follow-up sessions.delete cleanup fails with missing scope: operator.admin

That points more to a background/plugin runtime scope mismatch than to your dashboard token or device pairing.

So my updated read is:

REM narrative generation works
cleanup of the helper session is using a write-scoped path

sessions.delete needs admin, so it logs the warning
result: mostly harmless, but noisy, and it can leave temp sessions around until cleanup/scrub runs

I would stop chasing your auth config here. This looks bug-ish.

Practical advice

If sessions start piling up:

openclaw sessions cleanup
openclaw doctor --repair

If it’s just this warning at the end and everything else works, it’s probably safe to ignore for now.

I would file this as a bug

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

Suggested title:

memory-core dreaming narrative cleanup fails with missing scope: operator.admin after successful REM diary write

And include exactly these lines plus your status block.

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

Ah, this is useful.

The 41 total sessions across main and aemeath is consistent with these helper sessions not being cleaned up. Not proof by itself, but it fits the story.

The nice part is, the helper session keys use a very obvious prefix:

dreaming-narrative-...

So you can confirm it directly.

Check for leaked dream helper sessions

On Windows:

openclaw sessions --all-agents | findstr dreaming-narrative

Or just:

openclaw sessions --all-agents

and look for session keys containing dreaming-narrative-.

Clean them up

openclaw sessions cleanup

If you want to be extra safe:

openclaw doctor --repair

So at this point my take is:

not a bad Discord config
not an outdated version
probably a real cleanup bug / rough edge in the dreaming narrative helper path

If openclaw sessions --all-agents shows dreaming-narrative-* entries, that’s basically the smoking gun for the GitHub issue.

Yep, nothing scary there.

The Port 18789 is already in use bit is expected here, because your gateway is already running and listening on that port. So that is not the cause.

So this diagnosis basically says:

gateway is up
config is fine
channels are fine
plugin compatibility is fine
nothing obvious is broken in the environment

Which makes me even more confident this is not a local setup problem. It still looks like a dreaming narrative cleanup scope bug / rough edge.

At this point I’d do two things:

Confirm whether helper sessions are accumulating:

   openclaw sessions --all-agents | findstr dreaming-narrative

File a GitHub issue with:
- the log lines
- your openclaw --version
- the status/diagnosis blocks you pasted here
- the output of the command above, if it shows dreaming-narrative-*

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

So, short version: the new diagnostics do not point to any user misconfiguration.

Perfect, that settles it.

Your paired devices do have operator.admin, so this is not a device-scope problem. I’m glad you checked that.

That means the error is almost certainly coming from an internal plugin/background cleanup path that is not reusing the admin-scoped device/client you see in devices list.

So the updated diagnosis is:

your device scopes are fine
your gateway/token setup is fine
REM diary writing works
the failing part is the internal cleanup call
this is very likely an OpenClaw bug / scope propagation bug, not user misconfiguration

So yes, at this point I’d file it:

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

Suggested summary:

memory-core REM narrative cleanup fails with missing scope: operator.admin even though paired operator devices already have operator.admin

And include:

the original log lines
openclaw --version
openclaw status --all
openclaw doctor / diagnosis output
openclaw devices list

optionally:

openclaw sessions --all-agents | findstr dreaming-narrative

Workaround for now:

openclaw sessions cleanup

So, short version: you’ve ruled out the obvious auth causes. This looks real.

wooden spear Apr 21, 2026, 7:38 AM

Can you summarize what I need to do?

weary cradleBOT Apr 21, 2026, 7:39 AM

Yep. Short version:

You do not need to fix your device scopes
- your paired devices already have operator.admin
This looks like an OpenClaw bug / cleanup scope issue
- REM diary writing succeeds
- only the internal cleanup step fails
Optional cleanup on your machine
```
openclaw sessions cleanup
```
(and openclaw doctor --repair if you want a general cleanup pass)
File a GitHub issue
- https://github.com/openclaw/openclaw/issues