Summary

The exclusive memory slot in OpenClaw currently disables memory-core entirely whenever a third-party plugin (e.g. hindsight-openclaw, mem0, cognee, qmd, graphiti, NEXO Brain — see #52532) occupies the slot. As a side effect, the dreaming runtime that lives inside memory-core is also disabled, even though dreaming operates on the workspace .md files (MEMORY.md, daily notes, dreams.md) that are the shared substrate every memory plugin reads at bootstrap.

The result: every user who adopts a third-party memory plugin loses workspace file lifecycle management automatically — including the light/deep/REM phases, replay-safe deep promotion, recovery, and the Dream Diary surface introduced in v2026.4.5+.

Reproduction

1. Add memory-core to plugins.allow in openclaw.json
2. Set plugins.slots.memory to any third-party plugin (e.g. hindsight-openclaw)
3. Add a dreaming config block under plugins.entries.memory-core.config.dreaming
4. Restart the gateway

Observed (verified on v2026.4.8):

Config warnings:
- plugins.entries.memory-core: plugin disabled (memory slot set to "hindsight-openclaw") but config is present

memory-core is gated off at the plugin loader level, before its gateway:startup hook (registerShortTermPromotionDreaming) ever runs. The hardcoded local resolver resolveMemoryCorePluginConfig (in extensions/memory-core/index.js) which would otherwise read plugins.entries[\"memory-core\"].config independently of slot resolution is never reached. Dreaming silently does not run.

Why this matters

Dreaming is one of the most valuable community-developed features in OpenClaw — three cooperative phases, replay-safe promotion, REM pattern detection, recovery on health degradation, multilingual conceptual tagging, the Dream Diary UI. The 4.5–4.7 release notes show heavy investment from @vignesh07 and others.

But because dreaming lives inside memory-core and memory-core is mutually exclusive with any other memory slot plugin, the value of dreaming is reserved exclusively for users who run memory-core as their primary memory backend. Every user who adopts a richer third-party memory layer (semantic recall via Hindsight, graph memory via Mem0/Cognee/Graphiti, etc.) is forced to give up dreaming entirely, even though their workspace .md files still need maintenance.

This pushes plugin authors toward two bad options:

1. Reimplement dreaming inside their own plugin — duplicating code, fragmenting effort, diverging from the canonical implementation, losing every future improvement made upstream
2. Leave their users without workspace file lifecycle management — accumulating drift, staleness, and silent truncation in bootstrap context (TOOLS.md/MEMORY.md exceeding bootstrapMaxChars)

Neither is healthy for the ecosystem.

Proposal

Decouple the dreaming runtime from the memory slot ownership. Two possible shapes, in order of architectural cleanliness:

Option A — Dreaming as a system-level service

Promote the dreaming runtime to a top-level OpenClaw service that loads from memory-core's host SDK regardless of which plugin owns the memory slot. Gate it with a top-level config flag:

{
  \"memory\": {
    \"dreaming\": {
      \"enabled\": true,
      \"frequency\": \"0 13 * * *\",
      \"timezone\": \"Europe/Rome\"
    }
  }
}

Dreaming reads workspace .md files via the existing memory-core-host-runtime-files-* modules, which are already file-based and slot-agnostic. The slot plugin (Hindsight, Mem0, …) continues to handle recall/retain semantically without conflict.

Option B — memory-core loadable as a non-slot secondary plugin

Allow memory-core to be loaded as a secondary plugin when added to plugins.allow, even when the memory slot is occupied by another plugin. In this mode:

• memory-core does not claim the slot (no slot conflict)
• memory-core registers only its non-slot hooks: dreaming cron, daily notes lifecycle, dreams.md writer
• The memory slot plugin retains exclusive ownership of recall/retain runtime semantics
• Config under plugins.entries.memory-core.config.dreaming is honored

The current diagnostic ("plugin disabled but config is present") would be removed when this coexistence pattern is explicitly supported.

Option A is more elegant (single source of truth, no plugin gymnastics). Option B is closer to the current code shape and might be a smaller diff.

Impact

• Affected users: Estimated majority of advanced OpenClaw users — anyone running a third-party memory plugin (Hindsight, Mem0, Cognee, Graphiti, QMD, NEXO Brain, …)
• Breaking changes: None. Existing setups (memory-core as slot, no third-party plugin) keep working identically
• Plugin authors: Reduces pressure to reimplement dreaming-equivalent logic inside every memory plugin
• Community investment: Makes the existing investment in dreaming (3 phases, recovery, replay-safety, Dream Diary) universally available

Related

• [Feature]: Cognitive Memory Layer — Persistent, Semantic Memory with Ebbinghaus Decay #52532 — NEXO Brain proposal: same architectural concern, different framing (proposes adding a different memory layer; the underlying gap is identical)
• v2026.4.7 release note: "Memory/dreaming: make Dreams config reads and writes respect the selected memory slot plugin instead of always targeting memory-core" (fix(memory): respect selected slot in dreaming config #62275) — addresses config respect but not the loader-level gating that prevents memory-core from running at all when another plugin is in the slot

Workaround currently used

None viable. Workspace .md files must be maintained manually (or via the agent itself on-demand), without the benefit of the dreaming runtime, until this is resolved upstream.

Happy to contribute a PR for either Option A or Option B if there is interest and a preferred direction from maintainers.