Possible error while dreaming

[supple tree]

I'm on version 2025.5.18, I just turned openclaw on and it looks like it immediately started dreaming, looking at the error logs I can see these:

21:11:34
error
diagnostic
lane task error: lane=session:agent:sql:dreaming-narrative-rem-ce4f97c5f880-1779220952525 durationMs=536395 error="EmbeddedAttemptSessionTakeoverError: session file changed while embedded prompt lock was released: /home/admin/.openclaw/agents/sql/sessions/a63a2c65-869b-4587-93a6-17f7db93fa9d.jsonl"
21:11:44
error
diagnostic
lane task error: lane=dreaming-narrative:dreaming-narrative-deep-5e9d4bab0bad-1779220965387 durationMs=420902 error="EmbeddedAttemptSessionTakeoverError: session file changed while embedded prompt lock was released: /home/admin/.openclaw/agents/sql/sessions/67541583-3ab3-469e-bf0c-0ff3eaa7d210.jsonl"
21:11:44
error
diagnostic
lane task error: lane=session:agent:sql:dreaming-narrative-deep-5e9d4bab0bad-1779220965387 durationMs=420913 error="EmbeddedAttemptSessionTakeoverError: session file changed while embedded prompt lock was released: /home/admin/.openclaw/agents/sql/sessions/67541583-3ab3-469e-bf0c-0ff3eaa7d210.jsonl"
21:12:08
warn
gateway/ws
security warning: websocket origin accepted via Host-header fallback conn=f1ca13c9-4f96-4a7c-8668-86799b920ed6 count=1 host=piclaw:18789 origin=http://piclaw:18789
21:12:08
warn
gateway
security metric: gateway.controlUi.dangerouslyAllowHostHeaderOriginFallback accepted a websocket connect request

[maiden nebula]

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

[turbid holly]

That first error looks like a dreaming/session concurrency guard, not the gateway “crashing”. Dreaming’s diary/narrative phase runs an embedded agent turn, and EmbeddedAttemptSessionTakeoverError: session file changed while embedded prompt lock was released means the session transcript was modified while that embedded prompt had temporarily released its lock. OpenClaw aborts that lane instead of risking a corrupted session file.

A few practical checks:

openclaw memory status --deep
openclaw status --all
openclaw doctor

If you did not mean to enable dreaming, turn it off with:

/dreaming off

or set:

[turbid holly]

{
  "plugins": {
    "entries": {
      "memory-core": {
        "config": {
          "dreaming": {
            "enabled": false
          }
        }
      }
    }
  }
}

Docs: https://docs.openclaw.ai/concepts/dreaming and https://docs.openclaw.ai/help/faq

[turbid holly]

The websocket warnings are separate. They mean gateway.controlUi.dangerouslyAllowHostHeaderOriginFallback=true is enabled and accepted that browser origin via Host-header fallback. If this is just a local/LAN setup you intentionally configured, it may be expected, but it is explicitly the less-safe mode. Prefer setting exact origins under gateway.controlUi.allowedOrigins, e.g. ["http://piclaw:18789"], instead of using the dangerous fallback. Security/config docs: https://docs.openclaw.ai/gateway/configuration and https://docs.openclaw.ai/gateway/security

If those dreaming lane errors repeat every startup or keep piling up after doctor, I’d file a GitHub issue with openclaw --version, openclaw memory status --deep, and a redacted log tail: https://github.com/openclaw/openclaw/issues

[supple tree]

Results from memory deep can be ffound here: https://cl1p.net/4570

[turbid holly]

Thanks, I can read the paste.

That output does not show memory/dreaming as blocked or dirty. It shows all three agents have QMD memory stores present, recall stores populated, and recent recall updates. The important bits I see:

• dreaming is enabled on a 0 */6 * * * schedule for sql, lead-scout, and portfolio-guardian
• sql has a Dream Diary and 16 session-corpus files
• the QMD index is clean: Dirty: no
• embeddings/vector search are unavailable: QMD semantic vectors are unavailable, so vector mode is disabled

So I’d separate this into two issues:

1. The EmbeddedAttemptSessionTakeoverError is probably a Dream Diary/narrative embedded-session race. Annoying, but the status output suggests the memory store itself is not corrupt.
2. The embeddings warning means semantic vectors are not available in this QMD setup. That may reduce memory search quality, but it is not the same as the dreaming lane error.

I’d run this once:

[turbid holly]

openclaw memory status --deep --fix
openclaw doctor

Then restart the gateway and watch whether the same EmbeddedAttemptSessionTakeoverError returns on the next dreaming sweep. If you want it quiet while testing, use /dreaming off temporarily.

Also, can you confirm the exact output of:

openclaw --version

You wrote 2025.5.18; if that was meant to be 2026.5.18, that distinction matters for filing/debugging. If the error repeats after --fix + restart, this is worth a GitHub issue with the redacted logs and this memory status paste: https://github.com/openclaw/openclaw/issues

[supple tree]

I want dreaming to occur, my model only outputs 40 tokens per second so perhaps some timeout was hit?

[turbid holly]

Yes, the slow model can make this more likely, but the specific error you pasted does not look like the normal timeout path.

Your failures were around 420s and 536s. If the embedded agent run itself timed out, I’d expect nearby logs like embedded run timeout: ... timeoutMs=.... The error you got is different: session file changed while embedded prompt lock was released. That points more to a concurrency/session-file race during the Dream Diary narrative turn. A slower model widens the time window where that race can happen, so it may be a contributing factor without being the direct timeout error.

I’d keep dreaming enabled and check these next:

openclaw logs --follow

Then look for either:

• embedded run timeout → actual timeout, worth tuning/reporting as timeout-related
• EmbeddedAttemptSessionTakeoverError again, without timeout logs → likely session-lock/concurrency bug

Since you want dreaming on, don’t use /dreaming off except as a temporary quiet switch. The lower-risk test is to make dreaming less frequent while debugging, so fewer background narrative jobs collide with normal agent activity:

[turbid holly]

{
  "plugins": {
    "entries": {
      "memory-core": {
        "config": {
          "dreaming": {
            "enabled": true,
            "frequency": "0 3 * * *"
          }
        }
      }
    }
  }
}

[turbid holly]

Docs: https://docs.openclaw.ai/concepts/dreaming

If it repeats, I’d file it as a bug with the exact error plus whether embedded run timeout appears nearby. The slow-model detail is useful context for the issue: https://github.com/openclaw/openclaw/issues

[supple tree]

Is there a timeout associated with dreaming though? I can see that it fires off multple prompts in parrellel which get queued up

[turbid holly]

Yes. I checked the installed source: the Dream Diary/narrative subagent has a hardcoded wait timeout of 60,000 ms per narrative run.

A cron-triggered dreaming sweep can also queue several narrative prompts:

• each workspace can do light + REM + deep narrative entries
• cron mode detaches those narrative runs
• detached Dream Diary narratives are capped at 3 concurrent runs
• anything beyond that is queued

So with 3 workspaces, it is very plausible to see multiple prompts queued/running. At ~40 tok/s, a normal 80-180 word diary entry should usually fit inside 60s, but queueing plus slow startup/model latency can make the overall lane duration look much longer. Your log durations around 420s/536s are likely the outer lane/task time, not proof that one model call streamed for that entire time.

The thing that still stands out is the exact error: session file changed while embedded prompt lock was released. If it were purely the 60s narrative timeout, I’d expect logs saying narrative generation ended with status=timeout or embedded run timeout. So I think you may be seeing queued detached narrative runs colliding with session cleanup/session file mutation, not just “model too slow”.

Useful grep while reproducing:

[turbid holly]

openclaw logs --follow | grep -E "narrative generation|embedded run timeout|EmbeddedAttemptSessionTakeoverError|dreaming"

If it repeats, the issue report should mention: 3 memory workspaces, cron dreaming, detached narrative queueing, ~40 tok/s model, and the exact EmbeddedAttemptSessionTakeoverError. That is the shape maintainers need: https://github.com/openclaw/openclaw/issues

[supple tree]

The dreaming definately takes more than 60s. I can see at least 4 prompts running in parrelel, but lmstudio will process the prompt processign serially, so it will easily surpass 60 seconds

