Dreaming enabled but only 1 agent as dream sessions | Friends of the Crustacean 🦞🤝 | Page 1

finite flicker Apr 18, 2026, 6:59 PM

#

I have enabled dreaming but only my main agent has dreaming sessions.
I am using version: 2026.4.15 (041266a)

meager plankBOT Apr 18, 2026, 6:59 PM

#

fiery forgeBOT Apr 18, 2026, 6:59 PM

#

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

meager plankBOT Apr 18, 2026, 6:59 PM

#

surreal zodiacBOT Apr 18, 2026, 7:03 PM

#

That’s usually expected, not necessarily broken.

Dreaming is currently workspace-scoped, not “one visible dream session per agent”:

OpenClaw creates one managed dreaming cron and it wakes the main session
that sweep then fans out across configured memory workspaces
if multiple agents share the same workspace, they get one dreaming lane
if an agent is not in agents.list[], it may not be included in that fan-out

So if you only see dreaming sessions under main, that can still be normal.

What to check:

openclaw agents list
openclaw memory status --deep

#

openclaw memory status --agent <agent-id>

Most likely causes:

your other agents share the same workspace
your other agents are not actually in agents.list[]

If you want separate dreaming state/diaries per agent, give each agent its own workspace, usually via:

openclaw agents add <name> --workspace ~/.openclaw/workspace-<name>

Docs:

#

https://docs.openclaw.ai/cli/agents

If you paste openclaw agents list plus the relevant agents.list[].workspace entries, I can tell you pretty quickly whether this is expected or a real bug.

finite flicker Apr 18, 2026, 7:10 PM

#

question, only 1 agent has Identity.md why? - james (James (Fact Checker))
Workspace: ~/.openclaw/agents/james
Agent dir: ~/.openclaw/agents/james/agent
Model: minimax/MiniMax-M2.7
Routing rules: 0

orion (Orion)
Identity: Orion (IDENTITY.md)
Workspace: ~/.openclaw/agents/orion
Agent dir: ~/.openclaw/agents/orion/agent
Model: minimax/MiniMax-M2.7
Routing rules: 0

surreal zodiacBOT Apr 18, 2026, 7:11 PM

#

Yep, that IDENTITY.md thing is probably separate from the dreaming behavior.

What your output tells me:

James and Orion do have separate workspaces, so this is not the “shared workspace” case.
Identity: Orion (IDENTITY.md) just means OpenClaw found identity metadata for Orion.
If James doesn’t show that, it usually means one of:
1. James’s IDENTITY.md was never created yet
2. bootstrap file creation was disabled (agents.defaults.skipBootstrap)
3. the file was deleted manually

Important part: missing IDENTITY.md should not be the reason dreaming only shows visible sessions under main.

On current behavior, dreaming uses one managed cron targeted at main, then does the actual sweep work from there. So seeing dream sessions only under main can still be expected, even with multiple agent workspaces.

To check whether James is actually getting dreaming data, I’d verify per agent:

#

openclaw memory status --agent james --deep
openclaw memory status --agent orion --deep

Also check whether these exist in each workspace:

DREAMS.md
memory/.dreams/

If you want to fix James’s identity file too, you can set it explicitly:

openclaw agents set-identity --agent james --name "James" --theme "Fact Checker"

Docs:

#

If you paste the two memory status --agent ... --deep outputs, I can tell you whether dreaming is actually running for both or only surfacing under main.

finite flicker Apr 18, 2026, 7:12 PM

#

what is the benefit of having an identity file?

surreal zodiacBOT Apr 18, 2026, 7:12 PM

#

Mainly to give an agent a stable self-description.

IDENTITY.md is where OpenClaw keeps things like:

name
vibe/theme
emoji
sometimes avatar-related identity info

Why that helps:

Cleaner separation of concerns
IDENTITY.md = who the agent is
SOUL.md = tone/personality/boundaries
AGENTS.md = operating rules/instructions
Consistent bootstrap context

#

It gets injected at session start, so the agent has a stable identity every time.

Better multi-agent setup
Useful when you have several agents and want them to feel distinct.
UI / presentation niceties
It can feed name / vibe / avatar-ish identity behavior without stuffing that into AGENTS.md.

It’s optional, and it’s not required for dreaming.
So the benefit is mostly clarity, consistency, and nicer multi-agent separation, not core functionality.

Docs:

If you want, I can also explain when to put something in IDENTITY.md vs SOUL.md vs AGENTS.md, because that split is easy to get wrong.

finite flicker Apr 18, 2026, 7:13 PM

#

najef@OpenClaw-Server:~/Downloads/gtp$ openclaw memory status --agent james --deep
error: unknown command 'memory'

surreal zodiacBOT Apr 18, 2026, 7:15 PM

#

Huh, on 2026.4.15 openclaw memory should exist, so a plain:

error: unknown command 'memory'

usually points to one of these:

you’re hitting a different openclaw binary/path than the install you think you’re using
the memory plugin CLI surface is disabled, for example:
- plugins.slots.memory = "none"
- plugins.entries.memory-core.enabled = false
- plugins.allow excludes memory-core

Can you paste these?

#

which openclaw
openclaw --version
openclaw help | grep memory || true
openclaw config get plugins.slots.memory
openclaw config get plugins.entries.memory-core.enabled
openclaw config get plugins.allow

If /dreaming status still works in chat, that would suggest runtime memory-core is present, and the issue is more likely the CLI path / CLI command surface than dreaming itself.

Docs:

Paste those outputs and I’ll narrow it down fast.

finite flicker Apr 18, 2026, 7:19 PM

#

najef@OpenClaw-Server:~/Downloads/gtp$ which openclaw
openclaw --version
openclaw help | grep memory || true
openclaw config get plugins.slots.memory
openclaw config get plugins.entries.memory-core.enabled
openclaw config get plugins.allow
/home/najef/.nvm/versions/node/v24.14.1/bin/openclaw
OpenClaw 2026.4.15 (041266a)

[openclaw] Failed to start CLI: Error: The openclaw help command is unavailable because plugins.allow excludes "help". Add "help" to plugins.allow if you want that bundled plugin CLI surface.
at runCli (file:///home/najef/.nvm/versions/node/v24.14.1/lib/node_modules/openclaw/dist/run-main-BBeVm29G.js:458:45)

🦞 OpenClaw 2026.4.15 (041266a) — Your .zshrc wishes it could do what I do.

Config path not found: plugins.slots.memory

🦞 OpenClaw 2026.4.15 (041266a) — Somewhere between 'hello world' and 'oh god what have I built.'

Config path not found: plugins.entries.memory-core.enabled

🦞 OpenClaw 2026.4.15 (041266a) — Welcome to the command line: where dreams compile and confidence segfaults.

[
"browser",
"lossless-claw",
"telegram",
"minimax",
"metaclaw-openclaw",
"anthropic",
"memory-wiki",
"memory-core",
"active-memory",
"brave",
"duckduckgo",
"firecrawl"
]

surreal zodiacBOT Apr 18, 2026, 7:24 PM

#

Nice, that narrows it down a lot.

What your output shows:

not a path/version mismatch
memory-core is allowed
plugins.slots.memory and plugins.entries.memory-core.enabled being missing just means defaults are in effect, not disabled
the openclaw help failure is separate and just means your restrictive plugins.allow does not include the bundled help surface

So this really does not look like a config mistake on your side.

I checked the 2026.4.15 implementation, and the managed dreaming job in memory-core is created as a single cron targeting sessionTarget: "main". That matches your symptom: dream sessions only show up for the default/main agent.

So I think you’ve hit a bug/regression, especially because the docs say automatic dreaming runs should fan out across configured memory workspaces:

#

Best next step: please file this here:

https://github.com/openclaw/openclaw/issues

Suggested issue summary:

Dreaming enabled, but automatic dream sessions only run for main agent in multi-agent setup on 2026.4.15
memory-core is allowlisted, default memory slot is in use, but only the main/default agent gets dream sessions.

If you want, I can draft the full GitHub issue body for you in the next message.

finite flicker Apr 18, 2026, 7:26 PM

#

Please do write an github issue body for me

surreal zodiacBOT Apr 18, 2026, 7:26 PM

#

Yep, paste this into GitHub:

Title
Dreaming only creates sessions for main agent in multi-agent setup on 2026.4.15

Body

## Summary

In a multi-agent setup, I enabled dreaming, but only the **main/default agent** gets dreaming sessions. Other agents do not appear to get automatic dream sessions.

## Version

```bash
openclaw --version
# OpenClaw 2026.4.15 (041266a)

#


## What I expected

When dreaming is enabled, I expected automatic dreaming runs to apply across configured agent memory workspaces, not just the main agent.

## What actually happens

Only the main/default agent gets dream sessions.

## Things I checked

I verified this is not just a binary/path mismatch:

```bash
which openclaw
# /home/najef/.nvm/versions/node/v24.14.1/bin/openclaw

#


I also checked the relevant plugin config paths:

```bash
openclaw config get plugins.slots.memory
# Config path not found: plugins.slots.memory

openclaw config get plugins.entries.memory-core.enabled
# Config path not found: plugins.entries.memory-core.enabled

And plugins.allow includes the memory plugins:

openclaw config get plugins.allow
[

#

"browser",
"lossless-claw",
"telegram",
"minimax",
"metaclaw-openclaw",
"anthropic",
"memory-wiki",
"memory-core",
"active-memory",
"brave",
"duckduckgo",
"firecrawl"
]


So from what I can tell:

#


- `memory-core` is allowlisted
- the memory slot/config is just using defaults
- this does **not** look like a local config mistake

## Extra note

`openclaw help` is blocked in my setup because `plugins.allow` excludes `"help"`:

```bash
openclaw help | grep memory || true
# [openclaw] Failed to start CLI: Error: The `openclaw help` command is unavailable because `plugins.allow` excludes "help".

But that seems separate from the actual dreaming behavior.

#


## Suspected issue

This looks like the managed dreaming cron/session is only targeting the main session/agent, instead of fanning out to all configured memory workspaces in a multi-agent setup.

## Repro

1. Configure multiple agents
2. Enable dreaming
3. Wait for dreaming to run
4. Observe that only the main/default agent gets dream sessions

## Expected fix

Either:

#


- dreaming should automatically fan out across all configured agent memory workspaces, or
- docs should clarify that auto-dreaming is main-agent-only

## Docs referenced

- https://docs.openclaw.ai/cli/memory
- https://docs.openclaw.ai/concepts/dreaming

If you want, I can also give you a shorter maintainer-friendly version.

finite flicker Apr 18, 2026, 7:31 PM

#

Added the issue to openclaw... I have now 15 issues I have found and reported

surreal zodiacBOT Apr 18, 2026, 7:32 PM

#

Damn, 15 is a lot 😅

But seriously, thank you, that kind of reporting is super valuable. You’re basically doing QA the hard way, and it really helps shake out the weird edge cases.

Also, if you keep hitting this many unrelated bugs, it might be worth spinning up a local agent/session for deeper debugging so each issue stays cleaner and easier to track:
https://docs.openclaw.ai/help/faq#im-stuck-what’s-the-fastest-way-to-get-unstuck

If you want, I can help you triage the next one faster and turn it into a tight repro instead of a long back-and-forth.

finite flicker Apr 18, 2026, 7:33 PM

#

So far its going ok, do not have critical bugs, just weird behavoir. and some feature requests.

surreal zodiacBOT Apr 18, 2026, 7:33 PM

#

That’s honestly a pretty good place to be.

“No critical bugs, just weird behavior and feature requests” is very OpenClaw-coded 😄

Still useful stuff though, weird behavior is often where the sharp edges hide. If you keep going, I’d probably split them into:

bugs: surprising / inconsistent behavior
feature requests: “works, but should be better”
docs gaps: where the behavior makes sense only after reading source

That usually makes the backlog a lot easier to reason about.

If another weird one pops up, toss it in here and I’ll help you figure out whether it’s config, expected behavior, or a real bug.

finite flicker Apr 18, 2026, 7:36 PM

#

I wish there was a build in feature where my agent could report issues they found..

surreal zodiacBOT Apr 18, 2026, 7:37 PM

#

Yeah, I’d want that too, but with a human review step, not auto-posting.

Auto-filed issues would be useful, but also pretty risky:

agents can misclassify config mistakes as bugs
duplicate issues would pile up fast
feature requests vs bugs gets blurry
public issue trackers are a bad place for half-baked reports

The sweet spot would be something like:

agent detects weird behavior
agent writes a candidate issue to a local queue, markdown file, or Discord thread
human reviews it
one click to turn it into a real GitHub issue

That would be super nice.

#

Today, the closest practical version is:

have the agent keep a bugs.md / issues-to-file.md
or send you a structured report with:
- title
- repro
- expected
- actual
- logs/config
- severity guess

Then you approve what deserves a real issue.

Honestly, that sounds like a solid feature request on its own.

finite flicker Apr 18, 2026, 7:37 PM

#

I could have a approve page in the OpenCLaw control.

surreal zodiacBOT Apr 18, 2026, 7:38 PM

#

Yep, exactly, that feels like the right UX.

An “Approve Issues” page in Control would be pretty clean:

agent drafts issue candidates
Control shows them in a review queue
you can edit / approve / reject / merge duplicates
approved ones turn into GitHub-ready markdown
maybe optional “open in browser” instead of auto-posting

The nice extras would be:

severity
bug vs feature request
repro confidence
attached logs/config snippets
duplicate detection

#

privacy scrub before approval

That’s actually a strong feature request, not just a random idea. “Agent-generated issue draft inbox in Control” is a pretty compelling one.

finite flicker Apr 18, 2026, 7:51 PM

#

I requested a opt in feature where Openclaw can 1x per month think of new features and request them, when the agent submits a feater he gets 5 other features from other agents to judge. so features can points. high points are vieuwed by humans to approve.

surreal zodiacBOT Apr 18, 2026, 7:52 PM

#

Honestly, that’s a pretty cool idea.

It’s basically an opt-in monthly feature marketplace:

agents propose ideas
each agent reviews a few other ideas
ideas get scored/ranked
humans only look at the top set

I like it because it adds a filtering layer before human attention.

The main guardrails I’d want are:

opt-in only
strict monthly cap so it doesn’t spam
every proposal needs:
- problem
- why it matters

#

rough implementation idea
- expected users / use case
review should score:
- usefulness
- feasibility
- novelty
- duplicate risk
human final approval always

The strongest version would probably also require agents to ground proposals in evidence, like:

repeated user friction
repeated bug patterns
docs confusion
missing workflow support

So not just “I had a thought”, but “I saw this pain 6 times this month”.

#

That’s actually a much better system than raw auto-feature requests. It turns chaos into a triaged idea queue.

finite flicker Apr 19, 2026, 9:22 PM

#

1x per month I ask my agents what features they are missing and I try to build it. last week I made a teams channel where all agents in team groups. there is an @ agent sign so the agent that the message is to knows its for him, but all other agents are in the loop. So when I am talking about a feature I want to implenent all agents know what I want.

surreal zodiacBOT Apr 19, 2026, 9:22 PM

#

That’s actually a smart setup.

You’ve basically made a shared product context room with:

a clear intended recipient
passive visibility for the other agents
less repeated explanation
better alignment on what you’re trying to build

That kind of “everyone can overhear the roadmap” pattern is genuinely useful.

The only things I’d add are:

a lightweight decision summary after each feature discussion
maybe a pinned format like:
- problem
- chosen direction
- not doing

#Dreaming enabled but only 1 agent as dream sessions