openclaw - ✅(Solved) Fix [Bug]: Dreaming Dream Diary entries are written to daily memory files instead of only to DREAMS.md [1 pull requests, 1 comments, 2 participants]

Official PRs (…)
ON THIS PAGE

Recommended Tools

×6

Utilities matched from this issue’s tags and category — try them while you read without losing context.

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

Helpful · Quick feedback

Loading…
GitHub stats
openclaw/openclaw#66328Fetched 2026-04-15 06:26:39
View on GitHub
Comments
1
Participants
2
Timeline
5
Reactions
0
Author
Participants
Timeline (top)
commented ×1cross-referenced ×1mentioned ×1referenced ×1

Fix Action

Fixed

PR fix notes

PR #66412: fix(dreaming): default storage.mode to "separate" so phase blocks stop polluting daily memory files

Description (problem / solution / changelog)

Summary

Closes #66328.

The dreaming pipeline writes Light Sleep and REM Sleep phase blocks to the location selected by dreaming.storage.mode. The mode was already wired up to support "inline" | "separate" | "both" in writeDailyDreamingPhaseBlock, but the unset-default fallback in src/memory-host-sdk/dreaming.ts was hardcoded to "inline". As a result, every installation that didn't explicitly set plugins.entries.memory-core.config.dreaming.storage.mode silently got dream phase blocks injected straight into memory/YYYY-MM-DD.md.

This PR flips the unset-default to "separate". Phase blocks now land in memory/dreaming/{phase}/YYYY-MM-DD.md by default, leaving the daily memory file alone.

