Dreaming issue | Friends of the Crustacean 🦞🤝 | Page 1

flint spire Apr 21, 2026, 1:32 PM

#

It doesn't look like dreaming is working. I turned it on a few days ago, and seems to show according to my bot as disabled. openclaw.json"
"memory-core": {
"enabled": true,
"config": {
"dreaming": {
"enabled": true
}
}
}

v.2026.4.15
openclaw memory status --deep:
Memory Search (main)
Provider: gemini (requested: auto)
Model: gemini-embedding-001
Sources: memory
Indexed: 88/95 files · 166 chunks
Dirty: no
Store: ~/.openclaw/memory/main.sqlite
Workspace: ~/.openclaw/workspace
Dreaming: 0 3 * * * (America/Chicago) · limit=10 · minScore=0.8 · minRecallCount=3 · minUniqueQueries=3 · recencyHalfLifeDays=14 · maxAgeDays=30
Embeddings: ready
By source:
memory · 88/95 files · 166 chunks
Vector: ready
Vector dims: 3072
Vector path: ~/.npm-global/lib/node_modules/openclaw/node_modules/sqlite-vec-linux-arm64/vec0.so
FTS: ready
Embedding cache: enabled (271 entries)
Batch: disabled (failures 0/2)
Recall store: 5 entries · 0 promoted · 5 concept-tagged · 0 spaced · scripts=5 latin
Recall path: ~/.openclaw/workspace/memory/.dreams/short-term-recall.json
Recall updated: 2026-04-18T04:30:16.202Z
Dreaming artifacts: diary absent · 0 corpus files · ingestion state absent
Dream corpus: ~/.openclaw/workspace/memory/.dreams/session-corpus
Dream ingestion: ~/.openclaw/workspace/memory/.dreams/session-ingestion.json

Memory Search (main-a)
Provider: gemini (requested: auto)
Model: gemini-embedding-001
Sources: memory
Indexed: 0/0 files · 0 chunks
Dirty: yes
Store: ~/.openclaw/memory/main-a.sqlite
Workspace: ~/.openclaw/workspace/main-a
Dreaming: 0 3 * * * (America/Chicago) · limit=10 · minScore=0.8 · minRecallCount=3 · minUniqueQueries=3 · recencyHalfLifeDays=14 · maxAgeDays=30
Embeddings: ready
By source:
memory · 0/0 files · 0 chunks
Vector: ready
Vector path: ~/.npm-global/lib/node_modules/openclaw/node_modules/sqlite-vec-linux-arm64/vec0.so
FTS: ready
Embedding cache: enabled (0 entries)
Batch: disabled (failures 0/2)
Recall store: 0 entries · 0 promoted · 0 concept-tagged · 0 spaced
Recall path: ~/.openclaw/workspace/main-a/memory/.dreams/short-term-recall.json
Dreaming artifacts: diary absent · 0 corpus files · ingestion state absent
Dream corpus: ~/.openclaw/workspace/main-a/memory/.dreams/session-corpus
Dream ingestion: ~/.openclaw/workspace/main-a/memory/.dreams/session-ingestion.json
Issues:
no memory files found in ~/.openclaw/workspace/main-a

Memory Search (heartbeat)
Provider: gemini (requested: auto)
Model: gemini-embedding-001
Sources: memory
Indexed: 0/1 files · 0 chunks
Dirty: yes
Store: ~/.openclaw/memory/heartbeat.sqlite
Workspace: ~/.openclaw/workspace-heartbeat
Dreaming: 0 3 * * * (America/Chicago) · limit=10 · minScore=0.8 · minRecallCount=3 · minUniqueQueries=3 · recencyHalfLifeDays=14 · maxAgeDays=30
Embeddings: ready
By source:
memory · 0/1 files · 0 chunks
Vector: ready
Vector path: ~/.npm-global/lib/node_modules/openclaw/node_modules/sqlite-vec-linux-arm64/vec0.so
FTS: ready
Embedding cache: enabled (0 entries)
Batch: disabled (failures 0/2)
Recall store: 0 entries · 0 promoted · 0 concept-tagged · 0 spaced
Recall path: ~/.openclaw/workspace-heartbeat/memory/.dreams/short-term-recall.json
Dreaming artifacts: diary absent · 0 corpus files · ingestion state absent
Dream corpus: ~/.openclaw/workspace-heartbeat/memory/.dreams/session-corpus
Dream ingestion: ~/.openclaw/workspace-heartbeat/memory/.dreams/session-ingestion.json

solemn lindenBOT Apr 21, 2026, 1:32 PM

#

chrome prairieBOT Apr 21, 2026, 1:32 PM

#

To help others find answers, you can mark your question as solved via Right click solution message -> Apps -> ✅ Mark Solution

solemn lindenBOT Apr 21, 2026, 1:32 PM

#

brave ridgeBOT Apr 21, 2026, 1:38 PM

#

Let me verify the docs/source first, because your status output is a little sneaky here.

#

Your config block is correct, and the memory status --deep output you pasted actually shows dreaming enabled for main.

The key line is:

Dreaming: 0 3 * * * (America/Chicago) ...

That means it is configured/scheduled. The scary part here is that:

Dreaming artifacts: diary absent · 0 corpus files · ingestion state absent

does not mean “disabled”, it just means no dream diary / session-corpus artifacts have been written yet.

So the mismatch is probably one of these:

#

Gateway/runtime config skew
You edited openclaw.json, but the running bot has not reloaded it, or is using a different config path.
Cron scheduler / managed dreaming job is not actually running
Dreaming is enabled in config, but the nightly managed job is missing or cron is disabled.
Nothing has met the promotion thresholds yet
This would explain “enabled but no diary/promotions”, though it would not usually explain the bot explicitly saying “disabled”.

What I’d check next, in this order:

openclaw gateway restart
openclaw gateway status
openclaw cron status
openclaw cron list

#

What to look for:

If gateway status shows a different config path than the file you edited, that’s the bug.
If cron status says scheduler disabled, that’s the bug.
In cron list, you should see the managed dreaming job, named Memory Dreaming Promotion.

Also, your main-a / heartbeat empty workspace sections are mostly noise here. They do not explain why main is not dreaming.

If you want, paste these next:

openclaw gateway status
openclaw cron status
openclaw cron list

and I’ll help narrow it down fast.

#

Docs:

flint spire Apr 21, 2026, 1:44 PM

#

(ssc-3.12.5) akessel56@rpi5:~ $ openclaw gateway status

🦞 OpenClaw 2026.4.15 (041266a) — Type the command with confidence—nature will provide the stack trace if needed.

│
◇
Service: systemd (enabled)
File logs: /tmp/openclaw/openclaw-2026-04-21.log
Command: /usr/bin/node /home/akessel56/.npm-global/lib/node_modules/openclaw/dist/index.js gateway --port 18789
Service file: ~/.config/systemd/user/openclaw-gateway.service
Service env: OPENCLAW_GATEWAY_PORT=18789

Config (cli): ~/.openclaw/openclaw.json
Config (service): ~/.openclaw/openclaw.json

Gateway: bind=loopback (127.0.0.1), port=18789 (service args)
Probe target: ws://127.0.0.1:18789
Dashboard: http://127.0.0.1:18789/
Probe note: Loopback-only gateway; only local clients can connect.

Runtime: running (pid 1915891, state active, sub running, last exit 0, reason 0)
RPC probe: ok

Listening: 127.0.0.1:18789

(ssc-3.12.5) akessel56@rpi5:~ $ openclaw cron status

🦞 OpenClaw 2026.4.15 (041266a) — Your .env is showing; don't worry, I'll pretend I didn't see it.

│
◇
{
"enabled": true,
"storePath": "/home/akessel56/.openclaw/cron/jobs.json",
"jobs": 7,
"nextWakeAtMs": 1776832200000
}
(ssc-3.12.5) akessel56@rpi5:~ $ openclaw cron list

🦞 OpenClaw 2026.4.15 (041266a) — The lobster in your shell. 🦞

│
◇
ID Name Schedule Next Last Status Target Agent ID Model
5bcc8df0-d05e-4de6-8a2c-b0ffbc7eaccf Evening Work Summary ... cron 30 23 * * * @ America/Ch... in 15h 9h ago ok session:agent:main:discord:channel:1480773291491721217 main -
062f3bf9-ae4d-480b-b8d1-2bd4c0e5620f Daily Midnight Sessio... cron 0 0 * * * @ America/Chic... in 15h 9h ago ok isolated main flash
2bc923dc-793b-4bbc-b6af-0371dc44d56d Memory Dreaming Promo... cron 0 3 * * * @ America/Chic... in 18h 6h ago skipped main - -
6ed252ce-7070-410d-9e61-fda4a4dd4022 Daily OpenClaw Config... cron 30 3 * * * @ America/Chi... in 19h 5h ago ok isolated main flash
1ecc38f4-b3b6-4e4f-bd04-e61bdc37c361 Morning News & Email ... cron 45 6 * * * @ America/Chi... in 22h 2h ago ok isolated main flash
c7f3fb10-49ec-4648-b519-a55d1f7f4f29 r/openclaw Reddit Bri... cron 0 7 * * * @ America/Chic... in 22h 2h ago ok isolated main flash

brave ridgeBOT Apr 21, 2026, 1:46 PM

#

Nice, this narrows it down a lot. The config path and managed job both look right. The interesting bit now is simply that the dreaming job last ran as skipped.

#

Yep, this is much clearer now.

Your dreaming setup is not disabled. The managed job exists, cron is enabled, and the service is reading the right config.

The real clue is this row:

Memory Dreaming Promotion ... last status: skipped

And the important implementation detail is: that managed dreaming job targets main, so it runs through the heartbeat lane. In current code, a main-session cron can be skipped if heartbeat is:

outside heartbeat.activeHours → quiet-hours
disabled → disabled

Since your dreaming sweep is scheduled for 3 AM, my first suspicion is heartbeat active-hours.

#

Please run:

openclaw cron runs --id 2bc923dc-793b-4bbc-b6af-0371dc44d56d --limit 20

That should show the actual skip reason.

Most likely outcomes:

quiet-hours
Your heartbeat window excludes 3 AM.
Fix: either widen/remove agents.defaults.heartbeat.activeHours, or move dreaming to an in-window time, for example:
```
dreaming: {
  enabled: true,
```

#

    frequency: "0 9 * * *"
  }

disabled
Heartbeat is disabled for main (heartbeat.every: "0m" or equivalent), so the main-session dreaming cron never gets a turn.

So, short version: this now looks less like “dreaming broken” and more like “dreaming scheduled onto a heartbeat lane that is skipping.”

If you paste the cron runs output, I can tell you the exact fix.

Docs:

flint spire Apr 21, 2026, 1:49 PM

#

well here is the openclaw cron runs:

{
"entries": [
{
"ts": 1776758400038,
"jobId": "2bc923dc-793b-4bbc-b6af-0371dc44d56d",
"action": "finished",
"status": "skipped",
"error": "disabled",
"summary": "openclaw_memory_core_short_term_promotion_dream",
"runAtMs": 1776758400018,
"durationMs": 6,
"nextRunAtMs": 1776844800000,
"deliveryStatus": "not-requested"
},
{
"ts": 1776672045324,
"jobId": "2bc923dc-793b-4bbc-b6af-0371dc44d56d",
"action": "finished",
"status": "skipped",
"error": "disabled",
"summary": "openclaw_memory_core_short_term_promotion_dream",
"runAtMs": 1776672045299,
"durationMs": 3,
"nextRunAtMs": 1776758400000,
"deliveryStatus": "not-requested"
}
],
"total": 2,
"offset": 0,
"limit": 20,
"hasMore": false,
"nextOffset": null
}

brave ridgeBOT Apr 21, 2026, 1:50 PM

#

Aha, there it is. error: "disabled" is the smoking gun. That means the dreaming cron is firing, but when it hands off to the main heartbeat lane, heartbeat immediately says “I’m disabled”, so the dream sweep never actually runs.

#

Yep, that confirms it.

error: "disabled" here means the dreaming cron is waking up, but the main heartbeat lane is disabled, so the actual dream sweep never starts.

Two common causes in current behavior:

agents.defaults.heartbeat.every is 0m / blank
You have per-agent heartbeat blocks under agents.list, but not for main
If any agent has a heartbeat block, then only those agents get heartbeats.

That second one is especially sneaky, and your extra workspaces (main-a, heartbeat) make me suspicious you may have hit exactly that.

What to check in ~/.openclaw/openclaw.json:

agents: {

#

  defaults: {
    heartbeat: {
      every: "30m"   // must be > 0
    }
  }
}

or, if you use per-agent heartbeat config:

agents: {
  list: [
    {
      id: "main",

#

      heartbeat: {
        every: "30m"
      }
    }
  ]
}

Important gotcha:

if you already have something like:
```
agents.list[].heartbeat
```
on some other agent, but not on main, then main is treated as heartbeat-disabled.

After fixing it:

#

openclaw gateway restart
openclaw cron run 2bc923dc-793b-4bbc-b6af-0371dc44d56d
openclaw cron runs --id 2bc923dc-793b-4bbc-b6af-0371dc44d56d --limit 20

If you want, paste your agents section and I’ll tell you exactly which line is disabling main.

flint spire Apr 21, 2026, 1:54 PM

#

"agents": {
"defaults": {
"model": {
"primary": "zai/glm-5.1",
"fallbacks": [
"google/gemini-3-flash-preview",
"zai/glm-5-turbo",
"google/gemini-3.1-flash-lite-preview"
]
},
"models": {
"google/gemini-3.1-flash-lite-preview": {
"alias": "31lite"
},
"google/gemini-3-flash-preview": {
"alias": "flash"
},
"google/gemini-3.1-pro-preview": {
"alias": "pro"
},
"zai/glm-5-turbo": {
"alias": "turbo"
},
"zai/glm-5.1": {
"alias": "glm"
}
},
"workspace": "/home/akessel56/.openclaw/workspace",
"userTimezone": "America/Chicago",
"envelopeTimezone": "user",
"envelopeTimestamp": "on",
"compaction": {
"mode": "safeguard"
},
"timeoutSeconds": 600
},
"list": [
{
"id": "main",
"default": true
},
{
"id": "main-a",
"default": false
},
{
"id": "heartbeat",
"skills": [],
"workspace": "~/.openclaw/workspace-heartbeat",
"tools": {
"allow": [
"read",
"write",
"exec"
]
},
"heartbeat": {
"every": "60m",
"model": "google/gemini-3.1-flash-lite-preview",
"isolatedSession": true,
"lightContext": true,
"target": "discord",
"to": "channel:1482214704784080906",
"directPolicy": "block"
}
}
]
},

brave ridgeBOT Apr 21, 2026, 1:55 PM

#

Yep, that’s it.

The problem is not the agent id being named heartbeat.
The problem is this block:

{
  "id": "heartbeat",
  ...
  "heartbeat": { ... }
}

In current behavior, if any agent in agents.list has a heartbeat block, then only those agents get heartbeats.

So right now:

#

heartbeat agent: heartbeats enabled
main: heartbeats disabled
dreaming cron targets main
result: Memory Dreaming Promotion runs, hands off to main, gets disabled, skips

So your exact fix is to add a heartbeat block to main too.

For example:

{
  "id": "main",
  "default": true,
  "heartbeat": {
    "every": "60m",
    "target": "none"

#

}
}

You can keep your existing heartbeat agent block if you want.
You just need main to have heartbeat enabled as well, because dreaming is running on main.

Then:

openclaw gateway restart
openclaw cron run 2bc923dc-793b-4bbc-b6af-0371dc44d56d
openclaw cron runs --id 2bc923dc-793b-4bbc-b6af-0371dc44d56d --limit 20

If you want, I can help you sanity-check the final agents.list snippet before you restart.

flint spire Apr 21, 2026, 1:59 PM

#

Does that mean I will have to heartbeats running? If I have this or does it matter?:
"list": [
{
"id": "main",
"default": true,
"heartbeat": {
"every": "60m",
"target": "none"
}
},
{
"id": "main-a",
"default": false
},
{
"id": "heartbeat",
"skills": [],
"workspace": "~/.openclaw/workspace-heartbeat",
"tools": {
"allow": [
"read",
"write",
"exec"
]
},
"heartbeat": {
"every": "60m",
"model": "google/gemini-3.1-flash-lite-preview",
"isolatedSession": true,
"lightContext": true,
"target": "discord",
"to": "channel:1482214704784080906",
"directPolicy": "block"
}
}
]

brave ridgeBOT Apr 21, 2026, 2:00 PM

#

Yes, with that config main will have heartbeats enabled.

But:

target: "none" means no chat messages
it still means the main agent runs on that schedule
so there is still some token/work cost

Your snippet should make dreaming work, because main is no longer heartbeat-disabled.

A better version, if you only want this to unblock dreaming, is to make main low frequency and silent, for example:

{
  "id": "main",
  "default": true,

#

  "heartbeat": {
    "every": "24h",
    "target": "none"
  }
}

Then keep your separate heartbeat agent exactly as-is for the real hourly Discord heartbeat.

So:

main heartbeat: enabled, silent, low-frequency, just to keep dreaming from being blocked
heartbeat agent: your actual visible hourly heartbeat to Discord

Short answer: yes, it matters, but it does not have to be noisy.
The important part is that main has a heartbeat config with a non-zero every.

#

After changing it:

openclaw gateway restart
openclaw cron run 2bc923dc-793b-4bbc-b6af-0371dc44d56d
openclaw cron runs --id 2bc923dc-793b-4bbc-b6af-0371dc44d56d --limit 20

And honestly, if you want dreaming without needing main heartbeat enabled at all, that feels like a fair bug/UX issue to file: https://github.com/openclaw/openclaw/issues

flint spire Apr 21, 2026, 2:03 PM

#

What if I remove .openclaw/workspace/HEARTBEAT.md? Right now its a duplicate of what is in /worksapce-heartbeat/HEARTBEAT.md. It would be duplicating activity, or just have the .openclaw/workspace/HEARTBEAT.md empty? that heartbeat does too much work to duplicate.

brave ridgeBOT Apr 21, 2026, 2:05 PM

#

Let me check the heartbeat docs/behavior here, because the empty-file case is a little weird.

#

Ah, yep, in your case I’d do empty/header-only ~/.openclaw/workspace/HEARTBEAT.md, not a duplicate.

Why:

Missing HEARTBEAT.md means normal main heartbeats can still run with the default heartbeat prompt.
Empty/header-only HEARTBEAT.md makes normal main heartbeats skip as empty-heartbeat-file, which is exactly what you want if you’re trying to avoid duplicate work.
Dreaming cron wakes should still run, because cron-triggered heartbeat wakes bypass the normal HEARTBEAT.md file gate.

So the clean setup is:

main agent: heartbeat enabled, silent, low-frequency
~/.openclaw/workspace/HEARTBEAT.md: empty or just a header
heartbeat agent: keep the real heavy HEARTBEAT.md in ~/.openclaw/workspace-heartbeat/

Example main file could literally be:

#

# HEARTBEAT.md

That’s one of the rare cases where an “empty” heartbeat file is actually useful 🙂

Then test with:

openclaw gateway restart
openclaw cron run 2bc923dc-793b-4bbc-b6af-0371dc44d56d
openclaw cron runs --id 2bc923dc-793b-4bbc-b6af-0371dc44d56d --limit 20

If that flips from disabled/skipped to ok, you’ve got it.

Glad we found the weird part here. If this fixed it, please right-click the solution message → Apps → ✅ Mark Solution so Answer Overflow can index it.

flint spire Apr 21, 2026, 2:14 PM

#

How long do I need to wait before running the openclaw cron runs command. I ran it a few minutes later after making all those changes and restarting and the output is still the same:
{
"entries": [
{
"ts": 1776758400038,
"jobId": "2bc923dc-793b-4bbc-b6af-0371dc44d56d",
"action": "finished",
"status": "skipped",
"error": "disabled",
"summary": "openclaw_memory_core_short_term_promotion_dream",
"runAtMs": 1776758400018,
"durationMs": 6,
"nextRunAtMs": 1776844800000,
"deliveryStatus": "not-requested"
},
{
"ts": 1776672045324,
"jobId": "2bc923dc-793b-4bbc-b6af-0371dc44d56d",
"action": "finished",
"status": "skipped",
"error": "disabled",
"summary": "openclaw_memory_core_short_term_promotion_dream",
"runAtMs": 1776672045299,
"durationMs": 3,
"nextRunAtMs": 1776758400000,
"deliveryStatus": "not-requested"
}
],
"total": 2,
"offset": 0,
"limit": 20,
"hasMore": false,
"nextOffset": null

brave ridgeBOT Apr 21, 2026, 2:15 PM

#

You shouldn’t need to wait minutes.

Two cases:

If you did not run openclaw cron run ...
- then cron runs will stay unchanged until the next scheduled run at 3 AM
If you did run openclaw cron run 2bc923dc-793b-4bbc-b6af-0371dc44d56d
- you should usually see a new entry within a few seconds
- definitely not “wait a few minutes”

So if cron runs still shows only those same 2 old entries, that means either:

the manual run was never enqueued, or
it failed before creating a new run record

Please run these back-to-back and paste both outputs:

#

openclaw cron run 2bc923dc-793b-4bbc-b6af-0371dc44d56d
openclaw cron runs --id 2bc923dc-793b-4bbc-b6af-0371dc44d56d --limit 20

What I expect from the first command is something like:

{ "ok": true, "enqueued": true, "runId": "..." }

If you do get a new run entry and it still says disabled, then the config change still isn’t being seen the way we think, and we’ll inspect that next.

flint spire Apr 21, 2026, 2:16 PM

#

that's exactly what I did before:
(ssc-3.12.5) akessel56@rpi5:~ $ openclaw cron run 2bc923dc-793b-4bbc-b6af-0371dc44d56d

🦞 OpenClaw 2026.4.15 (041266a) — I run on caffeine, JSON5, and the audacity of "it worked on my machine."

│
◇
{
"ok": true,
"enqueued": true,
"runId": "manual:2bc923dc-793b-4bbc-b6af-0371dc44d56d:1776780688117:1"
}
(ssc-3.12.5) akessel56@rpi5:~ $ openclaw cron runs --id 2bc923dc-793b-4bbc-b6af-0371dc44d56d --limit 20

🦞 OpenClaw 2026.4.15 (041266a) — One CLI to rule them all, and one more restart because you changed the port.

│
◇
{
"entries": [
{
"ts": 1776758400038,
"jobId": "2bc923dc-793b-4bbc-b6af-0371dc44d56d",
"action": "finished",
"status": "skipped",
"error": "disabled",
"summary": "openclaw_memory_core_short_term_promotion_dream",
"runAtMs": 1776758400018,
"durationMs": 6,
"nextRunAtMs": 1776844800000,
"deliveryStatus": "not-requested"
},
{
"ts": 1776672045324,
"jobId": "2bc923dc-793b-4bbc-b6af-0371dc44d56d",
"action": "finished",
"status": "skipped",
"error": "disabled",
"summary": "openclaw_memory_core_short_term_promotion_dream",
"runAtMs": 1776672045299,
"durationMs": 3,
"nextRunAtMs": 1776758400000,
"deliveryStatus": "not-requested"
}
],
"total": 2,
"offset": 0,
"limit": 20,
"hasMore": false,
"nextOffset": null
}

brave ridgeBOT Apr 21, 2026, 2:17 PM

#

That’s genuinely weird. If it’s enqueued but never shows up in cron runs, then we’re past “config typo” territory and into “the queued run never actually executed.” Let me check the cron behavior/docs so I can point you at the next sharp diagnostic.

#

Got it, thanks, that’s really helpful.

This means something more specific:

the manual run is being enqueued
but it is not actually executing
because if it executed and still failed, you’d have a third entry in cron runs

So we’ve moved past config and into cron queue / execution-path debugging.

Please do this next:

Terminal 1

openclaw logs --follow

#

Terminal 2

openclaw cron run 2bc923dc-793b-4bbc-b6af-0371dc44d56d
openclaw system heartbeat last

Then paste the new log lines around that moment.

The strings I especially want to see are:

cron: queued manual run waiting for an execution slot
cron: queued manual run background execution failed
heartbeat skipped ...
anything mentioning disabled, cron, or memory-core

So, short version: you do not need to wait, and the lack of a new run entry is itself the bug clue.

#

If you want, also paste the output of:

openclaw system heartbeat last

That may show whether the main heartbeat subsystem is still considered disabled even after the config change.

flint spire Apr 21, 2026, 2:21 PM

#

So here are the log section ater I ran the openclaw cron run you just gave me:
14:19:52+00:00 warn plugins {"subsystem":"plugins"} memory-core: managed dreaming cron could not be reconciled (cron service unavailable).
14:19:52+00:00 warn plugins {"subsystem":"plugins"} memory-core: narrative generation used fallback for light phase because subagent runtime is request-scoped.
14:19:52+00:00 warn plugins {"subsystem":"plugins"} memory-core: narrative session cleanup failed for light phase: Plugin runtime subagent methods are only available during a gateway request.
14:19:53+00:00 warn plugins {"subsystem":"plugins"} memory-core: narrative generation used fallback for rem phase because subagent runtime is request-scoped.
14:19:53+00:00 warn plugins {"subsystem":"plugins"} memory-core: narrative session cleanup failed for rem phase: Plugin runtime subagent methods are only available during a gateway request.
14:19:53+00:00 warn plugins {"subsystem":"plugins"} memory-core: narrative generation used fallback for light phase because subagent runtime is request-scoped.
14:19:53+00:00 warn plugins {"subsystem":"plugins"} memory-core: narrative session cleanup failed for light phase: Plugin runtime subagent methods are only available during a gateway request.
14:19:53+00:00 warn plugins {"subsystem":"plugins"} memory-core: narrative generation used fallback for rem phase because subagent runtime is request-scoped.
14:19:53+00:00 warn plugins {"subsystem":"plugins"} memory-core: narrative session cleanup failed for rem phase: Plugin runtime subagent methods are only available during a gateway request.
14:19:53+00:00 info plugins {"subsystem":"plugins"} memory-core: dreaming promotion complete (workspaces=3, candidates=0, applied=0, failed=0).

#

(ssc-3.12.5) akessel56@rpi5:~ $ openclaw system heartbeat last

🦞 OpenClaw 2026.4.15 (041266a)
If it's repetitive, I'll automate it; if it's hard, I'll bring jokes and a rollback plan.

│
◇
{
"ts": 1776781193629,
"status": "skipped",
"reason": "no-target",
"preview": "NO_REPLY",
"durationMs": 1395,
"hasMedia": false

brave ridgeBOT Apr 21, 2026, 2:22 PM

#

This is actually good news.

The key line is:

memory-core: dreaming promotion complete (workspaces=3, candidates=0, applied=0, failed=0)

That means dreaming did run. So the original “it’s disabled” problem looks fixed.

What the logs say now:

Core dreaming sweep ran
It scanned 3 workspaces
It found 0 candidates
So it promoted 0 items

#

So at this point the problem is no longer “dreaming is off”, it’s more like:

dreaming is running
nothing currently meets promotion thresholds
the manual-run path is producing some noisy warnings

About the warnings:

managed dreaming cron could not be reconciled (cron service unavailable)
looks like a manual-run / cron bookkeeping bug, especially since cron is obviously there
narrative generation used fallback... request-scoped / cleanup failed
looks like the optional narrative/diary path being noisy, not the core promotion path failing
cron runs not showing the manual run even though it executed
also smells like a bug

#

So I’d say:

Dreaming itself is working now
The manual cron history / narrative warnings look buggy

If you want to check whether anything is eligible right now, run:

openclaw memory promote

That should confirm the “0 candidates” story from the logs.

And honestly, with the evidence you have now, I’d file a GitHub issue for this combo:

dreaming cron initially blocked by main heartbeat-disabled behavior
manual cron run executes, but cron runs does not record it

#

cron service unavailable warning during manual dreaming run
request-scoped narrative fallback / cleanup warnings

Issue link: https://github.com/openclaw/openclaw/issues

If you want, I can help you turn the evidence you already collected into a tight bug report.

#

Yep, that output is actually exactly what we wanted to see for main.

"status": "skipped",
"reason": "no-target",
"preview": "NO_REPLY"

That means:

the main heartbeat is now enabled and running
it did not send anything, because target: "none"
so the old disabled problem is gone

Combined with your earlier log:

#

memory-core: dreaming promotion complete (workspaces=3, candidates=0, applied=0, failed=0)

I’d call the original issue fixed:

dreaming is no longer disabled
main heartbeat is active
the dreaming sweep ran
it just found 0 candidates to promote

So the current state is:

Working: heartbeat/main lane
Working: dreaming execution
Not much to do yet: candidates=0
Probably buggy/noisy: manual cron runs history and the narrative fallback warnings

#

If you want the practical takeaway, it’s this:

your config change worked
no-target is fine
now you mostly just need to let the next normal dreaming runs happen and see whether enough recall builds up to produce candidates

If you want, the next useful check is tomorrow after the scheduled run:

openclaw memory status --deep

and/or watch for another:

memory-core: dreaming promotion complete ...

#

in logs.

If you decide to open a bug, you’ve got solid evidence now.

flint spire Apr 21, 2026, 2:24 PM

#

Would you mind pulling together the bug report for me?

brave ridgeBOT Apr 21, 2026, 2:26 PM

#

Yep, I can draft it. I can’t file it for you, but here’s a paste-ready issue for https://github.com/openclaw/openclaw/issues/new.

## Summary

`memory-core` dreaming appears enabled and the managed cron job exists, but the dreaming cron silently depends on the **default `main` heartbeat lane** being enabled.

If any `agents.list[]` entry has a `heartbeat` block, only those agents get heartbeats. In my case I had a dedicated `heartbeat` agent with a heartbeat config, but no heartbeat block on `main`. That caused the managed dreaming cron (which targets `main`) to skip with `error: "disabled"` even though dreaming looked enabled in status output.

There are also some confusing/manual-run diagnostics around this:
- `openclaw cron run <dreaming-job-id>` returns `{ ok: true, enqueued: true }`
- logs show the dreaming sweep actually runs
- but `openclaw cron runs --id ...` does not record the manual run
- manual run logs also show `managed dreaming cron could not be reconciled (cron service unavailable)`

## Version

#


- OpenClaw: `2026.4.15`
- Commit: `041266a`

## Platform

- Raspberry Pi 5 / Linux ARM64

## Relevant config

Dreaming enabled:

```json5
plugins: {
  entries: {
    "memory-core": {

#

enabled: true,
config: {
dreaming: {
enabled: true,
},
},
},
},
}


Agents config before fix:

```json5
agents: {
  defaults: {
    workspace: "/home/akessel56/.openclaw/workspace",

#

userTimezone: "America/Chicago",
},
list: [
{
id: "main",
default: true,
},
{
id: "main-a",
default: false,
},
{
id: "heartbeat",
workspace: "~/.openclaw/workspace-heartbeat",
tools: {
allow: ["read", "write", "exec"],
},

#

heartbeat: {
every: "60m",
model: "google/gemini-3.1-flash-lite-preview",
isolatedSession: true,
lightContext: true,
target: "discord",
to: "channel:1482214704784080906",
directPolicy: "block",
},
},
],
}


## Reproduction

#

1. Enable dreaming under `plugins.entries.memory-core.config.dreaming.enabled`.
2. Configure a dedicated non-main agent with a `heartbeat` block.
3. Leave `main` without a `heartbeat` block.
4. Restart gateway.
5. Check dreaming / cron state:
   - `openclaw memory status --deep`
   - `openclaw cron status`
   - `openclaw cron list`
   - `openclaw cron runs --id <dreaming-job-id> --limit 20`

## Actual behavior

`openclaw memory status --deep` shows dreaming configured:

```txt
Dreaming: 0 3 * * * (America/Chicago) · limit=10 · minScore=0.8 · minRecallCount=3 · minUniqueQueries=3 · recencyHalfLifeDays=14 · maxAgeDays=30

#


`openclaw cron list` shows the managed dreaming cron exists:

```txt
Memory Dreaming Promotion ... cron 0 3 * * * @ America/Chicago ... status skipped

openclaw cron runs --id <dreaming-job-id> --limit 20 shows:

{
  "entries": [
    {
      "status": "skipped",
      "error": "disabled",
      "summary": "__openclaw_memory_core_short_term_promotion_dream__"

#

}
]
}


So dreaming appears enabled, but the actual managed job skips because heartbeat is considered disabled for `main`.

## Expected behavior

One of these should happen:

1. Dreaming should **not depend on `main` heartbeat being enabled**, or
2. Dreaming status / doctor output should explicitly say something like:
   - `dreaming blocked: default agent heartbeat disabled`
   - `managed dreaming cron targets main, but main has no heartbeat config`
3. The behavior around per-agent heartbeats should not make dreaming silently fail when another agent has heartbeat enabled.

#


At minimum, the current status output is misleading because dreaming looks enabled/scheduled while the actual job skips with `disabled`.

## Additional observations after workaround

I added a silent heartbeat block to `main`:

```json5
{
  id: "main",
  default: true,
  heartbeat: {
    every: "24h",
    target: "none",
  },
}

#


After restart:

```bash
openclaw system heartbeat last

returned:

{
  "status": "skipped",
  "reason": "no-target",
  "preview": "NO_REPLY"
}

#


which suggests `main` heartbeat is now active.

Then running:

```bash
openclaw cron run <dreaming-job-id>

returned:

{
  "ok": true,
  "enqueued": true,
  "runId": "manual:..."

#

}


But `openclaw cron runs --id <dreaming-job-id> --limit 20` still did **not** record a new run entry.

At the same time, gateway logs showed the dreaming sweep actually ran:

```txt
memory-core: managed dreaming cron could not be reconciled (cron service unavailable).
memory-core: narrative generation used fallback for light phase because subagent runtime is request-scoped.
memory-core: narrative session cleanup failed for light phase: Plugin runtime subagent methods are only available during a gateway request.
memory-core: narrative generation used fallback for rem phase because subagent runtime is request-scoped.
memory-core: narrative session cleanup failed for rem phase: Plugin runtime subagent methods are only available during a gateway request.
memory-core: dreaming promotion complete (workspaces=3, candidates=0, applied=0, failed=0).

#

So there may be a second issue here:

- manual `cron run` executes the dreaming sweep
- but `cron runs` does not record that manual run
- and manual dreaming run logs emit confusing `cron service unavailable` / request-scoped subagent warnings

If maintainers prefer, I can split that secondary observation into a separate issue.

## Why this is confusing

From a user perspective, all of these looked true at the same time:

- dreaming enabled in config
- dreaming shown in `memory status --deep`
- managed dreaming cron job exists

#

- bot still reports dreaming as disabled
- cron runs show `disabled`
- after workaround, logs show dreaming actually runs, but cron run history still doesn’t reflect it

That made it very hard to tell whether dreaming was off, broken, or just had no candidates.

## Helpful commands / evidence already collected

```bash
openclaw gateway status
openclaw cron status
openclaw cron list
openclaw cron runs --id <dreaming-job-id> --limit 20
openclaw system heartbeat last
openclaw memory status --deep
openclaw logs --follow

#

If you want, I can also make a shorter maintainer-style version with less narrative and just the essentials.

flint spire Apr 21, 2026, 2:33 PM

#

whichever is more useful for filing the bug.

brave ridgeBOT Apr 21, 2026, 2:33 PM

#

I’d file the shorter maintainer-style version. It’s easier to triage.

Paste this:

## Summary

`memory-core` dreaming appears enabled and the managed cron job exists, but the job silently depends on the default `main` heartbeat lane being enabled.

If any `agents.list[]` entry has a `heartbeat` block, only those agents get heartbeats. In my setup I had a dedicated `heartbeat` agent with a `heartbeat` block, but no `heartbeat` block on `main`. That caused the managed dreaming cron (which targets `main`) to skip with `error: "disabled"` even though dreaming looked enabled in status output.

There also seems to be a second issue during manual testing:
- `openclaw cron run <dreaming-job-id>` returns `{ ok: true, enqueued: true }`
- gateway logs show the dreaming sweep actually runs
- but `openclaw cron runs --id ...` does not record the manual run

#

## Version

- OpenClaw `2026.4.15`
- commit `041266a`

## Platform

- Raspberry Pi 5 / Linux ARM64

## Reproduction

1. Enable dreaming:

```json5
plugins: {
  entries: {

#

"memory-core": {
enabled: true,
config: {
dreaming: {
enabled: true,
},
},
},
},
}


2. Configure agents like this:

```json5
agents: {
  defaults: {

#

workspace: "/home/akessel56/.openclaw/workspace",
userTimezone: "America/Chicago",
},
list: [
{
id: "main",
default: true,
},
{
id: "main-a",
default: false,
},
{
id: "heartbeat",
workspace: "~/.openclaw/workspace-heartbeat",
tools: {
allow: ["read", "write", "exec"],

#

},
heartbeat: {
every: "60m",
model: "google/gemini-3.1-flash-lite-preview",
isolatedSession: true,
lightContext: true,
target: "discord",
to: "channel:1482214704784080906",
directPolicy: "block",
},
},
],
}


3. Restart gateway.

#

4. Check status:

```bash
openclaw memory status --deep
openclaw cron list
openclaw cron runs --id <dreaming-job-id> --limit 20

Actual behavior

openclaw memory status --deep shows dreaming configured:

Dreaming: 0 3 * * * (America/Chicago) · limit=10 · minScore=0.8 · minRecallCount=3 · minUniqueQueries=3 · recencyHalfLifeDays=14 · maxAgeDays=30

#


`openclaw cron list` shows the managed job exists:

```txt
Memory Dreaming Promotion ... cron 0 3 * * * @ America/Chicago ...

But openclaw cron runs --id <dreaming-job-id> --limit 20 shows scheduled runs skipped:

{
  "entries": [
    {
      "status": "skipped",
      "error": "disabled",
      "summary": "__openclaw_memory_core_short_term_promotion_dream__"

#

}
]
}


So dreaming looks enabled, but the actual managed job skips because `main` heartbeat is considered disabled.

## Expected behavior

One of these should happen:

1. Dreaming should not depend on `main` heartbeat being enabled, or
2. Dreaming status should explicitly report that it is blocked because `main` heartbeat is disabled, or
3. Per-agent heartbeat configuration should not make dreaming silently fail when another agent has heartbeat enabled.

At minimum, the current status output is misleading because dreaming appears enabled/scheduled while the actual job skips with `disabled`.

#


## Workaround

Adding a silent heartbeat block to `main` unblocked the heartbeat lane:

```json5
{
  id: "main",
  default: true,
  heartbeat: {
    every: "24h",
    target: "none",
  },
}

#


After restart:

```bash
openclaw system heartbeat last

returned:

{
  "status": "skipped",
  "reason": "no-target",
  "preview": "NO_REPLY"
}

#


which suggests `main` heartbeat is now active.

## Additional observation: manual run history mismatch

After the workaround, running:

```bash
openclaw cron run <dreaming-job-id>

returned:

{
  "ok": true,

#

"enqueued": true,
"runId": "manual:..."
}


but:

```bash
openclaw cron runs --id <dreaming-job-id> --limit 20

did not record a new run entry.

At the same time, gateway logs showed the dreaming sweep actually ran:

memory-core: managed dreaming cron could not be reconciled (cron service unavailable).

#

memory-core: narrative generation used fallback for light phase because subagent runtime is request-scoped.
memory-core: narrative session cleanup failed for light phase: Plugin runtime subagent methods are only available during a gateway request.
memory-core: narrative generation used fallback for rem phase because subagent runtime is request-scoped.
memory-core: narrative session cleanup failed for rem phase: Plugin runtime subagent methods are only available during a gateway request.
memory-core: dreaming promotion complete (workspaces=3, candidates=0, applied=0, failed=0).


So there may be a second bug where manual dreaming cron runs execute but do not show up in `cron runs`.

## Evidence / commands used

```bash
openclaw gateway status
openclaw cron status
openclaw cron list
openclaw cron runs --id <dreaming-job-id> --limit 20
openclaw cron run <dreaming-job-id>

#Dreaming issue

Actual behavior