Skip to content

Bug: memory-core Dreaming cleanup still leaves narrative session trajectory residue on 2026.5.3-1 #77723

Description

@smasunspot

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:

  1. Stabilize Dreaming narrative session keys across runs/workspaces/phases, moving nowMs into idempotencyKey only.
  2. Add explicit pre-cleanup before starting a new narrative run.
  3. Ensure deleteSession / session maintenance handles trajectory sidecars for Dreaming narrative sessions.
  4. Ensure cleanup removes/prunes corresponding sessions.json entries or uses the normal session deletion lifecycle fully.
  5. 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:

Metadata

Metadata

Assignees

No one assigned

    Labels

    P2Normal backlog priority with limited blast radius.impact:crash-loopCrash, hang, restart loop, or process-level availability failure.impact:session-stateSession, memory, transcript, context, or agent state can drift or corrupt.staleMarked as stale due to inactivity

    Type

    No type

    Fields

    Priority

    None yet

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions