openclaw - ✅(Solved) Fix memory-core dreaming is unreachable when another plugin owns `plugins.slots.memory` [1 pull requests, 2 comments, 3 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#63590Fetched 2026-04-10 03:42:37
View on GitHub
Comments
2
Participants
3
Timeline
4
Reactions
0
Timeline (top)
commented ×2cross-referenced ×1referenced ×1

The memory-core plugin declares kind: "memory" and includes a full dreaming engine (light → REM → deep phases) with output to MEMORY.md and DREAMS.md. However, it cannot coexist with any other memory plugin on the same slot. When plugins.slots.memory is bound to a different plugin (e.g. memory-lancedb-hybrid), the memory-core plugin is silently disabled and its command handler (/dreaming), system event handler, and cron-job registration are never activated. The result is that dreaming cannot be triggered by any means once a slot conflict exists.


Root Cause

TriggerResult
/dreaming statusCommand not registered (plugin disabled)
openclaw agent --message "/dreaming status"Command not found
openclaw system event --text "__openclaw_memory_core_short_term_promotion_dream__"Returns ok, but handler not registered — no output
Direct Node.js import of runDreamingSweepPhasesRequires full plugin runtime (cfg, logger, subagent, pluginConfig) — not trivially invokable
Cron jobNever registered because plugin is disabled

Fix Action

Fixed

PR fix notes

PR #63605: fix(memory-lancedb): accept dreaming config for slot-aware dreaming

Description (problem / solution / changelog)

Summary

Fixes #63590.

When plugins.slots.memory = "memory-lancedb", the shared dreaming resolver (resolveMemoryDreamingPluginConfig in src/memory-host-sdk/dreaming.ts) already correctly reads dreaming config from plugins.entries.memory-lancedb.config.dreaming — the slot-aware plumbing was already in place. However, memoryConfigSchema in the lancedb extension rejected the dreaming key as an unknown property, producing a hard validation failure that prevented the gateway from starting:

Config invalid at ~/.openclaw/openclaw.json:
  × plugins.entries.memory-lancedb.config: invalid config: must NOT have additional properties

This meant users who set plugins.slots.memory = "memory-lancedb" (the recommended memory backend) could not configure dreaming at all, even though the runtime was ready to consume it.

Changes

  • extensions/memory-lancedb/config.ts — add dreaming?: unknown to MemoryConfig and "dreaming" to the assertAllowedKeys allowlist; pass cfg.dreaming through in the parsed output
  • extensions/memory-lancedb/index.test.ts — add test that dreaming is accepted and passed through; add test that other unknown keys are still rejected

dreaming is typed as unknown (rather than importing the full MemoryDreamingConfig shape) to avoid cross-package coupling and stay forward-compatible as the dreaming schema evolves.

Test plan

  • pnpm vitest run --project extension-memory passes
  • Config with plugins.entries.memory-lancedb.config.dreaming.enabled = true passes openclaw config validate
  • Gateway starts without errors
  • Dreaming respects the config (enabled/disabled, frequency) when lancedb owns the memory slot

Changed files

  • extensions/memory-lancedb/config.ts (modified, +15/-1)
  • extensions/memory-lancedb/index.test.ts (modified, +13/-0)
  • extensions/memory-lancedb/openclaw.plugin.json (modified, +4/-0)

Code Example

{
  "plugins": {
    "slots": {
      "memory": "memory-lancedb-hybrid"
    },
    "entries": {
      "memory-core": {
        "enabled": true,
        "config": {
          "dreaming": {
            "enabled": true,
            "frequency": "",
            "timezone": "America/Los_Angeles",
            "verboseLogging": true,
            "storage": { "mode": "separate", "separateReports": true },
            "phases": {
              "light": { "enabled": true, "lookbackDays": 7, "limit": 20 },
              "rem":    { "enabled": true, "lookbackDays": 14, "limit": 10 },
              "deep":   { "enabled": true, "limit": 15, "minScore": 0.7 }
            }
          }
        }
      }
    }
  }
}

---

Config warnings:
- plugins.entries.memory-core: plugin disabled (memory slot set to "memory-lancedb-hybrid") but config is present
RAW_BUFFERClick to expand / collapse

Summary

The memory-core plugin declares kind: "memory" and includes a full dreaming engine (light → REM → deep phases) with output to MEMORY.md and DREAMS.md. However, it cannot coexist with any other memory plugin on the same slot. When plugins.slots.memory is bound to a different plugin (e.g. memory-lancedb-hybrid), the memory-core plugin is silently disabled and its command handler (/dreaming), system event handler, and cron-job registration are never activated. The result is that dreaming cannot be triggered by any means once a slot conflict exists.


Environment

  • OpenClaw version: 2026.4.9
  • Plugin: memory-core (bundled at openclaw/dist/extensions/memory-core/)
  • Competing plugin: memory-lancedb-hybrid 1.2.0 (workspace skills, also kind: "memory")
  • Slot owner: memory-lancedb-hybrid bound to plugins.slots.memory

Relevant plugin config:

{
  "plugins": {
    "slots": {
      "memory": "memory-lancedb-hybrid"
    },
    "entries": {
      "memory-core": {
        "enabled": true,
        "config": {
          "dreaming": {
            "enabled": true,
            "frequency": "",
            "timezone": "America/Los_Angeles",
            "verboseLogging": true,
            "storage": { "mode": "separate", "separateReports": true },
            "phases": {
              "light": { "enabled": true, "lookbackDays": 7, "limit": 20 },
              "rem":    { "enabled": true, "lookbackDays": 14, "limit": 10 },
              "deep":   { "enabled": true, "limit": 15, "minScore": 0.7 }
            }
          }
        }
      }
    }
  }
}

Steps to Reproduce

  1. Install or activate memory-lancedb-hybrid as a memory plugin and bind it to plugins.slots.memory.
  2. Add a memory-core.config.dreaming block to plugins.entries.memory-core with dreaming.enabled: true (the dreaming config is accepted).
  3. Reload the gateway (SIGHUP or restart).
  4. Observe: Config warnings: plugins.entries.memory-core: plugin disabled (memory slot set to "memory-lancedb-hybrid") but config is present — this warning fires on every CLI invocation.
  5. Attempt to trigger dreaming via any known path (see Evidence below) — all silently no-op.

Expected Behavior

The /dreaming command is registered and accepts status, on, off, help. When dreaming.enabled is true, the plugin also registers a cron job ("Memory Dreaming Promotion") with schedule dreaming.frequency. The cron fires a system event __openclaw_memory_core_short_term_promotion_dream__ which the agent handles by calling runDreamingSweepPhases. This runs light → REM → deep phases and writes output files.


Actual Behavior

memory-core is marked disabled by the slot conflict. Its registerDreamingCommand handler (index.js:97-103) is never called. The /dreaming command is not registered. The cron job is not registered. The system event handler is not registered. All trigger paths silently no-op.


Evidence

Exact warning message

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

This warning appears on every openclaw CLI invocation when memory-core entry has a config block but the slot is bound elsewhere.

Attempted trigger paths and outcomes

TriggerResult
/dreaming statusCommand not registered (plugin disabled)
openclaw agent --message "/dreaming status"Command not found
openclaw system event --text "__openclaw_memory_core_short_term_promotion_dream__"Returns ok, but handler not registered — no output
Direct Node.js import of runDreamingSweepPhasesRequires full plugin runtime (cfg, logger, subagent, pluginConfig) — not trivially invokable
Cron jobNever registered because plugin is disabled

Source code citations

  • Plugin disabled mechanism: openclaw/dist/extensions/memory-core/index.jsregisterDreamingCommand called at line 97 only if plugin initializes; plugin initialization is skipped when slot is occupied.
  • 3-phase sweep documentation: `index.js:61-63:
    • "implementation detail: each sweep runs light -> REM -> deep."
    • "deep is the only stage that writes durable entries to MEMORY.md."
    • "DREAMS.md is for human-readable dreaming summaries and diary entries."
  • Cron job registration: openclaw/dist/dreaming-DKm55QYQ.jsbuildManagedDreamingCronJob creates cron with sessionTarget: "main" and payload { kind: "systemEvent", text: "__openclaw_memory_core_short_term_promotion_dream__" } — never called because plugin is disabled.
  • System event text constant: DREAMING_SYSTEM_EVENT_TEXT = "__openclaw_memory_core_short_term_promotion_dream__" — defined in openclaw/dist/dreaming-DKm55QYQ.js
  • Memory slot binding: openclaw.json plugins.slots.memory = "memory-lancedb-hybrid" — this is what causes memory-core to be marked disabled.
  • Slot conflict warning: appears to come from the plugin loader when a plugin is superseded by a slot binding.

Proposed Fix Options

Option A — Sidecar mode for dreaming

Allow memory-core (or a new memory-dreaming plugin) to operate without owning the memory slot. The dreaming feature does not actually need to be the memory provider — it reads memory events and writes durable files. Decouple the dreaming surface from the memory slot by:

  1. Declaring memory-core with kind: "dreaming" (new kind) or kind: "memory" + a sidecar: true flag.
  2. When sidecar: true, the plugin registers its commands and hooks without claiming the memory slot.
  3. The dreaming engine reads from state.db (memory_events) and writes to MEMORY.md/DREAMS.md without needing to be the active memory provider.

Option B — Non-memory plugin kind for memory-core

Ship memory-core as a plugin that declares only kind: "system" or a new kind: "memory-dreaming". Remove the kind: "memory" declaration entirely since the plugin does not actually provide the memory tool interface (recall/store/forget). The slot conflict only occurs between plugins of the same kind.

Option C — Allow multiple plugins on the memory slot with declared compatibility

Allow plugins.slots.memory to bind to a list of plugins instead of a single plugin, with a declared compatibility/priority order. The memory slot becomes a chain: first plugin that claims to own it is used for recall/store/forget, but other plugins can still register their hooks/commands/crons. This is architecturally complex but would allow both memory-lancedb-hybrid (primary recall) and memory-core (dreaming) to coexist.


Impact

Without a fix, users cannot enable memory-core dreaming on any OpenClaw install that uses any other memory plugin (including memory-lancedb-hybrid, which is the recommended memory plugin). This effectively makes the entire memory-core dreaming feature inaccessible in any non-trivial deployment.


Tags

  • plugin-system
  • memory
  • memory-core
  • slots
  • dreaming

extent analysis

TL;DR

To resolve the issue, consider modifying the memory-core plugin to operate without owning the memory slot, either by introducing a sidecar mode or redeclaring its kind to be non-memory related.

Guidance

  1. Assess the proposed fix options: Evaluate the feasibility of each proposed fix option (A, B, C) in the context of your specific use case and the OpenClaw architecture.
  2. Determine the compatibility requirements: If opting for Option C, carefully consider the compatibility and priority order of plugins bound to the memory slot to avoid conflicts.
  3. Test the chosen solution: Thoroughly test the implemented fix to ensure that the memory-core plugin can coexist with other memory plugins and that the dreaming feature functions as expected.
  4. Monitor for potential regressions: Keep an eye out for any unexpected behavior or errors that might arise from the changes made to the plugin or slot configuration.

Example

No specific code example is provided due to the complexity and variability of potential solutions. However, the general approach would involve modifying the memory-core plugin's configuration or code to accommodate one of the proposed fix options.

Notes

  • The choice of fix depends on the specific requirements and constraints of the OpenClaw deployment.
  • Introducing a sidecar mode or changing the plugin kind may have implications for other parts of the system that interact with the memory-core plugin.
  • Allowing multiple plugins on the memory slot adds complexity and may require significant changes to the plugin system architecture.

Recommendation

Apply Option A — Sidecar mode for dreaming, as it seems to be the most straightforward approach to decoupling the dreaming feature from the memory slot, allowing memory-core to coexist with other memory plugins without significant architectural changes.

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