Summary
Toggling the dreaming feature in the Control UI creates an orphaned memory-core config block at the top level of plugins.entries (outside the plugin's own entries), which triggers a config warning: plugins.entries.memory-core: plugin disabled (not in allowlist) but config is present.
Steps to Reproduce
- Open Control UI → Settings → Memory/Dreaming section
- Dreaming toggle shows as "off" (even though it may already be enabled in config)
- Toggle it on
- Gateway restarts and shows config warning
Expected Behavior
- Dreaming toggle should correctly reflect the current config state
- Config changes should be written to the correct
plugins.entries.memory-core path, not create a duplicate/orphaned block
Actual Behavior
The Control UI creates a second memory-core config block at the wrong level in openclaw.json:
{
"plugins": {
"entries": {
"memos-local-openclaw-plugin": { ... },
"memory-core": {
"enabled": true,
"config": { "dreaming": { "enabled": true } }
},
"memory-lancedb": { "enabled": true }
},
"memory-core": { // ← Orphaned block created by Control UI
"config": {
"dreaming": { "enabled": true }
}
}
}
}
This orphaned block at plugins.memory-core (outside plugins.entries) triggers:
Config warnings:
- plugins.entries.memory-core: plugin disabled (not in allowlist) but config is present
Root Cause Analysis
The Control UI's dreaming toggle writes config to the wrong JSON path. Instead of updating plugins.entries.memory-core.config.dreaming.enabled, it creates a new plugins.memory-core sibling to plugins.entries. This orphaned block:
- Has no
enabled: true flag (so the system treats it as disabled)
- Is not in
plugins.allow (because it's not a real plugin entry)
- Triggers the "disabled but config present" warning on every startup
Impact
- Config warning on every gateway restart
- Confusing UX: dreaming toggle shows "off" even when already enabled in config
- Potential config bloat if toggled multiple times
Environment
- OS: Windows 11
- OpenClaw version: 2026.4.5 (3e72c03)
- Config: Using
memos-local-openclaw-plugin as memory slot, with memory-core and memory-lancedb also enabled in plugins.entries
Suggested Fix
- Control UI should write dreaming config to
plugins.entries.memory-core.config.dreaming instead of creating a top-level plugins.memory-core block
- Dreaming toggle should read from the correct config path to reflect actual state
- Add config migration/cleanup for orphaned
plugins.memory-core blocks
Summary
Toggling the dreaming feature in the Control UI creates an orphaned
memory-coreconfig block at the top level ofplugins.entries(outside the plugin's own entries), which triggers a config warning:plugins.entries.memory-core: plugin disabled (not in allowlist) but config is present.Steps to Reproduce
Expected Behavior
plugins.entries.memory-corepath, not create a duplicate/orphaned blockActual Behavior
The Control UI creates a second
memory-coreconfig block at the wrong level inopenclaw.json:{ "plugins": { "entries": { "memos-local-openclaw-plugin": { ... }, "memory-core": { "enabled": true, "config": { "dreaming": { "enabled": true } } }, "memory-lancedb": { "enabled": true } }, "memory-core": { // ← Orphaned block created by Control UI "config": { "dreaming": { "enabled": true } } } } }This orphaned block at
plugins.memory-core(outsideplugins.entries) triggers:Root Cause Analysis
The Control UI's dreaming toggle writes config to the wrong JSON path. Instead of updating
plugins.entries.memory-core.config.dreaming.enabled, it creates a newplugins.memory-coresibling toplugins.entries. This orphaned block:enabled: trueflag (so the system treats it as disabled)plugins.allow(because it's not a real plugin entry)Impact
Environment
memos-local-openclaw-pluginas memory slot, withmemory-coreandmemory-lancedbalso enabled inplugins.entriesSuggested Fix
plugins.entries.memory-core.config.dreaminginstead of creating a top-levelplugins.memory-coreblockplugins.memory-coreblocks