Issue Station
Sign In
Tools hereToolbox

openclaw - ✅(Solved) Fix [Feature]: memory-core: expose lightContext for plugin-managed dreaming jobs [1 pull requests, 1 participants]

Official PRs (…)
ON THIS PAGE

Recommended Tools

×6

Utilities matched from this issue’s tags and category — try them while you read without losing context.

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

Helpful · Quick feedback

Loading…
GitHub stats
openclaw/openclaw#70086•Fetched 2026-04-23 07:29:28
View on GitHub
Comments
0
Participants
1
Timeline
1
Reactions
0
Author
Multiply3xMultiply3x
Participants
Multiply3xMultiply3x
Timeline (top)
labeled ×1

Allow the memory-core plugin to scope dreaming context loading via a lightContext config option, so plugin-managed dreaming work can run with a lean bootstrap without affecting global heartbeat behaviour.

Root Cause

Allow the memory-core plugin to scope dreaming context loading via a lightContext config option, so plugin-managed dreaming work can run with a lean bootstrap without affecting global heartbeat behaviour.

Fix Action

Fix / Workaround

  1. Modify the workspace bootstrap to be lean by default. Would affect all agent turns including interactive sessions, which need full bootstrap. Not a viable workaround for this specific gap.

PR fix notes

PR #70737: memory/dreaming: decouple managed cron from heartbeat

Description (problem / solution / changelog)

Summary

Cherry-picks 13 commits from @jalehman's josh/dreaming-isolated-cron-fix branch to move the managed dreaming cron off the heartbeat path and onto isolated agent turns (sessionTarget: "isolated" + payload.kind: "agentTurn" + lightContext: true), so dreaming runs even when heartbeat is disabled for the default agent. Also reverts #69875 (blocked-reason observability becomes dead code once decoupling lands) and adds a doctor migration for stale main-session dreaming jobs in persisted cron configs.

Issues addressed

  • Fixes #69811 — dreaming silently skips when the default agent has no heartbeat block. Decoupling cron from heartbeat removes the precondition entirely. (This is the bug #69875 was responding to.)
  • Fixes #67397 — dreaming cron skipped by heartbeat.activeHours because the consumer ran inside heartbeat-runner. Once cron drives an isolated turn directly, activeHours no longer applies.
  • Fixes #68972 — dreaming worked under sessionTarget: isolated but not main. This PR makes isolated the default/only managed shape; the reporter's manual workaround becomes the shipped behavior.
  • Addresses #70086 — request for lightContext on plugin-managed dreaming jobs. This PR hardcodes lightContext: true on the managed cron payload and on the dream-diary subagent run (via a new SubagentRunParams.lightContext SDK seam) rather than exposing it as a memory-core config knob; the underlying cost/context-bloat concern is solved either way.

Commits picked from Josh's branch (oldest → newest)

  • openclaw-3ba.1 move managed dreaming cron to isolated agent turns
  • openclaw-46d claim cron runs before embedded attempts
  • openclaw-575 disable managed dreaming cron delivery
  • openclaw-575 accept wrapped dreaming cron tokens
  • openclaw-ccd filter cron and wrapper transcript noise from dreaming corpus
  • openclaw-cd9 filter archived, cron, and heartbeat transcript noise from dreaming corpus
  • openclaw-cd9 suppress role-label reflection tags in rem dreaming
  • openclaw-b49 stop narrative timeouts from blocking dreaming cron
  • openclaw-b49 keep managed dreaming cron out of diary subagents
  • openclaw-ff9 restore cron dream diary generation without serial waits
  • openclaw-ff9 run dreaming narratives with lightweight isolated subagent lanes
  • openclaw-ff9 detach cron dream diary generation from run completion
  • openclaw-ff9 defer cron diary task startup until after cron completion

Test plan

  • pnpm tsgo / pnpm tsgo:extensions / pnpm check:test-types
  • pnpm lint:core
  • pnpm test extensions/memory-core — 48 files, 515 passed
  • pnpm test src/commands/doctor-cron.test.ts src/commands/doctor-cron-dreaming-payload-migration.test.ts
  • Manual: run openclaw doctor --fix against a config with the legacy sessionTarget: "main" shape and confirm rewrite
  • Manual: run dreaming end-to-end with heartbeat disabled and confirm a diary entry lands