[turbid holly]

Yep, that makes sense. If LM Studio is serializing prompt processing, then several “parallel” dreaming narrative runs can easily exceed the 60s wait budget even if each individual diary entry would be short once it starts generating.

Small correction to my earlier framing: the installed code caps detached Dream Diary narrative runs at 3 concurrent, but you can still observe more total model work around the same sweep because the sweep itself can span multiple workspaces/phases and other agent/session work may already be in LM Studio’s queue. From LM Studio’s perspective, that can behave like a serial backlog.

So yes: in your setup, the 60s narrative wait timeout is very likely relevant.

What I’d do pragmatically:

• keep dreaming enabled
• reduce the sweep frequency for now, e.g. daily instead of every 6h
• avoid triggering manual agent runs during the dreaming window if the same LM Studio backend is already busy
• check logs for narrative generation ended with status=timeout or embedded run timeout

Config example:

[turbid holly]

{
  "plugins": {
    "entries": {
      "memory-core": {
        "config": {
          "dreaming": {
            "enabled": true,
            "frequency": "0 3 * * *"
          }
        }
      }
    }
  }
}

[turbid holly]

I don’t see a documented user-facing knob for the Dream Diary narrative timeout in the current docs; the 60s value appears hardcoded in the installed source. Given LM Studio’s serial queue behavior, this is worth filing as a bug/feature request: either make the narrative timeout configurable, or make local/serial backends run dreaming narratives with lower concurrency. https://github.com/openclaw/openclaw/issues

[supple tree]

Can you file a bug that 60 seconds needs to ne configurable

[turbid holly]

I can’t file GitHub issues on your behalf from here, but I can give you a ready-to-paste issue.

Title:

Make Dream Diary narrative timeout configurable for slow/serial local model backends

Body:

## Summary

Dreaming’s Dream Diary narrative subagent wait timeout appears to be hardcoded to 60 seconds. On local model backends such as LM Studio, prompt processing may be serialized even when OpenClaw starts multiple dreaming narrative runs in parallel/queued form. This can cause dreaming narrative runs to exceed 60s and fail even though the backend is still working normally.

## Environment

[turbid holly]

- OpenClaw version: <paste openclaw --version>
- Model/backend: LM Studio / local model
- Approx throughput: ~40 tokens/sec
- Dreaming enabled with multiple memory workspaces/agents
- Dreaming frequency: e.g. `0 */6 * * *`

## Observed behavior

Dreaming starts multiple narrative prompts around the same sweep. LM Studio processes prompt work serially, so queued narrative runs can exceed the 60s wait budget.

Related logs include errors like:

EmbeddedAttemptSessionTakeoverError: session file changed while embedded prompt lock was released

[turbid holly]

and/or timeout-related narrative/embedded-run logs if present.

## Expected behavior

The Dream Diary narrative timeout should be configurable, or OpenClaw should reduce narrative concurrency for local/serial model backends so dreaming can complete reliably.

## Suggested fix

Add a user-facing config key for the Dream Diary narrative timeout, for example under:

```json
{
  "plugins": {
    "entries": {
      "memory-core": {

[turbid holly]

"config": {
"dreaming": {
"narrative": {
"timeoutMs": 300000,
"concurrency": 1
}
}
}
}
}
}
}

Exact config shape can differ, but the important part is making the current 60s timeout tunable.

[turbid holly]

File it here: https://github.com/openclaw/openclaw/issues

Small useful addition: include the output of openclaw --version and a redacted log snippet showing the dreaming lane failure.

[supple tree]

Bug report or new feature?

[turbid holly]

I’d file it as a bug report.

Reason: dreaming is an existing feature, and on a supported local-model setup it can fail because an internal 60s narrative wait budget is not adaptable to serial/slow backends. The requested configurability is the likely fix, but the user-facing problem is “dreaming fails/timeouts on LM Studio due to hardcoded timeout.”

Good title:

Bug: Dream Diary narrative timeout is hardcoded to 60s and fails on serial local model backends

Then in the body, include “requested fix: make timeout/concurrency configurable.”