Memory loss after Update

[supple hull]

Hey there. It seems like I'm messing up the current openclaw update. I am running 2026.5.7 and that agent recognizes their name. When I run openclaw update the process finishes, the agent doesn't even remember their name. New update is 2026.5.12 ...

Am I doing something wrong here?

[unkempt sage]

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

[supple hull]

It looks like on startup the SOUL.md file and all that stuff isn't read correctly @elder ocean , can you help out?

[elder ocean]

Yep — this usually means the upgraded gateway is starting against a different workspace/state dir, not that the update erased the persona.

I checked the current docs/source. OpenClaw keeps persona/memory files in the agent workspace, normally:

~/.openclaw/workspace/AGENTS.md
~/.openclaw/workspace/SOUL.md
~/.openclaw/workspace/USER.md
~/.openclaw/workspace/MEMORY.md

The workspace is separate from session/auth state and is configured with agents.defaults.workspace. Docs: https://docs.openclaw.ai/help/faq and https://docs.openclaw.ai/concepts/memory

First thing I’d check:

openclaw --version
openclaw status --all

[elder ocean]

openclaw config get agents.defaults.workspace
openclaw agents list --bindings

Then verify the workspace path from that config actually contains your old files:

ls -la ~/.openclaw/workspace
ls -la ~/.openclaw/workspace/SOUL.md ~/.openclaw/workspace/MEMORY.md

If those files are somewhere else, set the workspace back to the old path:

openclaw config set agents.defaults.workspace "~/.openclaw/workspace"

[elder ocean]

openclaw gateway restart

If you use profiles, also check you didn’t start the new version under a different profile/state dir. Profiles change the state/workspace location, e.g. ~/.openclaw-<profile> / ~/.openclaw/workspace-<profile>.

One more thing: if a stale BOOTSTRAP.md exists in the active workspace, the agent may act like it’s first-run bootstrapping. Don’t delete anything yet, but check whether it’s there and whether .openclaw/workspace-state.json says setup completed. If you paste the safe openclaw status --all output plus the agents.defaults.workspace value, we can narrow it down quickly. 🦞

[supple hull]

New version is OpenClaw 2026.5.12 (f066dd2) - which is the most recent one

Workspace is set to /home/elisabeth/.openclaw/workspace which contains SOUL.md and the other suspects. No BOOTSTRAP in sight.

[elder ocean]

Good, that narrows it down.

Next check should be from the affected chat/session, not just the shell:

/context list

or, if you can share more detail:

/context detail

That report should include an “Injected workspace files” section. For this case I’d expect at least AGENTS.md, SOUL.md, IDENTITY.md, USER.md, and usually MEMORY.md depending on the session type. If SOUL.md / IDENTITY.md are OK there, OpenClaw is injecting them and the model/provider is ignoring or losing the system context. If they’re MISSING or absent, the runner is resolving a different context path than the config suggests.

Also worth running:

[elder ocean]

openclaw status --all
openclaw doctor

Two details that matter here:

• If this is a Discord group/thread session, MEMORY.md behavior can differ from a private main session, but SOUL.md / IDENTITY.md should still be startup context.
• If you’re using sandboxing, check whether agents.defaults.sandbox / workspace access changed, since sandboxed runs can use a sandbox workspace copy.

If /context detail shows the persona files as OK and the bot still says it doesn’t know its name, I’d treat that as a 2026.5.12 regression and file it with the /context detail output plus openclaw status --all: https://github.com/openclaw/openclaw/issues

[supple hull]

This is weird:

🧠 Context breakdown
Workspace: /home/elisabeth/.openclaw/workspace
Bootstrap max/file: 20,000 chars
Bootstrap max/total: 150,000 chars
Sandbox: mode=off sandboxed=false
System prompt (run): 29,998 chars (~7,500 tok) (Project Context 13,146 chars (~3,287 tok))

Injected workspace files:
- AGENTS.md: OK | raw 2,478 chars (~620 tok) | injected 2,478 chars (~620 tok)
- SOUL.md: OK | raw 5,292 chars (~1,323 tok) | injected 5,292 chars (~1,323 tok)
- TOOLS.md: OK | raw 1,113 chars (~279 tok) | injected 1,113 chars (~279 tok)
- IDENTITY.md: OK | raw 1,296 chars (~324 tok) | injected 1,296 chars (~324 tok)
- USER.md: OK | raw 2,003 chars (~501 tok) | injected 2,003 chars (~501 tok)
- HEARTBEAT.md: OK | raw 1,436 chars (~359 tok) | injected 1,436 chars (~359 tok)
- BOOTSTRAP.md: MISSING | raw 0 | injected 0
- MEMORY.md: OK | raw 516 chars (~129 tok) | injected 516 chars (~129 tok)

Skills list (system prompt text): 4,778 chars (~1,195 tok) (16 skills)
Skills: browser-automation, clawhub, git-workflow, healthcheck, himalaya-email-skill, khal-calendar-skill, node-connect, obsidian-vault-maintainer, ping-host, session-logs, skill-creator, taskflow, taskflow-inbox-triage, tmux, weather, wiki-maintainer
Tool list (system prompt text): 0 chars (~0 tok)
Tool schemas (JSON): 16,748 chars (~4,187 tok) (counts toward context; not shown as text)
Tools: read, edit, write, exec, process, cron, update_plan, sessions_list, sessions_history, sessions_send, sessions_spawn, sessions_yield, subagents, session_status, web_search, image, memory_search, memory_get

Session tokens (cached): unknown / ctx=65,536

Inline shortcut: a command token inside normal text (e.g. “hey /status”) that runs immediately (allowlisted senders only) and is stripped before the model sees the remaining message.

This looks like it should be itself

[elder ocean]

Yep, that confirms the files are being injected. BOOTSTRAP.md: MISSING is fine here; that’s expected after setup is complete.

At this point I’d split it into “bad existing session state” vs “runtime/model ignoring injected persona”:

1. Start a fresh session:

/new

2. Ask something very direct:

What is your name according to IDENTITY.md?

If the fresh session answers correctly, the update didn’t lose memory; the old session likely had stale/compacted context fighting the workspace files. Use the new session or reset the affected one.

If the fresh session still doesn’t know, then this looks like a real 2026.5.12 regression or provider/runtime issue, because /context proves SOUL.md, IDENTITY.md, and MEMORY.md are in the prompt. In that case, please file it with:

[elder ocean]

• your /context list output
• openclaw status --all
• whether /new changes the behavior

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

One more useful probe: ask it to use the file tool to read IDENTITY.md. If it can read the file and quote the right name, but still won’t behave as that identity naturally, that points even more strongly at system-prompt/persona adherence rather than file loading.

[supple hull]

this is getting weirder by the minute, Krill. It looks like it cannot find the IDENTITY file and pokes around blindly. As if half of the stuff is missing.

"What is your name according to IDENTITY.md?" did lead to a lot of nonsense in terms of tool usage, looking for the wrong file. That's highly suspicious.

[elder ocean]

Yeah, that is suspicious. Since /context says the workspace files are injected, but the file tool can’t reliably find IDENTITY.md, I’d now suspect the runtime working directory / ACP session cwd, not the workspace config itself.

Please try these in that same thread/session:

/acp status

Look for runtimeOptions, especially cwd.

Then force it explicitly:

/acp cwd /home/elisabeth/.openclaw/workspace

After that, ask again:

[elder ocean]

Read IDENTITY.md and tell me your configured name.

If that fixes it, the update probably left an existing ACP/session with a stale cwd while the OpenClaw prompt builder still knows the right workspace. If it does not fix it, please file this as a bug; the evidence is now pretty strong:

• /context shows IDENTITY.md: OK
• sandbox is off
• workspace path is correct
• file tools still look in the wrong place / flail

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

As a temporary workaround, absolute paths should cut through the cwd confusion:

Read /home/elisabeth/.openclaw/workspace/IDENTITY.md

[elder ocean]

Not pretty, but it tells us whether the file tool can reach the real workspace at all.

[supple hull]

ACP error (ACP_SESSION_INIT_FAILED): Session is not ACP-enabled: agent:main:dashboard:29670003-3114-48a8-8836-47d8a191a6c5
next: If this session is stale, recreate it with `/acp spawn` and rebind the thread.

That looks like a smoking gun to me.

[elder ocean]

Yep, that’s a good lead. Also: my /acp cwd probe was the wrong branch if this session is not ACP-enabled.

The odd bit is the session key:

agent:main:dashboard:29670003-3114-48a8-8836-47d8a191a6c5

That looks like this Discord thread is routed/bound to a dashboard-origin session. If that binding is stale or half-migrated, it could explain “prompt context says one thing, runtime/tool behavior feels like another.”

I’d try this in the thread:

/agents
/unfocus
/new

[elder ocean]

Then ask the identity question again. /unfocus should remove the thread binding; /new should force a clean normal session for the thread.

If /unfocus says there’s no binding, or after /new it still shows agent:main:dashboard:..., then I’d call this a routing/session-store bug in 2026.5.12 and file it. Include that exact ACP error plus the earlier /context list output: https://github.com/openclaw/openclaw/issues

Temporary workaround: start from a clean unbound chat/thread, or reset/remove the stale thread binding if /agents shows one.

[supple hull]

glad I did snapshot the machine before. It was on the web session btw on the dashboard. Rolling back now.

Just to clarify, openclaw update was the correct path before?

[elder ocean]

Yes, openclaw update is the intended path for normal installs/source checkouts. I checked the current updater help: it handles source checkouts via git and global/package installs via the detected package manager.

Useful variants:

openclaw update status
openclaw update --dry-run
openclaw update
openclaw update --channel stable

Main exception: container/Docker installs don’t use openclaw update; those need the image/container rebuilt or restarted from the newer image.

Given your finding, I don’t think you did the wrong update command. This smells more like a 2026.5.12 dashboard/web-session routing regression or stale dashboard session migration issue. Rolling back from snapshot is reasonable. If you file it, the key clue is that /context showed the workspace files loaded, but the active session key was agent:main:dashboard:... and ACP reported “Session is not ACP-enabled.”

[supple hull]

Can you sum up my problem to file a GH issue?

[elder ocean]

Sure — here’s a paste-ready issue draft.

Title
Dashboard/web session after 2026.5.12 update loses persona/tool workspace behavior despite workspace context being injected

Environment

• OpenClaw version: 2026.5.12 (f066dd2)
• Previous working version: 2026.5.7
• Updated via: openclaw update
• Workspace: /home/elisabeth/.openclaw/workspace
• Session was from the web/dashboard session

Summary
After updating from 2026.5.7 to 2026.5.12, the agent appears to lose its identity/persona and behaves as if workspace files such as IDENTITY.md / SOUL.md are missing. However, /context list shows the correct workspace and reports all relevant workspace files as injected successfully.

Expected behavior
The agent should continue to read and follow the injected workspace files after update, especially SOUL.md, IDENTITY.md, USER.md, and MEMORY.md.

[elder ocean]

Actual behavior
The agent does not recognize its configured identity/name. When asked “What is your name according to IDENTITY.md?”, it performs confused/incorrect tool usage and appears to look for the wrong file or wrong location, despite /context list showing IDENTITY.md: OK.

Important diagnostics
/context list showed:

Workspace: /home/elisabeth/.openclaw/workspace
Sandbox: mode=off sandboxed=false
Injected workspace files:
- AGENTS.md: OK
- SOUL.md: OK
- TOOLS.md: OK
- IDENTITY.md: OK
- USER.md: OK
- HEARTBEAT.md: OK

[elder ocean]

- BOOTSTRAP.md: MISSING
- MEMORY.md: OK

BOOTSTRAP.md: MISSING appears expected because setup was already complete.

When checking ACP/session state, this error appeared:

ACP error (ACP_SESSION_INIT_FAILED): Session is not ACP-enabled: agent:main:dashboard:29670003-3114-48a8-8836-47d8a191a6c5
next: If this session is stale, recreate it with /acp spawn and rebind the thread.

The suspicious part is that the active session key is agent:main:dashboard:..., and the issue happened in a web/dashboard session. This may indicate a stale or partially migrated dashboard session after update: prompt context is built from the correct workspace, but runtime/tool behavior appears to be using the wrong session/cwd/state.

Workaround

[elder ocean]

Rolling back the VM snapshot to the previous version restored behavior.

Extra notes
This does not look like the workspace path being wrong:

• agents.defaults.workspace pointed to /home/elisabeth/.openclaw/workspace
• that directory contained SOUL.md, IDENTITY.md, etc.
• sandboxing was off
• /context list showed the expected files injected

[supple hull]

I filed the report. Based on my digging it could be the ollama provider acting up. Stragely nobody else seem to have an issue like that

[elder ocean]

That’s plausible. Local/Ollama models are much more likely to have trouble with tool calling and instruction hierarchy, so the same prompt can be injected correctly while the model still ignores identity or flails on file reads.

A useful A/B test for the issue would be:

/model status

then temporarily switch the same fresh session to a known tool-reliable cloud model and ask the exact same two prompts:

/context list
What is your name according to IDENTITY.md?
Read IDENTITY.md and tell me your configured name.

If cloud works and Ollama fails with the same /context list, that narrows it from “OpenClaw lost memory” to “Ollama/provider/tool-call regression or model incompatibility in 2026.5.12.”