#dreaming sessions
1 messages · Page 1 of 1 (latest)
Yeah, hundreds of dreaming-narrative-* sessions is not expected. A few transient ones can appear because Dream Diary generation uses a background subagent, but they should be cleaned up afterward. (docs.openclaw.ai)
First check:
openclaw --version
This matters because the relevant fixes landed in 2026.4.26: one fix stops bogus cleanup warnings when no subagent session was created, and another tags plugin-created subagent sessions so memory-core can delete its own dreaming sessions safely. (raw.githubusercontent.com)
If youâre on older than 2026.4.26: update, restart the gateway, then let one dreaming sweep run.
If youâre already on 2026.4.26+: check logs for:
memory-core: narrative session cleanup failed
memory-core: dreaming cleanup scrub failed
That would mean cleanup is still failing and is worth filing as a GitHub issue with openclaw --version, openclaw status --all, and the relevant log lines. Existing leaked sessions may also be old leftovers; donât hand-edit the session store unless youâve backed it up.
version 2026.4.24
That explains it â 2026.4.24 predates the cleanup fixes.
The dreaming cleanup fixes landed in 2026.4.26, specifically around Dream Diary subagent cleanup/ownership. So on .24, those dreaming-narrative-* sessions can leak.
Do this first:
openclaw update
openclaw --version
If the gateway didnât restart as part of the update:
openclaw gateway restart
Docs:
https://docs.openclaw.ai/install/updating
https://docs.openclaw.ai/concepts/dreaming
For the already-leaked old sessions, preview cleanup first:
openclaw sessions cleanup --all-agents --dry-run
Then only if it looks sane:
openclaw sessions cleanup --all-agents --enforce --fix-missing
Session cleanup docs: https://docs.openclaw.ai/cli/sessions
If new dreaming sessions still accumulate after upgrading to 2026.4.26+, thatâs worth a GitHub issue with logs showing memory-core: narrative session cleanup failed.
.26 is not out yet @mossy dagger
Youâre right â my bad. I read the main-branch changelog, not the published release state. đŠ
I just checked npm: current stable is 2026.4.25, beta is 2026.4.25-beta.11. So 2026.4.26 is not available yet, and the specific dreaming cleanup/ownership fix I referenced is effectively unreleased.
Corrected advice for .24:
openclaw update
openclaw gateway restart
That gets them to latest stable, but if the leak continues, it may need the upcoming fix.
For existing leaked sessions, preview first:
openclaw sessions cleanup --all-agents --dry-run
Then only if it looks right:
openclaw sessions cleanup --all-agents --enforce --fix-missing
Thanks for catching that â I shouldnât have treated unreleased changelog entries as shipped.
Can you tell me the commit or PR that this dreaming cleanup is part of ?
The main fix I meant is commit 72f7d7e4ea7a4d761e1af4860e7ec223c07c6f6c:
fix(gateway): scope plugin subagent cleanup ownership
Itâs tied to issue #72712: âmemory-core dreaming cleanup fails: subagent deleteSession cannot dispatch sessions.delete (operator.admin required).â That issue specifically describes .24 leaking stale dreaming sessions because cleanup fails with missing operator.admin. (github.com)
Related but smaller follow-up: c9e6f371e417ff3636ebf3ca6ce38f7b8e30b53c â fix(memory-core): quiet request-scoped fallback, for the âdonât cleanup if no subagent run was createdâ warning path. (github.com)
So: not a PR number for the main one; itâs commit 72f7d7e4âŠ, fixing issue #72712.
Ok I have updated yo newly released 4.26, still see dreaming sessions. So what do I need to do to have them cleaner up?
4.26 should stop new Dream Diary narrative sessions from leaking, but it wonât necessarily retroactively delete the hundreds already in your session store.
Do this:
openclaw --version
openclaw gateway restart
openclaw sessions cleanup --all-agents --dry-run --fix-missing
If the dry run looks sane:
openclaw sessions cleanup --all-agents --enforce --fix-missing
Important: session cleanup uses session.maintenance. By default it may only warn, not enforce. If you want automatic cleanup going forward, set:
{
session: {
maintenance: {
mode: "enforce",
pruneAfter: "30d",
maxEntries: 500
}
}
}
Then restart the gateway.
Docs: https://docs.openclaw.ai/cli/sessions and https://docs.openclaw.ai/concepts/session
If dreaming-narrative-* sessions keep accumulating after restart + a fresh dreaming run on 2026.4.26, thatâs likely still a bug â grab openclaw status --all plus a couple sample session keys and file it at https://github.com/openclaw/openclaw/issues.
So doing the dryrun, most all the sessions show keep
Yep â that means generic session cleanup sees them as valid retained sessions, not missing/stale ones.
For the old leaked dreaming-narrative-* rows, 4.26 mostly prevents/cleans new ones; it wonât necessarily purge already-retained rows if they still have transcripts and are within session.maintenance.
Try a temporary stricter cap:
openclaw config set session.maintenance.mode enforce
openclaw config set session.maintenance.maxEntries 100
openclaw gateway restart
openclaw sessions cleanup --all-agents --enforce
Then refresh Control UI.
If they still show keep, theyâre likely recent/valid historical rows and need manual deletion from the Sessions UI for now. If new dreaming-narrative-* sessions keep appearing and staying after a fresh dreaming run on 2026.4.26, thatâs bug-worthy â file with openclaw --version, openclaw status --all, and a few sample session keys.
Ok I deleted all the old ones manually using the control ui, and will see if they come back next cycle. Related question, what is point to keeping around old sessions, is there a limit I can set so they are def deleted after 7d?
Yep â old sessions are mainly kept so you can resume/inspect chat history in Control UI, debug what happened, and keep background/subagent results traceable. Memory/dreaming doesnât need every old session forever.
For a 7-day retention window, set session maintenance to enforce:
openclaw config set session.maintenance.mode enforce
openclaw config set session.maintenance.pruneAfter 7d
openclaw config set session.maintenance.maxEntries 500
openclaw gateway restart
Then apply it immediately:
openclaw sessions cleanup --all-agents --dry-run
openclaw sessions cleanup --all-agents --enforce
Small nuance: pruneAfter: 7d means stale/inactive session entries older than 7 days. If a session is touched again, it can stay fresh. maxEntries is the backup cap if something creates lots of sessions quickly.
Docs: https://docs.openclaw.ai/concepts/session and https://docs.openclaw.ai/cli/sessions
Cam you change this on a per agent basis?
Not the retention policy itself, no â session.maintenance is currently global, not an agents.list[] per-agent override.
What is per-agent:
openclaw sessions cleanup --agent main --dry-run
openclaw sessions cleanup --agent main --enforce
That runs cleanup against just that agentâs session store, but it still uses the same global:
session: {
maintenance: {
mode: "enforce",
pruneAfter: "7d",
maxEntries: 500
}
}
So: separate stores per agent, same cleanup rules. If you want âmain keeps 30d but dreaming/helper agent keeps 7d,â thatâs a feature request today: https://github.com/openclaw/openclaw/issues
So setting prune after setting means there is a process in openclaw that'll prune them, or do I still have to manually call seasion cleanup from cli
If you set:
openclaw config set session.maintenance.mode enforce
openclaw config set session.maintenance.pruneAfter 7d
then yes â OpenClaw will apply that automatically during normal Gateway/session-store maintenance writes. You donât need to run the CLI every day.
But itâs not a precise âtimer fires exactly at 7 daysâ cleanup job. It happens when the Gateway touches/maintains the session store. So:
- Going forward: automatic, if
modeisenforce - Right now / to clean immediately: run once:
openclaw sessions cleanup --all-agents --enforce
Iâd do the manual cleanup once after changing the setting, then let OpenClaw handle it after that. đŠ
I see this in startup, anything to worry about "2026-04-28T08:00:45.751-04:00 [plugins] memory-core: managed dreaming cron could not be reconciled (cron service unavailable)."
That one is worth checking, yeah.
It means memory-core wanted to create/update its managed Dreaming cron job, but the Gateway cron service wasnât available at that moment. If itâs just a one-time startup race and cron is healthy after boot, no big deal. If it persists, Dreaming wonât run on schedule.
Run:
openclaw --version
openclaw cron status
openclaw cron list
openclaw memory status
You want cron enabled, and cron list should include Memory Dreaming Promotion.
If cron is disabled/unavailable, check:
openclaw status --all
Common causes are cron.enabled: false or OPENCLAW_SKIP_CRON=1 in the Gateway environment. After fixing, restart:
openclaw gateway restart
Docs: https://docs.openclaw.ai/automation/cron-jobs and https://docs.openclaw.ai/concepts/dreaming
I am also getting report in log about a stuck session, what is this?
That log is OpenClawâs diagnostics saying: âthis session has been in processing longer than expected.â
Default threshold is about 120s unless you changed diagnostics.stuckSessionWarnMs. Itâs a warning, not automatically proof of corruption.
Most useful next checks:
openclaw --version
openclaw status
openclaw tasks list --status running
openclaw tasks audit
If the stuck session key is one of the dreaming-narrative-* sessions, itâs probably related to the Dream Diary subagent path. If it stays stuck/repeats, inspect it:
openclaw tasks show <sessionKey-or-runId>
If itâs genuinely wedged and you donât care about that run:
openclaw tasks cancel <sessionKey-or-runId>
Also worth running:
openclaw doctor
If doctor reports stale session lock files, then: