Bug type

Behavior bug (incorrect output/state without crash)

Beta release blocker

No

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

Steps to reproduce

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 --limit 20

Expected behavior

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.

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 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:
json
{
"entries": [
{
"status": "skipped",
"error": "disabled",
"summary": "openclaw_memory_core_short_term_promotion_dream"
}
]
}

OpenClaw version

Version - OpenClaw 2026.4.15 - commit 041266a

Operating system

• Raspberry Pi 5 / Linux ARM64 Debian 12 - Bookworm

Install method

npm global

Model

gemini-3.1-flash-lite-preview

Provider / routing chain

openclaw > google

Additional provider/model setup details

No response

Logs, screenshots, and evidence

## Evidence / commands used
openclaw gateway status
openclaw cron status
openclaw cron list
openclaw cron runs --id <dreaming-job-id> --limit 20
openclaw cron run <dreaming-job-id>
openclaw system heartbeat last
openclaw memory status --deep
openclaw logs --follow

Impact and severity

Affected systems: Dreaming
Severity: Blocks workflow
Consequence dreaming cron fails.

Additional information

Workaround

Adding a silent heartbeat block to main unblocked the heartbeat lane:
json5
{
id: "main",
default: true,
heartbeat: {
every: "60m",
target: "none",
},
}
After restart:
returned:
json
{
"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
returned:
json
{
"ok": true,
"enqueued": true,
"runId": "manual:..."
}
But:
bash
openclaw cron runs --id --limit 20
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 bug where manual dreaming cron runs execute but do not show up in cron runs.