Dreaming: cron reconcile + operator.admin scope errors (v2026.4.14)

[woeful pollen]

Hi — running OpenClaw v2026.4.14, Dreaming enabled 2026-04-13 (then on v2026.4.12). First 03:00 run completed
across 8 workspaces, but memory-core reports two issues:

1. managed dreaming cron could not be reconciled (cron service unavailable) — repeats every ~30 min, survives a
   gateway restart.
2. At 03:00: narrative session cleanup failed for rem phase: missing scope: operator.admin on every workspace.

Secondary: Deep phase is enabled in config, but only REM actually fired — plugin created a single managed dreaming
cron job, not one per phase.

Other cron jobs fire fine ([cron] entries in the log), so the subsystem is live — "unavailable" reads like a scope
issue. A CLI scope-upgrade to operator.admin was attempted but closed with pairing required.

How do I grant memory-core's internal token operator.admin for Dreaming? Feels like the scope auto-grant got missed
when Dreaming shipped.

Thanks!

[zealous zenith]

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

[mystic meadow]

I checked the current docs/code, and this looks like a bug, not a scope you can grant.

• One cron job is expected. Dreaming is designed as one managed cron for a full sweep, not one job per phase. It runs light -> REM -> deep in one pass. Docs: https://docs.openclaw.ai/concepts/dreaming and https://docs.openclaw.ai/reference/memory-config#dreaming-experimental
• There is no separate “memory-core internal token” you can widen via devices. The plugin runtime uses the current request scope, or falls back to an internal synthetic operator client that defaults to operator.write, not operator.admin.
• sessions.delete needs operator.admin. The dream diary cleanup path calls session deletion, so the missing scope: operator.admin on REM cleanup is a real regression in Dreaming's cleanup path.
• The “cron service unavailable” warning is probably unrelated to auth. That warning is emitted when the startup hook does not receive a cron service object at all, not when cron is denied by scope. So your “other cron jobs fire fine” observation actually fits.

So the short answer is:

You cannot fix this by granting memory-core operator.admin from the CLI.
Your CLI scope-upgrade only affects your paired device, not the plugin’s internal backend calls.

If you want to finish the CLI scope-upgrade anyway, the flow is still:

openclaw devices list

openclaw devices approve <requestId>

Docs: https://docs.openclaw.ai/cli/devices

But again, that should not fix Dreaming.

What I’d do next:

1. Treat this as an upstream bug/regression.
2. File it here with the two symptoms together: https://github.com/openclaw/openclaw/issues
3. Include:
   • version v2026.4.14
   • the recurring managed dreaming cron could not be reconciled (cron service unavailable)
   • the REM cleanup missing scope: operator.admin
   • note that a single managed cron exists, which is actually expected
   • whether you see memory-core: dreaming promotion complete or a ## Deep Sleep section / memory/dreaming/deep/YYYY-MM-DD.md

My read is:

• single cron = expected
• REM cleanup admin failure = bug
• cron unavailable warning = separate startup/reconciliation bug or misleading log

If you want, I can help you turn your report into a tight GitHub issue body.

[woeful pollen]

Thanks for the clarification — really helpful. Filed upstream: https://github.com/openclaw/openclaw/issues/66801

Included both symptoms with logs, the single-managed-cron-is-expected note so maintainers don't have to re-explain it,
and the observation that DREAMS.md prose is being written fine (so the reflection path works — just cleanup + cron
reconciliation are broken).