#Messages disappearing and losing session memory

1 messages · Page 1 of 1 (latest)

dire tendon
#

When my side agent (not a subagent) that I have for dev'ing hits a fallback model, the entire session history disappears.

Have tried to manually reset session history, openclaw configure, openclaw doctor multiple times,
change different models, nothing worked.

What can I do to trouble shoot?

west zodiacBOT
neon roostBOT
#

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

west zodiacBOT
unreal steepleBOT
#

I’m checking source/docs for anything specific to fallback + session-store resets so I don’t make you chase ghosts.

#

That’s not expected. Fallback should change the model selection, not nuke session memory. This smells more like a session store/routing problem than a model problem.

First, please paste:

openclaw --version

Then run this once before reproducing, reproduce the fallback, then run it again:

openclaw status --all
openclaw models status
openclaw sessions --all-agents --active 1440 --json
openclaw logs --follow
#

What I’d check specifically:

  • did the session key change?
  • did the agentId change?
  • did the sessionId/sessionFile change?
  • did the convo move from your side agent store to main (or another agent store)?

For named agents, history lives per agent here:

~/.openclaw/agents/<agentId>/sessions/sessions.json
~/.openclaw/agents/<agentId>/sessions/<sessionId>.jsonl

So also compare your dev agent vs main:

#
~/.openclaw/agents/main/sessions/
~/.openclaw/agents/<your-dev-agent>/sessions/

Most likely causes:

  1. Agent store split / reroute
    fallback coincides with the session being looked up under a different agent store.

  2. Reset/restart creating a new sessionId
    especially if logs show a reload/restart near the same time.

  3. Older build with session key/history bugs
    there have been recent fixes around orphaned session keys and session-history handling, so version matters a lot here.

When you reproduce it, grab the 30 to 60 log lines around the failure and look for: