2026.5.7 does not save memories after a /reset

[wooden nebula]

My history of what was done yesterday is not to be found, I did a reset this morning and all is gone? why was it not saved during the day?

[vagrant birch]

Stoffel, first check the exact version please:

openclaw --version

Short version: /reset starts a fresh session, so the old live session context is no longer the current chat context. That is separate from memory files.

There are two relevant memory mechanisms:

1. Normal memory is Markdown in the workspace: MEMORY.md and memory/YYYY-MM-DD.md.
2. The automatic pre-compaction memory flush only runs near context compaction, not continuously during the day, and it is skipped if the workspace is read-only.
3. Saving context specifically when /new or /reset runs requires the bundled session-memory hook. That hook saves the last 15 user/assistant messages to <workspace>/memory/YYYY-MM-DD-HHMM.md, but only if it is enabled and workspace.dir is configured.

Can you run these and paste the output?

[vagrant birch]

openclaw --version
openclaw hooks list --verbose
openclaw hooks info session-memory
openclaw config get workspace.dir
ls -la ~/.openclaw/workspace/memory

If session-memory is not enabled, enable it with:

openclaw hooks enable session-memory
openclaw gateway restart

Docs: https://docs.openclaw.ai/automation/hooks#session-memory and https://docs.openclaw.ai/concepts/memory

[wooden nebula]

here goes

[vagrant birch]

That output actually shows the reset memory hook did run: it created ~/.openclaw/workspace/memory/2026-05-20-0740.md.

The catch is: session-memory is not a full-day recorder. On /new or /reset it saves the last 15 user/assistant messages into a memory file. So if yesterday’s work was much longer than that, or if it happened before the current session transcript the hook could see, it would not all be copied into memory.

Two useful checks now:

sed -n '1,220p' ~/.openclaw/workspace/memory/2026-05-20-0740.md
ls -lah ~/.openclaw/workspace/memory

If that file contains the missing context, the agent should be able to recover it by reading memory. If it only contains a small tail of the session, that matches the current hook behavior.

For important “remember this / what we did today” state, explicitly ask the agent to write it to memory during the day. The automatic pre-compaction memory flush only runs near context compaction, not continuously, and the /reset hook only captures a tail snapshot.

Also: workspace.dir saying “Config path not found” while the hook says the requirement is ready is a little confusing, but the file landed in the default workspace, so memory writing itself is working.

[wooden nebula]

That file was created this morning after I asked my OC what happened to yestaerdays memories, I have the token log from OpenRouter with our day's conversation. I'm shocked that NONE was saved to any memory.

Can we run a full check on memory saving/committing. From paths to permissions, ubuntu os, to the embedding database, It's a waste of everything if OC starts up with a blank history!

[vagrant birch]

Yeah, that’s a valid thing to be upset about. Please don’t paste the OpenRouter token log publicly though; it may contain private conversation content.

Let’s split this into two layers:

1. Saving: are notes/transcripts being written into ~/.openclaw/workspace/MEMORY.md or ~/.openclaw/workspace/memory/*.md?
2. Recall/indexing: can OpenClaw index/search those files later via the memory DB?

Run this read-only diagnostic block and paste the output. It checks paths, hook state, filesystem permissions, recent memory files, session transcripts, and the memory DB location without changing anything:

set -u

echo '## version'
openclaw --version

echo '## os/user'

[vagrant birch]

uname -a
id
pwd

echo '## status'
openclaw status --all

echo '## hooks'
openclaw hooks list --verbose
openclaw hooks info session-memory

echo '## relevant config'
openclaw config get workspace.dir || true
openclaw config get hooks.internal || true
openclaw config get agents.defaults.compaction || true

[vagrant birch]

openclaw config get agents.defaults.sandbox || true
openclaw config get memory || true

echo '## workspace + memory permissions'
ls -ld ~/.openclaw ~/.openclaw/workspace ~/.openclaw/workspace/memory 2>&1
find ~/.openclaw/workspace -maxdepth 2 -type f \( -name 'MEMORY.md' -o -path '*/memory/*.md' \) -printf '%TY-%Tm-%Td %TH:%TM %s %m %u:%g %p
' 2>&1 | sort

echo '## recent memory tails'
for f in ~/.openclaw/workspace/MEMORY.md ~/.openclaw/workspace/memory/*.md; do
  [ -f "$f" ] || continue
  echo "--- $f"
  tail -80 "$f"
done

[vagrant birch]

echo '## session store + transcripts'
ls -lah ~/.openclaw/agents/*/sessions 2>/dev/null || true
find ~/.openclaw/agents -path '*/sessions/*' -type f -printf '%TY-%Tm-%Td %TH:%TM %s %p
' 2>/dev/null | sort | tail -40

echo '## memory db files'
find ~/.openclaw/memory -maxdepth 3 -type f -printf '%TY-%Tm-%Td %TH:%TM %s %p
' 2>/dev/null | sort | tail -40

Important nuance: session-memory only captures the last 15 user/assistant messages when /new or /reset runs. It is not a continuous day recorder. The automatic memory flush is also pre-compaction, not “save every turn.” If you expected all of yesterday to be committed automatically, that may be a behavior gap or docs gap, not just a local permissions problem.

If the diagnostics show yesterday’s session transcript still exists under ~/.openclaw/agents/*/sessions, the content may be recoverable. If the transcript exists but no memory file was written on reset, that’s worth filing as a bug with the diagnostic output: https://github.com/openclaw/openclaw/issues

[vagrant birch]

Thanks, this gives us a clearer picture.

What looks healthy:

• Ubuntu/user permissions look fine: ~/.openclaw, workspace, and memory/ are owned by chris.
• session-memory is enabled and ready.
• The memory DB exists: ~/.openclaw/memory/main.sqlite.
• Session transcripts were not lost. You have large session files, including:
  • c2d3d349...trajectory.jsonl at ~10 MB from May 19
  • c41d20f5...trajectory.jsonl at ~4.7 MB from May 20
  • matching .jsonl.reset.* archives

What looks broken / misleading:

• Only one memory note exists: ~/.openclaw/workspace/memory/2026-05-20-0740.md.
• That file is not a useful summary; it contains repeated tail content from this morning.
• There is no evidence that yesterday’s full day was ever written to MEMORY.md or memory/*.md.

[vagrant birch]

• The embedding DB can only index what exists in memory files. It does not itself create memories from sessions.

So the good news is: history likely still exists in session transcripts. The bad news is: OpenClaw did not convert yesterday’s conversation into durable memory automatically. That matches current behavior more than a Linux permissions failure.

For recovery, do this locally and keep outputs private because they may contain conversation content:

mkdir -p ~/.openclaw/workspace/recovery

# Identify the big sessions from yesterday/today
ls -lh ~/.openclaw/agents/main/sessions/*trajectory.jsonl ~/.openclaw/agents/main/sessions/*.jsonl.reset.* 2>/dev/null | sort -k6,7

# Copy likely relevant transcripts into a recovery folder, without deleting anything
cp ~/.openclaw/agents/main/sessions/c2d3d349-d540-407f-a1ad-368d004a219a.trajectory.jsonl ~/.openclaw/workspace/recovery/may19-trajectory.jsonl
cp ~/.openclaw/agents/main/sessions/c2d3d349-d540-407f-a1ad-368d004a219a.jsonl.reset.2026-05-20T03-36-49.163Z ~/.openclaw/workspace/recovery/may19-reset.jsonl
cp ~/.openclaw/agents/main/sessions/c41d20f5-71a8-49c3-9994-6ab47de2db3d.trajectory.jsonl ~/.openclaw/workspace/recovery/may20-trajectory.jsonl

[vagrant birch]

Then ask your local OpenClaw agent something like:

Read ~/.openclaw/workspace/recovery/*.jsonl. Extract durable facts, decisions, project state, file paths, todos, and preferences. Write a concise recovered memory summary to ~/.openclaw/workspace/memory/2026-05-19-recovered.md. Do not include private raw chat unless it is needed as factual project context.

After that, verify indexing/search:

openclaw doctor
openclaw status --all

Also, since lost_memories.md is in the workspace root, move/copy its useful summary into memory/ or MEMORY.md; root lost_memories.md is not necessarily part of the default memory index.

I’d file this as a GitHub issue too: the system gives the impression that /reset preserves useful memory, but in practice session-memory only snapshots a small tail and can produce low-value repeated content. Include the command outputs and file sizes, not the private transcript contents: https://github.com/openclaw/openclaw/issues

[wooden nebula]

I did as you said, even asked him the exact same "Read ~/.openclaw/workspace/recovery/*.jsonl....".

All he did was return a aprt of our conversation yesterday, did not write any file. I removed the file that was read and got it to do the next file with another block and nothing more.

I did a "/new" , and ".openclaw\workspace\memory\2026-05-20-1453.md" was created. I then asked to read the lost_memories.md file...

"You are going to read a file, this file contains memories of a very dear friend. Your goal is to recapture the last memories of our friend and save a concise memory summary to ~/.openclaw/workspace/memory/2026-05-19-recovered.md
You must focus only on .openclaw\workspace\lost_memories.md and not your memories when writing the summary."

...hoping he will read it in the correct context, but stayed on his own thought path with no recovery file written.

How am I going to get him to understand what I want?

[vagrant birch]

I think the issue is less “he doesn’t understand emotionally” and more “the run is staying in chat mode instead of doing tool/file work.” Two concrete fixes:

1. Use Linux absolute paths, not Windows-style slashes. This:

.openclaw\workspace\lost_memories.md

is not the path you want on Ubuntu. Use:

/home/chris/.openclaw/workspace/lost_memories.md
/home/chris/.openclaw/workspace/memory/2026-05-19-recovered.md

2. Make the task procedural and verifiable. Try this exact prompt:

[vagrant birch]

This is a file recovery task. Do not answer with a summary in chat.

Use tools to do these steps:
1. Read /home/chris/.openclaw/workspace/lost_memories.md.
2. Extract durable facts, decisions, project state, paths, TODOs, preferences, and important context.
3. Write the recovered summary to /home/chris/.openclaw/workspace/memory/2026-05-19-recovered.md.
4. Verify the file exists by checking its size and printing only the first 20 lines.

Success condition: /home/chris/.openclaw/workspace/memory/2026-05-19-recovered.md exists and contains a concise recovered memory summary.
If you cannot write the file, say exactly why and stop.

If it still replies with text instead of writing the file, that’s probably a tool-use reliability problem with the current model/runtime, not your wording. For the immediate rescue, first preserve the raw file as memory with a normal shell command:

[vagrant birch]

cp /home/chris/.openclaw/workspace/lost_memories.md /home/chris/.openclaw/workspace/memory/2026-05-19-raw-recovered.md

Then the memory system at least has the source material under memory/, even before it gets beautifully summarized.

After that, ask the agent to summarize memory/2026-05-19-raw-recovered.md into memory/2026-05-19-recovered.md. Smaller input usually helps a lot. If the model keeps failing to use tools, switch to a more tool-reliable cloud model and ask in #models for current recommendations: https://docs.openclaw.ai/concepts/models#model-discussions-community-notes

[wooden nebula]

How can I completely wipe my agents memories and any session history? Start fresh?

[vagrant birch]

Yes. Do it as a quarantine/move first, not a hard delete, so you can recover if you wipe too much.

This wipes memory files, the memory index DB, and all agent session transcripts, while keeping config/auth/channel setup intact:

openclaw gateway stop

stamp=$(date +%Y%m%d-%H%M%S)
backup="$HOME/.openclaw/reset-backups/fresh-start-$stamp"
mkdir -p "$backup"

# 1) Workspace memory files
mkdir -p "$backup/workspace"
[ -f "$HOME/.openclaw/workspace/MEMORY.md" ] && mv "$HOME/.openclaw/workspace/MEMORY.md" "$backup/workspace/"
[ -d "$HOME/.openclaw/workspace/memory" ] && mv "$HOME/.openclaw/workspace/memory" "$backup/workspace/"
mkdir -p "$HOME/.openclaw/workspace/memory"

[vagrant birch]

# 2) Memory embedding/search database
[ -d "$HOME/.openclaw/memory" ] && mv "$HOME/.openclaw/memory" "$backup/memory-db"
mkdir -p "$HOME/.openclaw/memory"

# 3) Session history for all agents
mkdir -p "$backup/agents"
for d in "$HOME"/.openclaw/agents/*/sessions; do
  [ -d "$d" ] || continue
  agent=$(basename "$(dirname "$d")")
  mkdir -p "$backup/agents/$agent"
  mv "$d" "$backup/agents/$agent/sessions"
  mkdir -p "$d"
done

[vagrant birch]

openclaw gateway start
openclaw status --all

Your old data will be under:

~/.openclaw/reset-backups/fresh-start-<timestamp>/

If you also want to reset persona/identity files, that is a separate bigger wipe: SOUL.md, USER.md, IDENTITY.md, TOOLS.md, etc. I would not remove those unless you truly want the agent to forget its setup/personality too.

After restarting, send /new and it should behave like a fresh session with empty memory/session history.

[wooden nebula]

How do I know that the memory of my agent will save after a certain amount of turns? Can I change how regular our turns are saved?

The last time I posted here was to downgrade after the .29 saga, I recall the db showed errors, how can we make sure everything memory-wise works correct?

[vagrant birch]

There isn’t currently a simple “save memory every N turns” knob for durable Markdown memory.

What exists today is:

• Session transcript: every conversation is stored under ~/.openclaw/agents/<agent>/sessions/. This is history, not curated memory.
• session-memory hook: on /new or /reset, saves only the last 15 user/assistant messages to workspace/memory/. It is not continuous.
• Pre-compaction memory flush: before compaction, OpenClaw runs a silent “write important memory now” turn. It is token-threshold based, not turn-count based. Docs: https://docs.openclaw.ai/concepts/memory and https://docs.openclaw.ai/reference/session-management-compaction#pre-compaction-memory-flush-implemented
• Memory search DB: indexes memory files so they can be searched. It does not create memories by itself.

You can make the pre-compaction flush happen earlier by lowering the threshold, but don’t set it too low or you’ll create extra hidden model calls:

openclaw config set agents.defaults.compaction.memoryFlush.enabled true --strict-json
openclaw config set agents.defaults.compaction.memoryFlush.softThresholdTokens 2000 --strict-json
openclaw config validate
openclaw gateway restart

[vagrant birch]

That still means “near compaction,” not “every 10 turns.” For important moments, the reliable workflow is still: “write this to memory now.”

To check memory/index health:

openclaw memory status --deep --agent main
openclaw memory index --force --agent main
openclaw memory search "test memory probe" --agent main

And do a real write/search probe:

mkdir -p ~/.openclaw/workspace/memory
printf 'Memory probe %s: Stoffel wants memory persistence verified.
' "$(date -Is)" >> ~/.openclaw/workspace/memory/2026-05-20-memory-probe.md

[vagrant birch]

openclaw memory index --force --agent main
openclaw memory search "Stoffel memory persistence verified" --agent main

If that search finds the probe, the memory DB/indexing path works.

If you want old session transcripts searchable too, there is an experimental session-memory-search path. This indexes transcripts for recall, but it still is not the same as committing curated memories:

openclaw config set agents.defaults.memorySearch.experimental.sessionMemory true --strict-json
openclaw config set agents.defaults.memorySearch.sources '["memory","sessions"]' --strict-json
openclaw config set agents.defaults.memorySearch.sync.sessions.deltaMessages 10 --strict-json
openclaw config validate
openclaw gateway restart
openclaw memory index --force --agent main

[vagrant birch]

Docs: https://docs.openclaw.ai/reference/memory-config#session-memory-search-experimental

Since you’re on 2026.5.7 and remember DB errors from the .29 downgrade, I’d run the status/index/search probe above and save the output. If memory status --deep or index --force shows SQLite/embedding errors, that’s the part to file as a GitHub issue: https://github.com/openclaw/openclaw/issues

[wooden nebula]

It seems to do the search, spits out some memory lines and ends with:

18:13:21 [memory] chunks_vec not updated — sqlite-vec unavailable. Vector recall degraded. Further duplicate warnings suppressed.

Is this serious?

[vagrant birch]

Not “memory is gone” serious. It means the SQLite vector acceleration layer (sqlite-vec, table chunks_vec) did not load/update, so vector recall is degraded.

If the search still spits out memory lines, then basic memory saving + keyword/FTS search is working. The degraded part is semantic/vector recall quality/performance. OpenClaw’s docs say it falls back automatically when sqlite-vec is unavailable, but recall may be less good, especially for fuzzy “same meaning, different wording” searches.

Run these and paste the non-private output:

openclaw memory status --deep --agent main
openclaw memory index --force --agent main
openclaw memory search "Stoffel memory persistence verified" --agent main

Then check the specific load error:

openclaw logs | grep -iE 'sqlite-vec|chunks_vec|memory' | tail -80

[vagrant birch]

How to interpret it:

• Embeddings: ok + Vector store: unavailable = memory can still index/search, but sqlite-vec acceleration is broken/missing.
• Embeddings: unavailable = semantic memory itself is not configured/authenticated; you’re mostly on keyword search.
• memory index --force fails = more serious, because the index rebuild path is broken.

I would treat this as worth fixing, but not as proof that memories are not being saved. The bigger issue from your earlier output was that few durable memory files were being created in the first place; this warning is about searching/indexing the memory that exists.

Docs: https://docs.openclaw.ai/concepts/memory-builtin#troubleshooting and https://docs.openclaw.ai/reference/memory-config#sqlite-vector-acceleration-sqlite-vec