Changed files

  • CHANGELOG.md (modified, +0/-1)
  • docs/concepts/dreaming.md (modified, +0/-12)
  • extensions/memory-core/src/cli.runtime.ts (modified, +1/-8)
  • extensions/memory-core/src/cli.test.ts (modified, +0/-129)
  • extensions/memory-core/src/concept-vocabulary.test.ts (modified, +16/-0)
  • extensions/memory-core/src/concept-vocabulary.ts (modified, +5/-1)
  • extensions/memory-core/src/dreaming-command.test.ts (modified, +0/-91)
  • extensions/memory-core/src/dreaming-command.ts (modified, +1/-6)
  • extensions/memory-core/src/dreaming-narrative.test.ts (modified, +6/-6)
  • extensions/memory-core/src/dreaming-narrative.ts (modified, +8/-23)
  • extensions/memory-core/src/dreaming-phases.test.ts (modified, +394/-0)
  • extensions/memory-core/src/dreaming-phases.ts (modified, +65/-25)
  • extensions/memory-core/src/dreaming-shared.test.ts (added, +40/-0)
  • extensions/memory-core/src/dreaming-shared.ts (modified, +11/-1)
  • extensions/memory-core/src/dreaming.test.ts (modified, +215/-4)
  • extensions/memory-core/src/dreaming.ts (modified, +88/-54)
  • src/agents/pi-embedded-runner/run.before-agent-reply-cron.test.ts (added, +83/-0)
  • src/agents/pi-embedded-runner/run.overflow-compaction.harness.ts (modified, +9/-0)
  • src/agents/pi-embedded-runner/run.ts (modified, +38/-0)
  • src/commands/doctor-cron-dreaming-payload-migration.constants-drift.test.ts (added, +53/-0)
  • src/commands/doctor-cron-dreaming-payload-migration.test.ts (added, +177/-0)
  • src/commands/doctor-cron-dreaming-payload-migration.ts (added, +92/-0)
  • src/commands/doctor-cron.test.ts (modified, +50/-0)
  • src/commands/doctor-cron.ts (modified, +18/-1)
  • src/gateway/server-plugins.test.ts (modified, +22/-0)
  • src/gateway/server-plugins.ts (modified, +1/-0)
  • src/memory-host-sdk/engine-qmd.ts (modified, +2/-0)
  • src/memory-host-sdk/host/session-files.test.ts (modified, +275/-0)
  • src/memory-host-sdk/host/session-files.ts (modified, +145/-13)
  • src/plugin-sdk/infra-runtime.ts (modified, +0/-1)
  • src/plugins/runtime/types.ts (modified, +1/-0)

Code Example

{
  plugins: {
    entries: {
      "memory-core": {
        config: {
          dreaming: {
            enabled: true,
            frequency: "nightly",
            lightContext: true,
            // optional related controls:
            // bootstrapFiles: ["DREAMING.md"]
          }
        }
      }
    }
  }
}
RAW_BUFFERClick to expand / collapse

Summary

Allow the memory-core plugin to scope dreaming context loading via a lightContext config option, so plugin-managed dreaming work can run with a lean bootstrap without affecting global heartbeat behaviour.

Problem to solve

The memory-core plugin’s Memory Dreaming Promotion job uses a systemEvent payload, which means the actual agent turn is processed by the main heartbeat runner. There is currently no per-plugin way to apply lightContext (or other turn-bootstrap controls) to dreaming work specifically. The cron CLI correctly rejects lightContext on systemEvent payloads (cron.update payload.kind="agentTurn" requires message) — this is by design, since lightContext controls how an agent turn bootstraps and systemEvent payloads don’t run their own agent turn at the cron level. So the rejection isn’t the issue. The issue is that the only available lever for scoping dreaming context is lightContext at the heartbeat level globally — which affects all heartbeat behaviour, not just dreaming. For deployments that want lean dreaming context loading without globally limiting heartbeat behaviour, this forces a tradeoff: either accept full-bootstrap context on every dreaming cycle, or apply lightContext globally and lose richer context for non-dreaming heartbeat work.

Proposed solution

Expose lightContext (and ideally a small set of related turn-bootstrap controls) under the existing memory-core config.

The example below is JSON5 (matching OpenClaw's own config format):

{
  plugins: {
    entries: {
      "memory-core": {
        config: {
          dreaming: {
            enabled: true,
            frequency: "nightly",
            lightContext: true,
            // optional related controls:
            // bootstrapFiles: ["DREAMING.md"]
          }
        }
      }
    }
  }
}

When set, memory-core would propagate this through to the heartbeat runner specifically for dreaming-triggered turns, leaving non-dreaming heartbeat behaviour unchanged. The change is additive to an existing config block (plugins.entries.memory-core.config.dreaming), so no new config tree is required and existing deployments are unaffected unless they opt in.

Alternatives considered

  1. Apply lightContext: true at the heartbeat level globally. Works mechanically, but affects all heartbeat work — not just dreaming. Suboptimal for any deployment where heartbeat does meaningful contextual work outside dreaming.

  2. Apply lightContext directly to the cron job via CLI. Not viable — the CLI correctly rejects lightContext on systemEvent payloads, since the agent turn happens downstream in heartbeat, not at the cron level. This is by design and the right design.

  3. Modify the workspace bootstrap to be lean by default. Would affect all agent turns including interactive sessions, which need full bootstrap. Not a viable workaround for this specific gap.

  4. Disable dreaming entirely. Avoids the cost but loses the capability. Counterproductive.

Impact

Affected users/systems/channels:

• Any OpenClaw deployment using the memory-core plugin with dreaming enabled.

• Particularly impactful for always-on personal assistant deployments running multiple agents with distinct workspaces, where dreaming runs nightly per agent and bootstrap context loading compounds across phases (light/deep/REM) and across agents.

Severity:

• Annoying for single-agent, low-frequency dreaming setups.

• Materially impacts cost and context hygiene for multi-agent, frequent-dreaming deployments. Scheduled jobs that load full bootstrap context were a recurring pattern behind unbounded context growth in our deployment, contributing to a cost incident in the four-figure range across a single month.

Frequency:

• Always — every dreaming cycle loads full bootstrap context. The pain is continuous, not intermittent.

Consequence:

• Higher token spend per dreaming cycle than necessary.

• Forces an undesirable tradeoff between lean dreaming and rich heartbeat context.

• One of the last remaining classes of “scheduled job loads more context than it needs” without a per-plugin scoping mechanism.

Evidence/examples

No response

Additional information

OpenClaw version: 4.15

Related architectural context: per the cron docs, systemEvent payloads correctly hand off to heartbeat for processing. This feature request is not asking that to change. It’s asking for memory-core to expose its own knob for scoping the downstream context loading, since memory-core owns the scheduled job that triggers the downstream work.

If a similar pattern exists for other plugin-managed scheduled work (i.e. plugins that own systemEvent cron jobs without exposing context-loading controls), this could generalise into a broader plugin-level convention. Happy to discuss scope if the maintainers see value in that direction.

extent analysis

TL;DR

Expose a lightContext config option under the memory-core plugin to allow scoping dreaming context loading without affecting global heartbeat behavior.

Guidance

  • Add a dreaming config block to the memory-core plugin with a lightContext option to control context loading for dreaming-triggered turns.
  • Update the memory-core plugin to propagate the lightContext config to the heartbeat runner specifically for dreaming-triggered turns.
  • Verify that the lightContext config is correctly applied by checking the context loading behavior for dreaming cycles.
  • Consider generalizing this pattern to other plugin-managed scheduled work to provide a broader plugin-level convention for scoping context loading.

Example

{
  plugins: {
    entries: {
      "memory-core": {
        config: {
          dreaming: {
            enabled: true,
            frequency: "nightly",
            lightContext: true
          }
        }
      }
    }
  }
}

Notes

This solution assumes that the memory-core plugin can be updated to expose the lightContext config option and propagate it to the heartbeat runner. The impact of this change should be verified to ensure that it does not introduce any unintended behavior.

Recommendation

Apply the proposed solution by exposing the lightContext config option under the memory-core plugin, as it provides a targeted solution to the problem without affecting global heartbeat behavior.

Vote matrix · Quick signals

Works
Did the solution work? Tap to confirm.
Easy Fix
Was it a quick fix?
Time Saver
Did it save you time?
Blocking
Was it severely blocking?
Common Issue
Are others likely hitting this too?
Flaky / Intermittent
Is it intermittent?
Verified / Reproducible
Can you reproduce it reliably?
Loading…
#api#ssr#retrieval issue#search optimization#API routing

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

Back to top recommendations

TRENDING