Bug type

Regression (worked before, now fails)

Beta release blocker

No

Summary

After upgrade from v2026.5.6 to v2026.5.18, dreaming promotion throws file exceeds limit of 16777216 bytes (got 20971907) for a workspace whose memory/.dreams/short-term-recall.json had grown to ~20 MB under v5.6, and per-workspace failure is not surfaced in openclaw cron list or doctor.

Steps to reproduce

1. Run OpenClaw v2026.5.6 long enough for ~/.openclaw/workspace/memory/.dreams/short-term-recall.json to exceed 16,777,216 bytes (observed in our workspace: 20,971,907 bytes after several weeks of high-frequency recall).
2. Upgrade to v2026.5.18 (npm install -g [email protected]).
3. Trigger the managed dreaming cron job: openclaw cron run <dreaming-cron-id> --wait (get the id from openclaw cron list).
4. Read the verbose JSON log at /tmp/openclaw/openclaw-<YYYY-MM-DD>.log.

Expected behavior

On v2026.5.6 the same dreaming cron ran cleanly against a multi-megabyte short-term-recall.json — ~/.openclaw/workspace/memory/.dreams/{deep,light,rem}/ and DREAMS.md were updated nightly with no errors.

Actual behavior

On v2026.5.18, the cron run is marked ok by openclaw cron list but /tmp/openclaw/openclaw-2026-05-19.log shows:

[ERROR 2026-05-19T03:00:00.701-07:00] memory-core: dreaming promotion failed for workspace /Users/<user>/.openclaw/workspace: file exceeds limit of 16777216 bytes (got 20971907) [INFO 2026-05-19T03:00:00.913-07:00] memory-core: dreaming promotion complete (workspaces=2, candidates=0, applied=0, failed=1).

No .dreams subdirectory entries are written. openclaw cron list reports Status: ok for the cron job. doctor --lint reports clean.

OpenClaw version

2026.5.18 (build 50a2481)

Operating system

macOS 26.4 (Tahoe, Apple Silicon), Node 25.8.1

Install method

npm global (installed at /opt/homebrew/lib/node_modules/openclaw/)

Model

deepseek/deepseek-v4-pro

Provider / routing chain

openclaw → deepseek (deepseek-v4-pro)

Additional provider/model setup details

This bug is independent of model/provider — the throw originates in the fs-safe / file-store layer (memory-core internal), reached by the dreaming promotion read path before any LLM call.

Logs, screenshots, and evidence

# Verbose dreaming log (path: /tmp/openclaw/openclaw-2026-05-19.log)
[WARN  2026-05-19T03:00:00.674-07:00] memory-core: managed dreaming cron could not be reconciled (cron service unavailable).
[ERROR 2026-05-19T03:00:00.701-07:00] memory-core: dreaming promotion failed for workspace /Users/<user>/.openclaw/workspace: file exceeds limit of 16777216 bytes (got 20971907)
[INFO  2026-05-19T03:00:00.913-07:00] memory-core: dreaming promotion complete (workspaces=2, candidates=0, applied=0, failed=1).

# `openclaw cron list` at the same time
ID                                   Name                     Schedule         Next       Last       Status
8b2def11-5782-420d-9e62-14e4c6e1ed1c Memory Dreaming Promo... cron 0 3 * * *   in 16h     8h ago     ok

# File size on disk
$ ls -la ~/.openclaw/workspace/memory/.dreams/short-term-recall.json
-rw-------  1 <user>  staff  20971907  May 18 19:30  short-term-recall.json

# Post-mitigation rebuild (after we mv'd the old file and re-ran cron)
$ ls -la ~/.openclaw/workspace/memory/.dreams/short-term-recall.json
-rw-------  1 <user>  staff    193023  May 19 12:01  short-term-recall.json

Impact and severity

Affected: any workspace whose memory/.dreams/short-term-recall.json was ≥ 16 MB at the time of upgrade to v2026.5.18. Observed on one production workspace; a sub-workspace on the same install (file < 16 MB) was unaffected. Severity: High — hard block on dreaming promotion for affected workspaces. No nightly DREAMS.md / .dreams subdirectory updates until the file is manually archived. Frequency: Always — every dreaming cron fire after upgrade hits the same throw until the file is removed/trimmed. Consequence: Silent loss of dreaming feature for affected users. cron list and doctor both still report ok, so the failure is invisible unless the user happens to read /tmp/openclaw/openclaw-<date>.log. macOS default LaunchAgent plist routes stderr to /dev/null, further hiding the error.

Additional information

Last known good version: 2026.5.6 (dreaming cron ran cleanly on this workspace through 2026-05-18 03:00 PDT). First known bad version: 2026.5.18 (upgrade auto-triggered 2026-05-18 ~19:46 PDT; first dreaming run on the new version at 2026-05-19 03:00 PDT failed as shown).

Workaround (immediate unblock, does not prevent recurrence):

mv ~/.openclaw/workspace/memory/.dreams/short-term-recall.json \
   ~/.openclaw/workspace/memory/.dreams/short-term-recall.json.archive.$(date +%Y%m%d)
openclaw cron run <dreaming-cron-id> --wait

After this, OpenClaw rebuilt the file at 193 KB on the next run and dreaming promotion has reported failed=0 since.

Root cause walk-through (against the v2026.5.18 dist):

• Throw site: dist/secure-temp-dir-*.js readOpenedFileSafely: if (params.maxBytes !== void 0 && params.opened.stat.size > params.maxBytes) throw new FsSafeError("too-large", file exceeds limit of ${params.maxBytes} bytes (got ${params.opened.stat.size}));
• maxBytes value: arrives from root(rootDir, defaults) → readDefaults falls back to DEFAULT_ROOT_MAX_BYTES = 16 * 1024 * 1024 when caller passes no explicit value.
• Dreaming read path: dist/short-term-promotion-*.js → privateFileStore(workspaceDir).readJsonIfExists(SHORT_TERM_STORE_RELATIVE_PATH) → dist/file-store-*.js readJsonIfExists → openRoot() passes maxBytes: undefined → fallback kicks in.
• Write path asymmetry: same module uses privateFileStore.writeJson(...) with no maxBytes; write() calls assertMaxBytes(size, undefined) which short-circuits — so writes have no upper bound while reads do. Rebuilt files can therefore grow past the read cap again over time.
• v2026.5.6 baseline does not contain file-store-*.js, private-file-store-*.js, or secure-temp-dir-*.js modules — all three are introduced in v2026.5.18.

Possible directions (evidence-grounded, offered for the team's consideration — leaving prioritization to maintainers):

1. Migration on upgrade: detect over-cap short-term-recall.json on first startup or first dreaming run, trim by maxAgeDays (default 30), log what was dropped, back-up before trim.
2. Write-side rolling trim: have writeJson (or its caller) prune oldest entries when projected size crosses a threshold, so the file cannot grow into an unreadable state.
3. Surface per-workspace failure in openclaw cron list and doctor --lint (e.g. partial-fail (N/M workspaces) when last N days contain failed > 0).
4. macOS gateway install default: set StandardErrorPath to ~/Library/Logs/openclaw/gateway.err.log instead of /dev/null so that this class of failure is visible without enabling verboseLogging.
5. Expose plugins.entries.memory-core.config.dreaming.maxRecallBytes so users with legitimate large-recall workloads can override the 16 MB default.
6. Cosmetic: a [WARN] managed dreaming cron could not be reconciled (cron service unavailable) line fires 27 ms before every successful dreaming run on this install; appears to be benign but is misleading.

Related but distinct upstream tickets (for triage cross-reference, none overlap with this report):

• #84286 (open, 2026-05-19) — different dreaming bug: cron not auto-recreated after plugin re-enable + zero promotion downstream of recallCount reset. Same module (memory-core), unrelated root cause.
• #64068 (closed) — memory-core dreaming candidates=0/applied=0 due to recallCount normalization reset. Different mechanism (algorithm), same module.
• #83943 (open, 2026-05-19) — session-resource-loader unbounded growth, also a 5.x regression. Different module entirely; included as structural reference only.
• #83657 (open, 2026-05-18, P1) — JSON file read retry on transient race conditions for paired.json. Different file and mechanism, but illustrates that fs-safe / JSON-file-read robustness is an active area.