openclaw - 💡(How to fix) Fix Dreaming narrative generation always falls back; DREAMS.md never gets real entries [2 comments, 2 participants]

openclaw: 2026.5.7 Workspace: dreaming enabled at default 0 3 * * *, single workspace

Symptoms

• openclaw memory status reports Dreaming artifacts: diary absent after 5+ days of cron firings. DREAMS.md is never created.
• Recall store: 415 entries · 0 promoted (and 28/0 on a second workspace).
• Per-phase reports under memory/dreaming/{light,deep,rem}/YYYY-MM-DD.md ARE written daily, but:
  • Every Light Sleep candidate has identical totalScore: 0.58, recallCount: 0, one queryHash — all below the deep gates (minScore=0.8, minRecallCount=3, minUniqueQueries=3), so Deep promotes 0 candidates every night.
  • Highest-frequency candidate snippets are inter-session routing metadata, e.g. "User: [Subagent Context] You are running as a subagent (depth 1/1)...", "[Inter-session message] sourceSession=agent:main:...". The corpus ingestion appears not to be redacting / filtering these.

Likely root cause (from reading the bundled dist)

In dist/dreaming-phases-*.js, narrative generation is a single try/catch around params.subagent.run(...). The only fallback path is:

} catch (runErr) {
  if (!isRequestScopedSubagentRuntimeError(runErr)) throw runErr;
  await appendNarrativeEntry({
    narrative: buildRequestScopedFallbackNarrative(params.data), // first raw snippet
    ...
  });
  logger.info(`memory-core: narrative generation used fallback for ${phase} phase because subagent runtime is request-scoped.`);
}

buildRequestScopedFallbackNarrative returns the first non-empty snippet verbatim — not a generated diary entry:

function buildRequestScopedFallbackNarrative(data) {
  return data.snippets.map(v => v.trim()).find(v => v.length > 0)
      ?? (data.promotions ?? []).map(v => v.trim()).find(v => v.length > 0)
      ?? "A memory trace surfaced, but details were unavailable in this run.";
}

If the dreaming cron always runs in a request-scoped subagent runtime (OPENCLAW_SUBAGENT_RUNTIME_REQUEST_SCOPE), then on every workspace the spawn fails → fallback fires → DREAMS.md gets raw transcript scraps (or, as in my case, the appendNarrativeEntry itself silently fails or is gated and DREAMS.md never appears at all).

Schema/runtime config notes

• dreaming.model and dreaming.execution.defaults.model are both accepted by the schema and read by the resolver — but they only matter for the subagent spawn that is itself being rejected.
• There is no documented or coded "direct-model narrative" path that skips the subagent.

Requests

1. Either (a) hoist narrative spawning so it doesn't run inside a request-scoped runtime, (b) add an actual direct-model narrative path keyed on execution.model, or (c) make the fallback at least summarize/format instead of echoing the first raw snippet.
2. Add redaction for inter-session routing metadata ([Subagent Context], [Inter-session message], <<<END_UNTRUSTED_CHILD_RESULT>>>, etc.) to the session-corpus ingestion path so these don't dominate the recall store.
3. Have openclaw memory status surface "narrative fallback fired N times" so this is visible instead of silently downgrading.

Happy to share corpus/recall samples privately if useful.

Authored by Merlin 🪄