Bug type

Behavior bug (incorrect output quality)

Summary

Dreaming can stage raw transport/session metadata as durable short-term candidates and later promote that garbage into MEMORY.md.

This is more severe than the already-reported "daily file pollution" / "raw session-corpus reflections" issues, because the bad metadata is not only shown in Dream Diary or REM reflections — it can survive the whole pipeline and be written into long-term memory.

In my local run, a generated promotion block in MEMORY.md contained transcript-wrapper noise such as:

• Conversation info (untrusted metadata)
• Sender (untrusted metadata)
• raw message_id values (5417, 5421)
• staged-candidate style metadata copied from Dreaming artifacts

I had to manually delete that promotion block from MEMORY.md.

What I observed locally

Environment:

• OpenClaw 2026.4.14
• macOS arm64
• Dreaming enabled via memory-core
• Default runtime model currently configured as derouter-gpt/gpt-5.4

Relevant docs currently say Dream Diary runs a background subagent turn using the default runtime model:

• docs/concepts/dreaming.md

Relevant local config:

{
  "agents": {
    "defaults": {
      "model": {
        "primary": "derouter-gpt/gpt-5.4"
      }
    }
  }
}

Observed pipeline behavior:

1. Dreaming generated low-signal candidate/reflection content based on transcript wrapper metadata
2. Dreaming output polluted DREAMS.md and daily memory files
3. A deep-phase promotion block was appended to MEMORY.md
4. That promotion block contained metadata garbage rather than a distilled memory

The removed bad block in MEMORY.md was under a heading like:

## Promoted From Short-Term Memory (2026-04-16)

and included a promotion marker pointing back to a daily-memory source range, but the promoted content itself contained transport/session metadata rather than a real durable fact.

Why this seems distinct from existing issues

There are already related issues, but this appears to be the next step of the same contamination chain:

• [Bug]: Dreaming/REM surfaces raw session-corpus metadata (untrusted, user, assistant) instead of meaningful reflections #63921 — Dreaming/REM surfaces raw session-corpus metadata in reflections
• Dreaming system pollutes daily memory files, causing heartbeat agents to skip memory logging #66947 — Dreaming pollutes memory/YYYY-MM-DD.md
• [Behavior]: memory-core dreaming deep phase promotes raw verbatim daily-log snippets to MEMORY.md without distillation #67363 — Deep phase writes raw snippets into MEMORY.md without distillation

What I am reporting here is the combination of those problems in one live path:

raw transport metadata -> staged candidate / diary pollution -> daily memory pollution -> erroneous promotion into MEMORY.md

So even if the Dream Diary / daily-file pollution is tolerated temporarily, the current pipeline can still corrupt long-term memory quality.

Expected behavior

Transport-layer/session-wrapper text should never become a promotable durable-memory candidate.

At minimum, the pipeline should reject candidates/snippets containing patterns like:

• Conversation info (untrusted metadata)
• Sender (untrusted metadata)
• System (untrusted) blocks
• raw JSON envelope blobs
• message_id, sender_id, timestamps from inbound wrappers
• reply tags such as [[reply_to_current]]

And deep promotion should refuse to write such content into MEMORY.md even if it somehow survives earlier filters.

Actual behavior

Metadata garbage can survive multiple stages and end up in MEMORY.md.

Likely root cause

This looks like a defense-in-depth gap across multiple layers:

1. Session-corpus ingestion does not sufficiently strip transport wrappers
2. Light/REM candidate generation treats metadata-heavy text as valid evidence
3. Daily-file inline dreaming output makes the bad snippets easier to persist and re-ingest
4. Deep promotion trusts candidate.snippet too much and does not run a final "is this memory-worthy / is this metadata garbage" gate before appending to MEMORY.md

Suggested fixes

1. Ingress filtering

   • Strip inbound envelope blocks and reply tags before Dreaming corpus generation
   • Exclude Conversation info, Sender, System (untrusted), raw JSON objects, and obvious metadata keys

2. Candidate validation

   • Reject staged candidates whose snippet is dominated by metadata tokens / ids / wrapper text
   • Downrank or zero-score candidates containing message_id, sender_id, timestamps, or channel envelope markers

3. Promotion safety gate

   • Before appending to MEMORY.md, run a deterministic final filter:
     • if snippet matches metadata-wrapper heuristics -> skip promotion
     • optionally log the skip reason into dreaming events for debugging

4. Write-path separation

   • Keep Dreaming narrative output separate from daily logs by default (related to Dreaming system pollutes daily memory files, causing heartbeat agents to skip memory logging #66947)

5. Distilled promotion

   • Even for valid candidates, avoid verbatim raw snippet promotion (related to [Behavior]: memory-core dreaming deep phase promotes raw verbatim daily-log snippets to MEMORY.md without distillation #67363)

Impact

Medium to high.

Low-quality Dream Diary output is annoying but recoverable. Pollution of MEMORY.md is worse, because users may trust it as curated long-term memory and not notice that transport metadata has been promoted as if it were meaningful autobiographical memory.

Extra note

I already manually cleaned the affected local files, so I cannot paste the full bad block verbatim anymore without restoring it from history. But the concrete garbage pattern was unmistakable: Conversation info / Sender / raw message_id fields had been promoted into MEMORY.md as if they were a legitimate durable memory.