You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
During overnight dreaming, the light-phase work summary block emits identical commit-list content every cycle for ~6 hours, producing apparent duplicates in DREAMS.md. Only the REM reflection block (which precedes each work summary) shows incrementing memory counts, suggesting the REM input pipeline is incremental but the work-summary pipeline is not.
Evidence (inline excerpts)
DREAMS.md is auto-published from ~/.openclaw/memory/DREAMS.md. Two adjacent cycles 29 minutes apart, on the same workspace:
April 12, 2026 at 2:00 AM (cycle 1):
Reflections: Theme: `assistant` kept surfacing across 230 memories.;
confidence: 0.96; evidence: memory/.dreams/session-corpus/2026-04-10.txt:2-2,
memory/.dreams/session-corpus/2026-04-10.txt:4-4, ...; note: reflection
- Added primary issue extraction for pain notifications so notify
output explicitly states the shared main issue instead of only
saying "多源共振". - Updated signals cron notification style ...
commits: `1124b18` `fix: clarify signals pain notifications` ...
April 12, 2026 at 2:29 AM (cycle 2, 29 min later):
Reflections: Theme: `assistant` kept surfacing across 397 memories.;
confidence: 1.00; evidence: memory/.dreams/session-corpus/2026-04-10.txt:2-2,
memory/.dreams/session-corpus/2026-04-10.txt:4-4, ...; note: reflection
- Added primary issue extraction for pain notifications so notify
output explicitly states the shared main issue instead of only
saying "多源共振". - Updated signals cron notification style ...
commits: `1124b18` `fix: clarify signals pain notifications` ...
The REM reflection block went 230 memories → 397 memories (so the cycle did fire fresh and saw new corpus), but the work-summary block is byte-for-byte identical, including the same commit hash 1124b18.
This pattern continues across the same night for 6 cycles (2:00 / 2:29 / 3:29 / 4:29 / 5:29 / 6:29 AM) and the next night for another 5 cycles, producing the same 1124b18 work-summary block emitted verbatim 11 times across two nights. REM memory count climbs through 230 → 397 → 551 → 705 → 846 → 987 → 1239 → 1338 → 1430 → 1526 → 1604 across these cycles.
The full DREAMS.md is in a private repo; happy to share full samples or a session bundle on request.
Steps to reproduce
Have an active workspace with git commits in the last ~24h
Observe DREAMS.md the next morning — work-summary content is identical across cycles
Expected behavior
Light-phase work summary should be incremental: only commits that are new since the last cycle's emit should appear. Alternatively, content could be dedup'd against prior entries within the same dreaming session window.
Actual behavior
Each cycle re-summarizes the same fixed window (apparently "last ~24h commits"), without tracking a "last-emitted cutoff" or any dedup against the prior cycle's output. Result: the same commit-list block repeats across every cycle until the underlying commit window rolls forward.
Light/deep cycle's commit-summarizer reads a fixed time window from git history (or a corpus snapshot) without tracking a per-phase cutoff timestamp, so identical input → identical output every cycle.
Proposed fix sketch
Persist a per-phase lastEmittedAt in dreaming state; summarizer filters input to commits.timestamp > lastEmittedAt before generating the summary, then advances lastEmittedAt on successful emit.
Summary
During overnight dreaming, the light-phase work summary block emits identical commit-list content every cycle for ~6 hours, producing apparent duplicates in DREAMS.md. Only the REM reflection block (which precedes each work summary) shows incrementing memory counts, suggesting the REM input pipeline is incremental but the work-summary pipeline is not.
Evidence (inline excerpts)
DREAMS.md is auto-published from
~/.openclaw/memory/DREAMS.md. Two adjacent cycles 29 minutes apart, on the same workspace:April 12, 2026 at 2:00 AM (cycle 1):
April 12, 2026 at 2:29 AM (cycle 2, 29 min later):
The REM reflection block went
230 memories→397 memories(so the cycle did fire fresh and saw new corpus), but the work-summary block is byte-for-byte identical, including the same commit hash1124b18.This pattern continues across the same night for 6 cycles (2:00 / 2:29 / 3:29 / 4:29 / 5:29 / 6:29 AM) and the next night for another 5 cycles, producing the same
1124b18work-summary block emitted verbatim 11 times across two nights. REM memory count climbs through 230 → 397 → 551 → 705 → 846 → 987 → 1239 → 1338 → 1430 → 1526 → 1604 across these cycles.The full DREAMS.md is in a private repo; happy to share full samples or a session bundle on request.
Steps to reproduce
Expected behavior
Light-phase work summary should be incremental: only commits that are new since the last cycle's emit should appear. Alternatively, content could be dedup'd against prior entries within the same dreaming session window.
Actual behavior
Each cycle re-summarizes the same fixed window (apparently "last ~24h commits"), without tracking a "last-emitted cutoff" or any dedup against the prior cycle's output. Result: the same commit-list block repeats across every cycle until the underlying commit window rolls forward.
Environment
enabled: true, frequency: "0 3 * * *", storage.mode: "separate". No phase-level overrides.Suspected mechanism
Light/deep cycle's commit-summarizer reads a fixed time window from git history (or a corpus snapshot) without tracking a per-phase cutoff timestamp, so identical input → identical output every cycle.
Proposed fix sketch
Persist a per-phase
lastEmittedAtin dreaming state; summarizer filters input tocommits.timestamp > lastEmittedAtbefore generating the summary, then advanceslastEmittedAton successful emit.Related
isContaminatedDreamingSnippetfilter for promotion candidacy — different layer; that filter does not affect diary write path, which is what this bug is about.