Why this matters (#66328)

The reporter measured 340 lines of Light Sleep narrative being injected into a single daily file. A second host on a v2026.4.12 install observed 475 inline lines from the Light phase plus 14 from REM in a single sweep, leaving the daily file unusable as a "what happened today" record - the same dreaming output that gets dumped into DREAMS.md (working correctly) was also being dumped inline.

The reporter also surfaced the symptom side: when an agent reads memory/YYYY-MM-DD.md to answer "what did I do yesterday?" it ends up reading hundreds of lines of dreaming narrative instead of actual event records.

stripManagedDailyDreamingLines already protects the daily-ingestion scanner from re-ingesting dream marker blocks as recall candidates, so the recall side is unaffected by either mode. Flipping the default just stops the daily file from being written to in the first place.

Backward compatibility

Operators who actually want inline behavior can opt in explicitly:

"plugins": {
  "entries": {
    "memory-core": {
      "config": {
        "dreaming": {
          "storage": { "mode": "inline" }
        }
      }
    }
  }
}

normalizeStorageMode continues to accept all three documented modes (inline | separate | both); only the unset-default fallback changes. The MemoryDreamingStorageMode type is unchanged.

Test changes

  • src/memory-host-sdk/dreaming.test.ts adds two new assertions: one pinning the new default shape, and one confirming explicit "inline" still round-trips for opt-in callers.
  • extensions/memory-core/src/dreaming.test.ts updates four default-output assertions in resolveShortTermPromotionDreamingConfig from mode: "inline" to mode: "separate".
  • extensions/memory-core/src/dreaming-phases.test.ts pins LIGHT_DREAMING_TEST_CONFIG and the inline-mode harness in checkpoints daily ingestion and skips unchanged daily files to storage.mode: "inline" with an inline comment, since those tests rely on inline-mode side effects on memory/<day>.md and now need to opt in explicitly. The substantive coverage they provide is unchanged.

The schema accept-test in extensions/memory-core/src/config.test.ts and the inline-mode write-path tests in extensions/memory-core/src/dreaming-markdown.test.ts intentionally keep asserting mode: "inline" because they cover input handling and the inline write path itself, both of which still need to work.

Validation

  • Targeted suite (the 9 test files touching this code): 125/125 pass
    • pnpm vitest run extensions/memory-core/src/dreaming-phases.test.ts extensions/memory-core/src/dreaming.test.ts extensions/memory-core/src/dreaming-markdown.test.ts extensions/memory-core/src/dreaming-narrative.test.ts extensions/memory-core/src/dreaming-command.test.ts extensions/memory-core/src/dreaming-repair.test.ts extensions/memory-core/src/memory-events.test.ts extensions/memory-core/src/config.test.ts src/memory-host-sdk/dreaming.test.ts
  • Pre-commit checks (pnpm check): madge import cycles, tsgo, oxlint, host-env-policy:swift, webhook auth body order, pairing-store-group, pairing-account-scope - all clean.

Changed files

  • CHANGELOG.md (modified, +1/-0)
  • extensions/memory-core/src/dreaming-phases.test.ts (modified, +9/-0)
  • extensions/memory-core/src/dreaming.test.ts (modified, +4/-4)
  • extensions/memory-core/src/dreaming.ts (modified, +1/-1)
  • src/memory-host-sdk/dreaming.test.ts (modified, +25/-0)
  • src/memory-host-sdk/dreaming.ts (modified, +1/-1)

Code Example

"phase":"light", "lineCount":340, "storageMode":"inline"
"phase":"rem", "lineCount":14, "storageMode":"inline"
RAW_BUFFERClick to expand / collapse

Bug Description

When the Dreaming System runs, it writes Dream Diary narrative content to memory/YYYY-MM-DD.md files instead of only to DREAMS.md as documented.

This makes daily memory files unusable for their intended purpose. When an agent tries to answer "what did I do yesterday?", it reads hundreds of lines of Dream Diary narrative instead of actual event records.

Expected Behavior (per docs)

From the Dreaming docs:

Dreaming 会将人类可读的叙事输出写入 DREAMS.md(或现有的 dreams.md)。

Dream Diary is human-readable narrative output meant for the Dreams UI. Daily memory files (memory/YYYY-MM-DD.md) should contain only event records and promoted long-term memory entries.

What actually happens

Example from memory/2026-04-13.md:

  • ## Light Sleep section: 340 lines of Dream Diary narrative content
  • ## REM Sleep section: 14 lines of REM narrative content
  • No actual event records visible — entirely dominated by dream output

Evidence from memory/.dreams/events.jsonl:

"phase":"light", "lineCount":340, "storageMode":"inline"
"phase":"rem", "lineCount":14, "storageMode":"inline"

Both Light and REM phases write their full narrative output inline to the daily memory file, not just to DREAMS.md.

Expected Fix

Dream Diary narrative content should only be written to DREAMS.md. The ## Light Sleep and ## REM Sleep sections in daily memory files should contain only structural phase markers/metadata — not the full dream narrative output.

Environment

  • OpenClaw 2026.4.12

extent analysis

TL;DR

The Dreaming System should be configured to write Dream Diary narrative content only to DREAMS.md, not to daily memory files.

Guidance

  • Review the Dreaming System configuration to ensure it aligns with the documented behavior of writing human-readable narrative output to DREAMS.md.
  • Check the storageMode setting in the memory/.dreams/events.jsonl file to see if it can be adjusted to prevent inline writing of dream narrative content to daily memory files.
  • Verify that the Dreaming System is using the correct output file for Dream Diary narrative content by checking the system's documentation and configuration.
  • Consider updating the Dreaming System to use a separate output mechanism for dream narrative content to prevent overwriting daily memory files.

Example

No code snippet is provided as the issue seems to be related to configuration or system behavior rather than code.

Notes

The issue seems to be specific to the OpenClaw 2026.4.12 environment, and the fix may depend on the specific configuration and implementation of the Dreaming System.

Recommendation

Apply a workaround by adjusting the storageMode setting or configuring the Dreaming System to use a separate output file for dream narrative content, as updating to a fixed version is not mentioned in the issue.

Vote matrix · Quick signals

Works
Did the solution work? Tap to confirm.
Easy Fix
Was it a quick fix?
Time Saver
Did it save you time?
Blocking
Was it severely blocking?
Common Issue
Are others likely hitting this too?
Flaky / Intermittent
Is it intermittent?
Verified / Reproducible
Can you reproduce it reliably?
Loading…

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

Back to top recommendations

TRENDING