OpenClaw memory-core Dreaming narrative session cleanup still leaves session/trajectory residue on 2026.5.3-1
Summary
On OpenClaw 2026.5.3-1, the managed memory-core Dreaming sweep runs successfully, but it still leaves substantial session/trajectory residue after the 03:00 sweep.
This looks related to earlier fixed/closed Dreaming cleanup issues, but the local installed 2026.5.3-1 bundle still lacks the key cleanup behavior proposed in open PR #70464.
This report is intended as evidence for either a new issue or a comment on the existing Dreaming cleanup PR/issue. It was prepared from a local read-only audit; no local OpenClaw core patch was applied.
Environment
OpenClaw: 2026.5.3-1 (2eae30e)
OS: macOS 26.4.1 x64
Node: 25.9.0
Context engine: lossless-claw 0.9.4
Memory plugin: memory-core bundled 2026.5.3
Dreaming: enabled, managed cron `0 3 * * *` Asia/Shanghai
Agent/workspace audited: sungeng, plus main sessions where Dreaming narrative residue appears
Actual behavior observed
The official managed Dreaming cron ran successfully around 03:00 Asia/Shanghai.
Evidence from the local audit:
Memory Dreaming Promotion cron: last run OK
DREAMS.md mtime: 2026-05-05 03:00:50
New phase files:
- memory/dreaming/light/2026-05-05.md (~20KB)
- memory/dreaming/rem/2026-05-05.md (~128B)
- memory/dreaming/deep/2026-05-05.md (~154B)
Recall store after run: 55 entries, 0 promoted
The quality side is not the main problem here. Promoted 0 can be normal because durable memory should require repeated evidence.
The problem is residue:
03:00–03:03 window under ~/.openclaw/agents/main/sessions:
- 61 files touched/created in the window
- total size ~5.0 MB
- 37 files matched dream/memory-related patterns
- matched size ~5.0 MB
Examples from that window include many .trajectory.jsonl sidecars around 200KB each and paired/small .jsonl files:
9826c96c-37ce-467b-8f5f-7f96c874ad40.jsonl 10247 03:00:22
9826c96c-37ce-467b-8f5f-7f96c874ad40.trajectory.jsonl 213313 03:00:23
336562ec-8534-4b0e-95d3-115e13f49c4f.trajectory.jsonl 206977 03:00:40
32defa40-27a0-43da-a6be-337b46f78d02.trajectory.jsonl 215363 03:00:50
fbc5934e-8d3c-4f87-bb95-258e3712124d.jsonl 3933 03:00:54
fbc5934e-8d3c-4f87-bb95-258e3712124d.trajectory.jsonl 202191 03:00:55
...
The main session store also contains many Dreaming narrative entries (agent:main:dreaming-narrative-*). A local scan found roughly 21 Dreaming/cron-related entries among 23 entries in ~/.openclaw/agents/main/sessions/sessions.json at the time of investigation.
Logs also showed lossless-claw processing Dreaming narrative sessions after Dreaming, including ENOENT for missing .jsonl files. This suggests the primary transcript can disappear while other session/LCM/trajectory lifecycle code still sees references:
lossless-claw afterTurn/bootstrap checkpoint refresh failed: ENOENT stat ~/.openclaw/agents/main/sessions/<sessionId>.jsonl
lossless-claw auto-rotate warning: reason=session-file-stat-failed
Expected behavior
After the Dream Diary/narrative subagent run is processed, internal dreaming-narrative-* sessions should not accumulate in normal session stores/UI, and trajectory sidecars should not accumulate unboundedly.
Expected cleanup should reconcile:
sessions.json entries / session store rows
- primary
.jsonl transcript files
.trajectory.jsonl sidecars
.trajectory-path.json sidecars if present
- LCM/context-engine afterTurn timing, or at least avoid leaving ENOENT races as repeated warnings
Relevant upstream history
There are multiple prior issues/PRs that appear related:
Local code comparison against #70464 direction
Local installed file:
/usr/local/lib/node_modules/openclaw/dist/dreaming-phases-BAWwmoXz.js
Local buildNarrativeSessionKey still includes nowMs in the session key:
function buildNarrativeSessionKey(params) {
const workspaceHash = createHash("sha1").update(params.workspaceDir).digest("hex").slice(0, 12);
return `dreaming-narrative-${params.phase}-${workspaceHash}-${params.nowMs}`;
}
Local startNarrativeRunOrFallback uses the session key as the idempotency key:
params.subagent.run({
idempotencyKey: params.sessionKey,
sessionKey: params.sessionKey,
...
})
Local feature check:
{
"phaseFile": "/usr/local/lib/node_modules/openclaw/dist/dreaming-phases-BAWwmoXz.js",
"serverPluginsFile": "/usr/local/lib/node_modules/openclaw/dist/server-plugins-Bn7zfXhk.js",
"buildNarrativeSessionKeyIncludesNowMs": true,
"buildNarrativeSessionKeyStableWithoutNowMs": false,
"startNarrativeRunUsesSessionKeyAsIdempotencyKey": true,
"hasPreCleanupBeforeNarrativeRun": false,
"scrubMentionsTrajectory": false,
"scrubScansJsonlOnly": true,
"deleteSessionFinallyExists": true,
"pluginOwnedDeleteHasSyntheticAdmin": true
}
This suggests the local 2026.5.3-1 bundle includes some earlier cleanup fixes, but not the later #70464-style stable session key / separate idempotency key / pre-cleanup behavior.
Local code already has the older permission fix
The old operator.admin cleanup failure appears fixed locally.
Local file:
/usr/local/lib/node_modules/openclaw/dist/server-plugins-Bn7zfXhk.js
Local deleteSession(params) now passes pluginRuntimeOwnerId and uses synthetic admin scope for plugin-owned cleanup when needed:
const pluginOwnedCleanupOptions = pluginId ? {
pluginRuntimeOwnerId: pluginId,
...!hasAdminScope(scope?.client) ? {
forceSyntheticClient: true,
syntheticScopes: [ADMIN_SCOPE]
} : {}
} : void 0;
await dispatchGatewayMethod("sessions.delete", {
key: params.sessionKey,
deleteTranscript: params.deleteTranscript ?? true
}, pluginOwnedCleanupOptions);
So this does not look like the older missing-operator.admin problem anymore.
Local scrub appears to ignore trajectory sidecars
dreaming-phases-BAWwmoXz.js contains scrubDreamingNarrativeArtifacts(...), but the local audit found:
- it scans session directory files ending in
.jsonl
- no
.trajectory reference was found in that dreaming cleanup function/file
This matches the observed residue pattern: primary JSONL handling may be partially working, while .trajectory.jsonl / sidecar cleanup is not closed-loop.
Why this matters
One daily Dreaming run produced roughly 5 MB and dozens of session/trajectory artifacts. If Dreaming stays enabled for long-term accumulation, this can cause:
- session directory bloat
- slow
sessions.list / session maintenance
- noisy UI/session switcher entries
- lossless-claw afterTurn ENOENT warnings
- event-loop delay / file-scan pressure over time
Request / proposed fix direction
Please confirm whether #70464 or equivalent logic is intended for 2026.5.x.
Potential fix areas:
- Stabilize Dreaming narrative session keys across runs/workspaces/phases, moving
nowMs into idempotencyKey only.
- Add explicit pre-cleanup before starting a new narrative run.
- Ensure
deleteSession / session maintenance handles trajectory sidecars for Dreaming narrative sessions.
- Ensure cleanup removes/prunes corresponding
sessions.json entries or uses the normal session deletion lifecycle fully.
- Coordinate with context-engine afterTurn lifecycle so cleanup does not race with lossless-claw checkpoint/rotation processing, or at least avoids persistent ENOENT warnings.
Attachments / local artifacts
Local read-only audit artifacts are available under:
~/.openclaw/tmp/dreaming-cleanup-issue-draft-20260505_142912
Relevant generated files:
OpenClaw memory-core Dreaming narrative session cleanup still leaves session/trajectory residue on 2026.5.3-1
Summary
On OpenClaw
2026.5.3-1, the managedmemory-coreDreaming sweep runs successfully, but it still leaves substantial session/trajectory residue after the 03:00 sweep.This looks related to earlier fixed/closed Dreaming cleanup issues, but the local installed 2026.5.3-1 bundle still lacks the key cleanup behavior proposed in open PR #70464.
This report is intended as evidence for either a new issue or a comment on the existing Dreaming cleanup PR/issue. It was prepared from a local read-only audit; no local OpenClaw core patch was applied.
Environment
Actual behavior observed
The official managed Dreaming cron ran successfully around 03:00 Asia/Shanghai.
Evidence from the local audit:
The quality side is not the main problem here.
Promoted 0can be normal because durable memory should require repeated evidence.The problem is residue:
Examples from that window include many
.trajectory.jsonlsidecars around 200KB each and paired/small.jsonlfiles:The
mainsession store also contains many Dreaming narrative entries (agent:main:dreaming-narrative-*). A local scan found roughly 21 Dreaming/cron-related entries among 23 entries in~/.openclaw/agents/main/sessions/sessions.jsonat the time of investigation.Logs also showed lossless-claw processing Dreaming narrative sessions after Dreaming, including ENOENT for missing
.jsonlfiles. This suggests the primary transcript can disappear while other session/LCM/trajectory lifecycle code still sees references:Expected behavior
After the Dream Diary/narrative subagent run is processed, internal
dreaming-narrative-*sessions should not accumulate in normal session stores/UI, and trajectory sidecars should not accumulate unboundedly.Expected cleanup should reconcile:
sessions.jsonentries / session store rows.jsonltranscript files.trajectory.jsonlsidecars.trajectory-path.jsonsidecars if presentRelevant upstream history
There are multiple prior issues/PRs that appear related:
.jsonlandsessions.jsonnot cleaned up.operator.admin/deleteSessionscope.fix(memory-core): prevent dreaming-narrative session leaks (#66358).fix(memory-core): allow bounded dreaming session cleanup.Local code comparison against #70464 direction
Local installed file:
Local
buildNarrativeSessionKeystill includesnowMsin the session key:Local
startNarrativeRunOrFallbackuses the session key as the idempotency key:Local feature check:
{ "phaseFile": "/usr/local/lib/node_modules/openclaw/dist/dreaming-phases-BAWwmoXz.js", "serverPluginsFile": "/usr/local/lib/node_modules/openclaw/dist/server-plugins-Bn7zfXhk.js", "buildNarrativeSessionKeyIncludesNowMs": true, "buildNarrativeSessionKeyStableWithoutNowMs": false, "startNarrativeRunUsesSessionKeyAsIdempotencyKey": true, "hasPreCleanupBeforeNarrativeRun": false, "scrubMentionsTrajectory": false, "scrubScansJsonlOnly": true, "deleteSessionFinallyExists": true, "pluginOwnedDeleteHasSyntheticAdmin": true }This suggests the local 2026.5.3-1 bundle includes some earlier cleanup fixes, but not the later #70464-style stable session key / separate idempotency key / pre-cleanup behavior.
Local code already has the older permission fix
The old
operator.admincleanup failure appears fixed locally.Local file:
Local
deleteSession(params)now passespluginRuntimeOwnerIdand uses synthetic admin scope for plugin-owned cleanup when needed:So this does not look like the older missing-
operator.adminproblem anymore.Local scrub appears to ignore trajectory sidecars
dreaming-phases-BAWwmoXz.jscontainsscrubDreamingNarrativeArtifacts(...), but the local audit found:.jsonl.trajectoryreference was found in that dreaming cleanup function/fileThis matches the observed residue pattern: primary JSONL handling may be partially working, while
.trajectory.jsonl/ sidecar cleanup is not closed-loop.Why this matters
One daily Dreaming run produced roughly 5 MB and dozens of session/trajectory artifacts. If Dreaming stays enabled for long-term accumulation, this can cause:
sessions.list/ session maintenanceRequest / proposed fix direction
Please confirm whether #70464 or equivalent logic is intended for 2026.5.x.
Potential fix areas:
nowMsintoidempotencyKeyonly.deleteSession/ session maintenance handles trajectory sidecars for Dreaming narrative sessions.sessions.jsonentries or uses the normal session deletion lifecycle fully.Attachments / local artifacts
Local read-only audit artifacts are available under:
Relevant generated files:
local-evidence.jsonsession-evidence.txt