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 <dreaming-job-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 <dreaming-job-id> returned: json { "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:

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.