OpenClaw 'Dreaming' Explained: How Your Agent Now Remembers While It Sleeps | OpenClaw DC

OpenClaw v2026.4.9 introduced “Dreaming,” a memory system where your agent replays old daily notes and consolidates them into durable, searchable memory during idle time. Think of it like how human brains process memories during sleep. Old conversations that were lost after compaction can now be recovered and stored permanently. Here is how it works and how to use it.

TL;DR: Dreaming replays your agent’s old daily notes into a persistent Dreams store during idle time. No second memory stack required. Conversations you had weeks ago are no longer lost to compaction. Upgrade to v2026.4.9 and flip one config flag.

How to Upgrade

npm install -g openclaw@latest

Verify: openclaw --version should show 2026.4.9.

If you run into problems, check the troubleshooting guide. Coming from 4.1? Read the 4.1 Task Brain release notes first so you do not miss changes to background task configuration.

What Dreaming Actually Does

Every time you talk to your OpenClaw agent, the conversation gets logged as a daily note. These notes are useful in the short term because the agent can reference them for context. But daily notes pile up. After a configurable retention window, they get compacted down to save space. Compaction keeps a thin summary and throws away the detail. That detail is gone forever.

Dreaming fixes this by running a replay cycle during idle time. When your agent is not actively handling a conversation, it picks up old daily notes, reads through them, extracts the important facts, preferences, decisions, and context, and writes those into a separate durable store called Dreams. Dreams are indexed and searchable. They persist indefinitely. The original daily note can still be compacted on schedule, but the knowledge it contained lives on.

The name is intentional. The process mirrors what neuroscience tells us about REM sleep in humans. During REM, the brain replays the day’s experiences, consolidates important memories into long-term storage, and lets the rest fade. OpenClaw’s Dreaming does exactly that for your agent’s memory.

REM Backfill Explained

REM backfill is the mechanism that powers Dreaming. Here is what happens step by step:

1. Scan. The agent checks the daily-notes directory for files older than the configured threshold (default: 3 days).
2. Replay. Each qualifying note is fed through a summarization pass. This is not a simple truncation. The agent re-reads the full conversation, identifies durable facts (user preferences, project decisions, key dates, relationship context), and separates them from ephemeral chatter.
3. Extract. Durable facts get structured into memory entries with metadata: source date, confidence level, topic tags, and a reference back to the original note.
4. Write. The structured entries are written into the Dreams store, a dedicated section of the memory system that is separate from daily notes and the working context window.
5. Mark. The original daily note is flagged as “dreamed,” so it is not replayed again. Compaction can proceed on its normal schedule.

The entire cycle runs without a second memory stack. Previous workarounds for long-term memory in OpenClaw required running a separate vector database or embedding pipeline alongside the agent. Dreaming eliminates that complexity. It uses the same memory system, just a different partition within it.

Backfill also works retroactively. If you have weeks or months of un-dreamed daily notes sitting in your agent’s storage, the first Dreaming cycle will process them all. Depending on volume, the initial backfill may take a few idle cycles to complete. After that, it stays caught up incrementally.

The Compaction Memory Loss Problem

This is the issue that drove the feature. OpenClaw users have been vocal about it since the early 3.x releases. You would have a long, detailed conversation with your agent about a project. A week later, you would reference something from that conversation and the agent would have no memory of it. The daily note had been compacted. The detail was gone.

The workaround was to manually pin important notes or run a separate memory pipeline. Both approaches required ongoing effort from the user. Dreaming automates the entire process. You do not need to pin anything. You do not need to run a second system. The agent handles it on its own, during time it would otherwise spend doing nothing.

For a deeper look at how OpenClaw’s memory layers work together, read the memory systems overview.

How to Enable and Configure Dreaming

Dreaming is off by default in v2026.4.9 to give users control over the rollout. Enable it with one command:

openclaw config set memory.dreaming.enabled true

Optional tuning:

openclaw config set memory.dreaming.threshold 3d
openclaw config set memory.dreaming.idleTrigger 15m
openclaw config set memory.dreaming.maxReplayBatch 20

• threshold controls how old a daily note must be before it qualifies for replay. Default is 3 days.
• idleTrigger sets how long the agent must be idle before a Dreaming cycle starts. Default is 15 minutes.
• maxReplayBatch limits how many notes are processed per cycle to avoid CPU spikes on resource-constrained devices.

Once enabled, you can monitor Dreaming activity in the logs with openclaw logs --filter dreaming or through the new diary timeline UI.

Diary Timeline UI

Version 4.9 also ships a diary timeline, a visual interface for browsing daily notes and Dreams side by side. Access it from the dashboard or with the /diary command in any chat interface.

The timeline shows daily notes on the left and their corresponding Dream entries on the right. You can see exactly what the agent extracted from each conversation, when the replay happened, and what facts were stored. Clicking a Dream entry expands it to show the full structured memory with source references.

This is useful for auditing. If the agent remembers something you do not expect, or forgets something you thought it should keep, the diary timeline gives you a clear trail to follow. You can manually promote or delete Dream entries directly from the UI.

SSRF Hardening

All outbound requests made by OpenClaw tools now pass through a stricter SSRF filter. The filter blocks requests to private IP ranges, link-local addresses, and metadata endpoints (169.254.x.x, 10.x.x.x, 192.168.x.x, and cloud provider metadata URLs). This applies to web_search, web_fetch, API tool calls, and any custom MCP server that makes outbound HTTP requests.

If you self-host services on a private network that the agent needs to reach, you can allowlist specific ranges:

openclaw config set security.ssrf.allowlist '["10.0.1.0/24"]'

The default posture is deny-all for private ranges. This is a security-first change that closes a class of vulnerabilities where a malicious prompt could trick the agent into hitting internal services.

Android Pairing Overhaul

The Android companion app pairing flow has been rebuilt from scratch. The old QR-code handshake was unreliable on certain devices and failed silently when the camera permission was revoked mid-scan. The new flow uses a six-digit PIN displayed on both devices. Enter the PIN on either side and the pairing completes in under two seconds.

The new flow also supports pairing over Tailscale and WireGuard networks, which the QR system could not handle because it embedded local IP addresses that were not routable across VPN tunnels.

What Comes Next

Dreaming is the foundation for a longer roadmap around agent memory. Future releases will add selective forgetting (letting the agent prune outdated Dreams), cross-agent Dream sharing for multi-agent setups, and Dream-aware retrieval that weights recent Dreams higher during context assembly.

If you want help setting up Dreaming for your use case or need guidance on OpenClaw configuration, book a call with us on Calendly.