#dreaming sessions

1 messages · Page 1 of 1 (latest)

granite herald
#

I saw in the release notes that the dreaming sessions are supposed to be cleaned up after running, but when I go to control-ui and session I see hundred sessions related to dreaming. What is wrong?

twin spireBOT
#

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

mossy daggerBOT
#

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.

granite herald
#

version 2026.4.24

mossy daggerBOT
#

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
#

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.

glad scroll
#

.26 is not out yet @mossy dagger

mossy daggerBOT
#

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.

granite herald
#

Can you tell me the commit or PR that this dreaming cleanup is part of ?

mossy daggerBOT
#

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.

granite herald
#

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?

mossy daggerBOT
#

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:

granite herald
#

So doing the dryrun, most all the sessions show keep

mossy daggerBOT
#

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.

granite herald
#

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?

mossy daggerBOT
#

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
granite herald
#

Cam you change this on a per agent basis?

mossy daggerBOT
#

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

granite herald
#

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

mossy daggerBOT
#

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 mode is enforce
  • 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. 🩐

granite herald
#

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)."

mossy daggerBOT
#

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:

granite herald
#

I am also getting report in log about a stuck session, what is this?

mossy daggerBOT
#

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: