openclaw - 💡(How to fix) Fix [Bug]: dreaming.enabled=false still writes memory/.dreams recall artifacts during normal memory_search

[Bug]: dreaming.enabled=false still writes memory/.dreams recall artifacts during normal memory_search

Bug type Behavior bug

Beta release blocker No

Summary When plugins.entries.memory-core.config.dreaming.enabled=false, normal memory_search still writes dreaming-related artifacts such as memory/.dreams/short-term-recall.json and memory/.dreams/events.jsonl, even though users expect dreaming, dream diary, and automatic promotion side effects to be disabled.

Steps to reproduce

1. Configure plugins.entries.memory-core.config.dreaming.enabled: false.
2. Start OpenClaw with memory-core as the active memory plugin.
3. Run normal memory recall flows such as memory_search from the tool path or openclaw memory search "query" from the CLI.
4. Observe that search results are returned normally.
5. Observe that memory/.dreams/short-term-recall.json and/or memory/.dreams/events.jsonl are created or updated.

Expected behavior With dreaming.enabled=false, OpenClaw should still allow ordinary memory_search, memory_get, and session transcript recall, but it should not produce dreaming/promotion side effects such as .dreams recall traces, dream diary output, or automatic promotion artifacts.

Actual behavior Managed dreaming flows are disabled correctly, but ordinary memory search recall tracking still writes .dreams artifacts. The main observed files are:

• memory/.dreams/short-term-recall.json
• memory/.dreams/events.jsonl

OpenClaw version Observed in source investigation on releases from v2026.5.2 through v2026.5.18, with current repo behavior matching the same write paths.

Operating system Windows 11

Install method pnpm dev / source checkout

Model NOT_ENOUGH_INFO

Provider / routing chain NOT_ENOUGH_INFO

Additional provider/model setup details This issue does not appear to depend on a specific model provider. The suspected write path is in memory-core recall tracking rather than model-specific dreaming generation.

Logs, screenshots, and evidence Source investigation points to two ordinary search paths that still call recordShortTermRecalls(...) without guarding on dreaming.enabled:

• extensions/memory-core/src/tools.ts:334
• extensions/memory-core/src/tools.ts:114
• extensions/memory-core/src/cli.runtime.ts:1232
• extensions/memory-core/src/short-term-promotion.ts:934

The managed dreaming flows do respect the flag:

• extensions/memory-core/src/dreaming.ts:508
• extensions/memory-core/src/dreaming-phases.ts:1815
• extensions/memory-core/src/dreaming-phases.ts:1831
• extensions/memory-core/src/dreaming.ts:422

Relevant write points:

• extensions/memory-core/src/short-term-promotion.ts:876 writes memory/.dreams/short-term-recall.json
• src/memory-host-sdk/events.ts:55 appends memory/.dreams/events.jsonl

Impact and severity Affected: users who disable dreaming but still use normal memory search Severity: Medium Frequency: Expected on ordinary memory search paths when recall tracking runs Consequence: unexpected .dreams artifact churn, confusing config semantics, and unwanted background memory-promotion side effects despite dreaming being disabled

Additional information This looks more like a behavior bug than intended config semantics. Current docs describe dreaming.enabled as the master switch for dreaming:

• docs/reference/memory-config.md:589
• docs/gateway/configuration-reference.md:311

Minimal fix direction:

• Keep ordinary memory_search / memory_get working
• Keep session transcript recall and memory wiki working
• Stop auto recall-tracking writes when dreaming.enabled=false

Smallest likely patch surface:

• extensions/memory-core/src/tools.ts
• extensions/memory-core/src/cli.runtime.ts

Those call sites can skip recordShortTermRecalls(...) when top-level dreaming is disabled, without changing core memory search behavior or non-dreaming memory surfaces.