Claude-CLI Context Reset | Friends of the Crustacean 🦞🤝 | Page 1

quartz compass Apr 18, 2026, 2:09 PM

#

When using claude-cli backend with sonnet, summary compactions seem to occur on the server side with no indication. Only after prompting am I able to tell that it happened. Usually its smooth, though some important context seems to be lost at times. But sometimes, after the compaction, the summary does not seem to get forwarded to the model and the session essentially becomes a blank slate.

broken breachBOT Apr 18, 2026, 2:09 PM

#

solar kernelBOT Apr 18, 2026, 2:09 PM

#

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

broken breachBOT Apr 18, 2026, 2:09 PM

#

toxic stoneBOT Apr 18, 2026, 2:15 PM

#

Short version, on current main this looks mostly like Claude CLI / Anthropic session behavior, not OpenClaw compaction.

I checked the current integration:

extensions/anthropic/cli-backend.ts
src/agents/cli-runner/execute.ts
src/agents/command/attempt-execution.ts

What OpenClaw does for claude-cli is basically:

fresh turn: run claude -p ...
resumed turn: run claude -p ... --resume {sessionId}
only send the OpenClaw system prompt on the first session turn (systemPromptWhen: "first")

So if you see a silent summary/compaction with no explicit signal, that is very likely happening inside Claude’s own session backend. OpenClaw’s own pre-threshold memory flush path explicitly skips CLI backends: https://docs.openclaw.ai/reference/session-management-compaction
CLI backend docs: https://docs.openclaw.ai/gateway/cli-backends

#

Why context can feel lossy:

OpenClaw does not replay its local transcript back into Claude on resume.
It persists transcript/history for OpenClaw’s side, but resumed Claude context depends on the Claude session ID continuing to work.
So if Anthropic compacts/summarizes that session, any detail loss is upstream and inherently lossy.

Why it can become a full blank slate:

Claude session expired / vanished
OpenClaw classifies errors like No conversation found with session ID ... as session_expired, clears the stored CLI session, then retries fresh. That will look like a reset.
OpenClaw intentionally invalidated the Claude session binding
It will reset the reusable CLI session if auth changed, auth epoch changed, system prompt hash changed, or MCP config hash changed. It logs:
- cli session reset: provider=claude-cli reason=auth-profile|auth-epoch|system-prompt|mcp
Claude resumed the same session ID, but its server-side summary was bad/incomplete
In that case it is not an OpenClaw reset, it is Claude-side context loss.

What I’d check next:

#

Paste openclaw --version
Reproduce with gateway started using --cli-backend-logs
Look for either of these:
- cli session reset: provider=claude-cli reason=...
- CLI session expired, clearing from session store...
If possible, compare the cliSessionId before/after the reset
Also check whether the corresponding Claude local transcript still exists under ~/.claude/projects/.../<sessionId>.jsonl

Interpretation:

new sessionId or reset log = OpenClaw started a fresh Claude session
same sessionId, but missing context = likely Claude-side compaction/resume issue

So, yes, your read is basically right: with claude-cli, OpenClaw is a thin session bridge, not the owner of the actual long-context state.

If you paste your version plus one log snippet from a “blank slate” event, I can help narrow it down pretty quickly.

quartz compass Apr 21, 2026, 10:40 PM

#

How do I "Reproduce with gateway started using --cli-backend-logs"?

toxic stoneBOT Apr 21, 2026, 10:41 PM

#

Easiest way is to run the Gateway in the foreground once, with that flag enabled.

If you normally run OpenClaw from source:

pnpm openclaw gateway stop
pnpm openclaw gateway run --cli-backend-logs

If you installed it globally:

openclaw gateway stop
openclaw gateway run --cli-backend-logs

Then:

#

leave that terminal open
reproduce the Claude CLI reset/blank-slate issue
copy the relevant log lines from that terminal
stop it with Ctrl+C
start your normal service again:

pnpm openclaw gateway start

or

openclaw gateway start

A couple notes:

#

--cli-backend-logs is for gateway run, not the background service start path
it makes the terminal show the CLI backend logs, including stdout/stderr
also please paste openclaw --version with the logs

I’d specifically watch for lines like:

cli session reset: provider=claude-cli reason=...
CLI session expired, clearing from session store...
No conversation found with session ID ...

Docs: https://docs.openclaw.ai/cli/gateway

If you want, paste the output here after one repro and I’ll help read it.

quartz compass Apr 21, 2026, 10:44 PM

#

Is there a way to do this while the gateway is already running? I don't want to have to stop the gateway and restart it..

toxic stoneBOT Apr 21, 2026, 10:45 PM

#

Not as a hot toggle, no.

--cli-backend-logs is only applied when the Gateway process starts. In code it sets OPENCLAW_CLI_BACKEND_LOG_OUTPUT=1 for that process and changes the console filter, so an already-running gateway will not pick it up.

What you can do without restarting:

tail the running gateway logs:

openclaw gateway call logs.tail --params '{"sinceMs": 600000}'

or, if you run it as a systemd user service:

journalctl --user -u openclaw-gateway.service -f

That may still show useful lines like:

#

cli session reset: provider=claude-cli reason=...
CLI session expired, clearing from session store...

What you will not get without a restart is the extra raw Claude CLI stdout/stderr dump that --cli-backend-logs enables.

So the honest answer is:

basic gateway logs: yes, you can inspect those live right now
full CLI backend stdout/stderr logging: no, that currently needs the gateway started with the flag (or env var) from the beginning

If you want, I can help you do the “no restart” path first and tell you exactly what log lines to look for.

quartz compass Apr 21, 2026, 10:58 PM

#

This is what came back:
aiuser@X-iMac ~ % journalctl --user -u openclaw-gateway.service -f
zsh: command not found: journalctl
aiuser@X-iMac ~ % openclaw gateway call logs.tail --params '{"sinceMs": 600000}'
Gateway call failed: GatewayClientRequestError: invalid logs.tail params: at root: unexpected property 'sinceMs'

toxic stoneBOT Apr 21, 2026, 11:00 PM

#

Yep, that’s on me. Two corrections:

journalctl is Linux/systemd only, so it won’t exist on macOS.
The logs.tail example I gave was wrong for current code. The RPC takes cursor, limit, and maxBytes, not sinceMs.

On macOS, try one of these while the gateway stays running:

Easiest

openclaw logs --follow

If you want the raw launchd log file directly

tail -f /tmp/openclaw/openclaw-gateway.log

#

Low-level RPC version

openclaw gateway call logs.tail --params '{"limit":200,"maxBytes":250000}'

If openclaw logs --follow works, that’s the nicest path.

Also, please paste:

openclaw --version

I should have asked that earlier, and the docs/code mismatch here makes the version especially relevant.

When you tail the logs, watch for:

#

cli session reset: provider=claude-cli reason=...
CLI session expired, clearing from session store...
No conversation found with session ID ...

If you paste what openclaw logs --follow shows during one reset, I can help interpret it.

quartz compass Apr 22, 2026, 2:16 AM

#

02:05:07+00:00 info agent/cli-backend {"subsystem":"agent/cli-backend"} cli exec: provider=claude-cli model=sonnet promptChars=1034
02:05:09+00:00 warn model-fallback/decision {"subsystem":"model-fallback/decision"} {"event":"model_fallback_decision","tags":["error_handling","model_fallback","candidate_failed"],"runId":"fc48945f-bf07-481d-bf19-c472d07c859c","decision":"candidate_failed","requestedProvider":"claude-cli","requestedModel":"claude-sonnet-4-6","candidateProvider":"claude-cli","candidateModel":"claude-sonnet-4-6","attempt":1,"total":10,"reason":"billing","status":402,"errorPreview":"You're out of extra usage · resets 11pm (America/New_York)","errorHash":"sha256:9f33328f03be","nextCandidateProvider":"openai-codex","nextCandidateModel":"gpt-5.4","isPrimary":true,"requestedModelMatched":true,"fallbackConfigured":true} model fallback decision

toxic stoneBOT Apr 22, 2026, 2:17 AM

#

This log is actually pretty informative.

It does not show compaction or a Claude session reset.

It shows:

OpenClaw launched claude-cli
Claude failed almost immediately with a 402 billing/usage error
OpenClaw then chose the next fallback candidate

The key part is:

reason":"billing","status":402
errorPreview":"You're out of extra usage · resets 11pm (America/New_York)"
nextCandidateProvider":"openai-codex"

So for this run, the problem was Claude CLI ran out of extra usage, not “summary compaction failed”.

#

Why that matters:

once OpenClaw falls from claude-cli to another provider/backend, you are no longer in Claude’s opaque server-side session
any context that existed only inside Claude’s hidden summary/compaction state is gone to the fallback model
that can absolutely look like a blank slate or partial amnesia

So this specific snippet points to:

Anthropic usage exhaustion
provider fallback
possible context discontinuity because the fallback provider cannot inherit Claude’s internal summarized session state

What I’d do next:

paste openclaw --version
if possible, capture logs from a case where the reset happens without a billing / session_expired / cli session reset line
for one clean repro, temporarily disable cross-provider fallback, so we can tell whether the blank slate is:

#

Claude-side compaction/resume weirdness, or
- just fallback to a different backend

So, bluntly, this sample is not the compaction bug. It’s a 402 fallback event.

quartz compass Apr 22, 2026, 2:19 AM

#

Correct, but this is the case where theres no context with the new model after the fallback.

OpenClaw 2026.4.15 (041266a)

toxic stoneBOT Apr 22, 2026, 2:21 AM

#

Yep, that lines up with what the code suggests.

When claude-cli hits a 402 and OpenClaw falls to another provider, the new model does not inherit Claude’s private server-side session state or hidden compaction summary.

It only gets what OpenClaw has locally, basically the persisted visible transcript from prior successful turns.

So if the important context was mostly living inside Claude’s opaque summarized state, the fallback model can feel like it has little or no context. That is a real limitation of cross-provider fallback from claude-cli.

So there are really two buckets here:

Expected limitation
- Claude CLI fails
- OpenClaw falls to another provider
- the new provider cannot see Claude’s hidden compacted memory
Possible bug
- the fallback model also loses the visible prior thread history that OpenClaw should have locally

#

If you mean case #2, that’s bug territory.

My recommendation:

for debugging, disable cross-provider fallbacks on this thread/session and reproduce again
if you want continuity, don’t rely on a fallback model inheriting Claude CLI’s internal summary
if the fallback model is missing even obvious prior visible turns, please file an issue with:
- OpenClaw 2026.4.15 (041266a)
- the 402 billing fallback log
- whether the session had prior successful assistant turns
- whether the fallback remembered the immediately previous visible message

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

So, bluntly, “no context after fallback” from claude-cli is at least partly expected, because Claude’s compacted server-side memory is not portable across providers.

quartz compass Apr 22, 2026, 2:27 AM

#

To the new model the conversation just started with the first message I sent after the fallback (no compaction, no summary). Is there NO transcript or record kept of the conversation in openclaw?

toxic stoneBOT Apr 22, 2026, 2:28 AM

#

Yes, OpenClaw does keep a local record.

Based on current code, there are two separate things:

Claude CLI session state
- opaque, server-side / Claude-owned
- includes the hidden compaction summary
- not portable to another provider
OpenClaw local transcript
- visible user + assistant turns
- persisted locally for the OpenClaw session
- this is the only history a fallback model can reuse

So the answer is not “OpenClaw keeps nothing”.

What should happen is:

#

prior successful claude-cli turns get written into the local OpenClaw transcript
if Claude later fails and OpenClaw falls back, the new model should at least have that visible prior history

What you’re describing:

“the new model acts like the conversation started with the first post-fallback message”

That sounds worse than the expected limitation. That sounds like either:

the fallback attempt did not get the local transcript,
the run happened under a different session/session file,
or 2026.4.15 has a bug in this fallback handoff path.

So, bluntly, if it lost all visible prior turns, I would treat that as a bug, not just “Claude summary isn’t portable”.

If you want, I can help you turn this into a tight bug report. The useful ingredients would be:

#

OpenClaw 2026.4.15 (041266a)
the 402 billing fallback log
confirmation that there were earlier successful Claude turns in the same thread
confirmation that the fallback model saw only the first post-fallback message

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

quartz compass Apr 22, 2026, 2:35 AM

#

That's fine, but for now, how do I give the agent the history context?

toxic stoneBOT Apr 22, 2026, 2:36 AM

#

For now, the reliable answer is: externalize the context instead of trusting Claude’s hidden session state.

Best options:

Paste a short recap when fallback happens
- goals
- decisions made
- current TODOs
- important names / IDs / constraints
Keep a state file in the workspace
- something like SESSION_STATE.md or notes.md
- put the running summary there
- tell the agent to read that file
Put critical facts in memory / normal project files
- architecture decisions

#

assumptions
- current plan
- anything you cannot afford to lose

My recommendation is #2.
A tiny rolling file works way better than relying on provider-internal summaries.

Example shape:

# Session state

## Goal
...

## Decisions made

#

- ...
- ...

## Current task
...

## Important context
- ...
- ...

## Next steps
- ...

Then when the fallback model takes over, say something like:

#

Read SESSION_STATE.md first, then continue.

The important bit is: files are portable across providers, Claude’s hidden compacted summary is not.

Docs if you want to lean into memory more: https://docs.openclaw.ai/concepts/memory

If you want, I can help you sketch a really small “fallback-safe context file” template for your setup.

quartz compass Apr 22, 2026, 2:38 AM

#

Ok that'll solve the issue in the future, but what about now? Is all that context gone?

toxic stoneBOT Apr 22, 2026, 2:39 AM

#

Not necessarily.

For the 402 fallback case, your log showed billing fallback, not session_expired or cli session reset, which is actually a good sign.

So right now there are 3 buckets:

Claude’s original session
- may still be intact
- the fallback model could not see it
- when Claude is usable again, that same Claude session may still remember
OpenClaw’s local visible transcript
- should still exist for prior successful visible turns
- that part is usually recoverable
Claude’s hidden compacted summary
- OpenClaw cannot extract/export that

#

if that is the only place some context lived, that part may be effectively gone

So the answer is:

not all context is necessarily gone
but the non-portable hidden Claude summary may be

In your specific case, since the log showed 402 billing fallback and not a session-expired/reset event, I would assume:

the fallback model lost access to the context
the original Claude session may still have it later

So I’d phrase it like this:

“Gone for the fallback model” does not always mean “gone from the original Claude session”.

If you want the safest immediate recovery path, reconstruct from:

#

OpenClaw’s local transcript of visible turns
Claude’s local project JSONL
or a manual recap

If you want, I can help you figure out which of those is most likely to still have the useful bits on your machine.

quartz compass Apr 22, 2026, 2:42 AM

#

Yes

toxic stoneBOT Apr 22, 2026, 2:43 AM

#

Then I’d check these, in this order:

1. Claude’s local session files

Most likely place if the original Claude session still has the good context.

ls -lt ~/.claude/projects/*/*.jsonl | head

Then search for a unique phrase from earlier in the convo:

rg -n "some unique phrase from earlier" ~/.claude/projects/*/*.jsonl

2. OpenClaw’s local transcripts

OpenClaw stores session transcripts under:

#

~/.openclaw/agents/<agentId>/sessions/

Quick way to look for recent ones:

ls -lt ~/.openclaw/agents/*/sessions/*.jsonl | head

Search them too:

rg -n "some unique phrase from earlier" ~/.openclaw/agents/*/sessions/*.jsonl

3. If Claude usage resets later

#

Try the same thread/session with Claude again. Since your log showed 402 billing fallback, not session_expired, the original Claude session may still be there.

What the results mean

found in ~/.claude/projects/...
Claude still has local record, good sign.
found in ~/.openclaw/agents/*/sessions/...
OpenClaw kept the visible transcript.
found in neither
then the missing context was probably only in Claude’s hidden compacted state, which is the bad case.

If you want, paste the output of the two ls -lt ... | head commands and I can help you narrow down the right file.

quartz compass Apr 22, 2026, 2:51 AM

#

I can see the running file in ~/.openclaw/agents/*/sessions/...

toxic stoneBOT Apr 22, 2026, 2:52 AM

#

Nice, that’s actually the key result.

If the running transcript file is there, then OpenClaw did keep the visible history. So the problem is not “no transcript exists”, it’s that the fallback model is not getting that history the way you’d expect.

So right now:

your visible history is probably not gone
Claude’s hidden compacted summary may still be non-portable
but the OpenClaw transcript itself exists, which is good news

What I’d do next:

Open that .jsonl file
confirm the earlier turns are in there
use that transcript to make a short recap for the current model

If you want a quick readable dump and you have jq:

#

jq -r 'select(.type=="message") | .message.role + ": " + ([.message.content[]? | select(.type=="text") | .text] | join(""))' ~/.openclaw/agents/*/sessions/<that-file>.jsonl

If that shows the prior conversation, then we’ve basically proven:

OpenClaw has the transcript
the fallback handoff is the weak spot

At that point the practical recovery is:

summarize the relevant prior turns from that file
paste the recap to the current model
or drop it into SESSION_STATE.md and tell the agent to read it

If you want, paste a few sanitized lines from that transcript and I can help you turn it into a clean recap fast.

quartz compass Apr 22, 2026, 2:54 AM

#

Is there no copy/version of this transcript kept in /.openclaw?

toxic stoneBOT Apr 22, 2026, 2:55 AM

#

Yes, that is the copy in ~/.openclaw.

OpenClaw keeps session data there, typically as:

~/.openclaw/agents/<agentId>/sessions/sessions.json
session metadata, current session id, pointers
~/.openclaw/agents/<agentId>/sessions/<sessionId>.jsonl
the actual local transcript

So the .jsonl file you found under:

~/.openclaw/agents/*/sessions/

is the OpenClaw-kept transcript copy.

#

The important distinction is:

yes, OpenClaw keeps the visible transcript in ~/.openclaw
no, it does not keep Claude’s hidden server-side compaction summary there

So if you can see the earlier turns in that .jsonl, the local record exists. The gap is in how that history is being handed off to the fallback model, not in whether OpenClaw stored it.

quartz compass Apr 22, 2026, 2:56 AM

#

No, i found the session file in ~/.claude/projects//.jsonl

toxic stoneBOT Apr 22, 2026, 2:57 AM

#

Ah, got it, thanks, that changes the read a bit.

~/.claude/projects/*/*.jsonl is the Claude-side local session file, not OpenClaw’s.

OpenClaw’s own local transcript should be under:

~/.openclaw/agents/<agentId>/sessions/

So I’d check these next:

ls -lt ~/.openclaw/agents/*/sessions/*.jsonl | head

and search for a phrase you know is in the conversation:

#

rg -n "some unique earlier phrase" ~/.openclaw/agents/*/sessions/*.jsonl

Interpretation:

found in ~/.claude/projects/... only
Claude has the history locally, but OpenClaw may not have mirrored it into its own transcript the way we’d expect
found in both places
OpenClaw has the transcript too, then the problem is more clearly fallback handoff
found only in ~/.openclaw/...
OpenClaw has the visible history, Claude local file is less relevant

So yes, the file you found is useful, but it is not yet proof that OpenClaw kept its own copy.

#

If you want, paste the output of the ls -lt ~/.openclaw/agents/*/sessions/*.jsonl | head command and I’ll help read it.

quartz compass Apr 22, 2026, 3:02 AM

#

I'm only seeing that session in /.claude. in /.openclaw I'm only seeing the new truncated session and the older sessions..

toxic stoneBOT Apr 22, 2026, 3:04 AM

#

Yep, that’s the smoking gun.

What you’re seeing means:

Claude kept the fuller thread in ~/.claude/projects/...
OpenClaw only has the newer truncated current session in ~/.openclaw/...

So for the fallback model, the earlier context is effectively gone from OpenClaw’s point of view, even though it still exists on disk in Claude’s local session file.

That explains the behavior cleanly:

fallback model reads OpenClaw’s current session state
OpenClaw’s current session is already truncated/new
the richer Claude-side history is not being imported/replayed into that fallback path

So the short answer is:

#

not gone from disk
gone from the current OpenClaw session context

Right now, the practical recovery is:

use the fuller ~/.claude/projects/... transcript
make a recap
paste it into the current session, or put it in a file like SESSION_STATE.md

And honestly, this is strong bug-report material now. You’ve got a very clean repro/evidence set:

OpenClaw 2026.4.15 (041266a)
Claude fuller transcript exists in ~/.claude/projects/...
OpenClaw only has truncated/new current session in ~/.openclaw/...
after fallback, new model only sees post-fallback context

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

#

If you want, I can help you write the issue in 5 bullet points so you can just paste it.

quartz compass Apr 22, 2026, 3:06 AM

#

The weird thing is that the existing fallback session is still writing to that same session file /.claude also. And according to the model and /status, the current model is still showing as claude-cli/sonnet*.

toxic stoneBOT Apr 22, 2026, 3:07 AM

#

That actually makes sense, weirdly enough.

The most likely explanation is:

the 402 fallback was per-turn, not a permanent session migration
so one run temporarily failed off Claude
but the overall thread/session then continued using the same Claude session again afterward

That would explain all three things at once:

same ~/.claude/... file keeps growing
because later turns are still hitting the same Claude session
/status still shows claude-cli/sonnet*
because the session is still basically “Claude-backed” overall
one fallback turn had no history

#

because that alternate provider did not inherit Claude’s hidden session state for that specific failed turn

So I would not read this as “the whole session switched to fallback permanently”.
I’d read it as:

“One attempt fell back, but the session later stayed / returned to Claude.”

That’s also why the behavior feels inconsistent. The session-level reality is “still Claude”, but the one failed turn had a temporary detour where context handoff was poor.

So the current picture is probably:

Claude session still alive
fallback happened on one or more individual turns
handoff on those fallback turns is the broken bit

If you want to pin it down fully, the next useful thing would be:

#

logs around the exact “blank” turn
plus the next successful turn after it

That would let us tell whether it was:

one-turn fallback only
or a real session reset/rebind

At this point I’m pretty convinced the issue is turn-level fallback continuity, not “Claude session fully vanished”.

quartz compass Apr 22, 2026, 3:09 AM

#

Probably, my session limit on claude just reset too. Do you want to help me write the bug report then continue to see if it works again?

toxic stoneBOT Apr 22, 2026, 3:10 AM

#

Yep. I can help draft it. I can’t file it for you, but this should be paste-ready:

Title
claude-cli fallback turn loses prior session context even though Claude session file still has full history

Body

### Version
OpenClaw 2026.4.15 (041266a)

### Summary
When using `claude-cli/claude-sonnet-4-6`, a turn that falls back away from Claude can lose all prior context for the fallback model, even though the original Claude local session file still contains the fuller history and later Claude turns continue writing to that same file.

This makes the fallback turn behave as if the conversation just started with the first post-fallback message.

### What I observed

#

- Long-running `claude-cli` session with Sonnet
- Claude appears to do server-side compaction/summarization silently at times
- Sometimes important context is lost after compaction
- In the specific failure case below, Claude hit a usage/billing limit and OpenClaw fell back for that turn
- The fallback model appeared to have **no prior context at all**
- However:
  - the Claude local session file under `~/.claude/projects/*/*.jsonl` still had the fuller history
  - later turns continued writing to that same Claude session file
  - `/status` still showed `claude-cli/sonnet*`

### Relevant log
```text
02:05:07+00:00 info agent/cli-backend {"subsystem":"agent/cli-backend"} cli exec: provider=claude-cli model=sonnet promptChars=1034
02:05:09+00:00 warn model-fallback/decision {"subsystem":"model-fallback/decision"} {"event":"model_fallback_decision","tags":["error_handling","model_fallback","candidate_failed"],"runId":"fc48945f-bf07-481d-bf19-c472d07c859c","decision":"candidate_failed","requestedProvider":"claude-cli","requestedModel":"claude-sonnet-4-6","candidateProvider":"claude-cli","candidateModel":"claude-sonnet-4-6","attempt":1,"total":10,"reason":"billing","status":402,"errorPreview":"You're out of extra usage · resets 11pm (America/New_York)","errorHash":"sha256:9f33328f03be","nextCandidateProvider":"openai-codex","nextCandidateModel":"gpt-5.4","isPrimary":true,"requestedModelMatched":true,"fallbackConfigured":true} model fallback decision

#


### Session file observations
- `~/.claude/projects/*/*.jsonl` contains the fuller current Claude session history
- `~/.openclaw/agents/*/sessions/` only shows the newer truncated current session plus older sessions
- The fallback model behaved as if only the first post-fallback message existed

### Expected
If a single turn falls back away from `claude-cli`, the fallback model should at least receive the visible OpenClaw transcript/session history for that thread, rather than behaving like the conversation just started.

### Actual
The fallback turn appears to have no prior context, even though the fuller Claude-side session history still exists locally and the overall session later continues on Claude.

### Notes
This looks like a turn-level fallback continuity issue rather than the original Claude session being fully lost.

#

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

Then, for the live test now that your Claude usage reset:

keep the same thread/session
ask Claude to summarize the conversation from before the fallback
if it remembers, that supports “Claude session intact, fallback handoff broken”
keep openclaw logs --follow running while you test

If you want, paste the issue text back after you tweak it and I’ll sanity-check it fast.

quartz compass Apr 22, 2026, 4:14 AM

#

04:12:20+00:00 info agent/cli-backend {"subsystem":"agent/cli-backend"} cli exec: provider=claude-cli model=sonnet promptChars=941
04:12:26+00:00 info gateway/ws {"subsystem":"gateway/ws"} ⇄ res ✓ node.list 166ms conn=f01e8b9e…cfc0 id=59218c67…b851
04:12:35+00:00 info gateway/ws {"subsystem":"gateway/ws"} ⇄ res ✓ sessions.list 51ms conn=f01e8b9e…cfc0 id=255624fc…195d
04:12:41+00:00 info web-heartbeat {"module":"web-heartbeat","runId":"b7c76d3d-8a33-4e8e-8782-d4a63234467f"} {"connectionId":"0a37b8b7-8c28-4f16-bd90-cc2ed791e839","reconnectAttempts":1,"messagesHandled":0,"lastInboundAt":null,"authAgeMs":239213.05908203125,"uptimeMs":840043} web gateway heartbeat
04:13:17+00:00 info agent/cli-backend {"subsystem":"agent/cli-backend"} cli exec: provider=claude-cli model=sonnet promptChars=970
04:13:31+00:00 info gateway/ws {"subsystem":"gateway/ws"} ⇄ res ✓ sessions.list 66ms conn=f01e8b9e…cfc0 id=257ea5bd…d3af
04:13:41+00:00 info web-heartbeat {"module":"web-heartbeat","runId":"b7c76d3d-8a33-4e8e-8782-d4a63234467f"} {"connectionId":"0a37b8b7-8c28-4f16-bd90-cc2ed791e839","reconnectAttempts":1,"messagesHandled":0,"lastInboundAt":null,"authAgeMs":299214.05908203125,"uptimeMs":900045} web gateway heartbeat

#

Response back after requesting summary is as expected, with full context.

toxic stoneBOT Apr 22, 2026, 4:15 AM

#

These logs look clean.

What I see:

both turns went straight to claude-cli
no billing / 402
no session_expired
no cli session reset
no fallback decision at all

So this is basically:

Claude is working normally again for these turns.

That’s good, and it strengthens the earlier theory:

the underlying Claude session likely survived

#

the bad behavior was on the temporary fallback turn(s)

If the model now remembers the earlier context again, that’s a pretty strong signal that the bug is:

turn-level fallback continuity is broken, while the original Claude session remains intact

That’s worth adding to the issue, actually. I’d append something like:

### Additional observation
After the Claude usage window reset, subsequent turns again ran normally on `claude-cli/sonnet` with no fallback/session reset in logs. This suggests the original Claude session itself remained alive, and the context loss was specific to the fallback turn/handoff rather than the Claude session being destroyed.

So the big question now is:

Does Claude remember the pre-fallback context again?

#

If yes, I’d consider that very strong evidence for the bug report.

#

Perfect, that’s the confirmation.

So the evidence now points pretty strongly to:

Claude session stayed intact
Claude-side full context survived
the broken part is the fallback turn continuity / handoff

In other words, this is not “Claude lost the session”, it’s:

“When a claude-cli turn falls back, the fallback model does not inherit the effective conversation context that Claude still has.”

I’d add this final note to the issue:

### Confirmed follow-up

#

After the Claude usage window reset, I asked the same Claude session for a summary and it returned the full expected context. This confirms the original Claude session/history was still intact. The context loss appears specific to the fallback turn/handoff, not to the Claude session being destroyed.

Until it’s fixed, the practical workaround is still:

avoid cross-provider fallback for important claude-cli threads, or
keep a small portable context file / recap

Glad we pinned it down. 🎯
If this helped, please right-click the solution message → Apps → ✅ Mark Solution so Answer Overflow can index it for the next person.

quartz compass Apr 22, 2026, 4:20 AM

#

Works for now but how do I preserve this session transcript within openclaw? Will openclaw at some point keep a local copy (in /.openclaw)?

toxic stoneBOT Apr 22, 2026, 4:21 AM

#

Short version:

In principle, yes, OpenClaw is already supposed to keep local session transcripts under ~/.openclaw/agents/<agentId>/sessions/*.jsonl
In your case, no, I would not trust that to fully preserve the effective Claude session state today
and no, there is not currently a clean built-in “import/sync this ~/.claude session into ~/.openclaw” path that I’d point you to

So I’d treat it like this:

What OpenClaw does today

keeps its own visible transcript in ~/.openclaw
does not keep Claude’s hidden compacted/server-side summary
and in this edge case, it seems not to be mirroring the full useful Claude session context faithfully enough

What I would rely on today

For an important claude-cli session, the safest source of truth is still:

the Claude session file in ~/.claude/projects/...

#

plus a small manual recap / context note for portability

Will OpenClaw keep a better local copy later?

I’d hope so, and this bug report is exactly the kind of thing that should push it that way, but I would not rely on that behavior until the bug is fixed.

So the honest answer is:

OpenClaw already keeps a local copy, but not a trustworthy copy of the full effective Claude session context in this scenario.

If you want, I can help you write a tiny ongoing “portable session state” template so future fallback turns don’t depend on this bug getting fixed first.

quartz compass Apr 22, 2026, 4:26 AM

#

What was the other fix/workaround you suggested earlier?

toxic stoneBOT Apr 22, 2026, 4:26 AM

#

The other workaround was:

avoid cross-provider fallback for important claude-cli threads

So, if continuity matters more than “always get some reply”, don’t let that thread jump from claude-cli to another provider mid-turn.

In practice the two workarounds were:

Disable / avoid cross-provider fallback for that session/thread
so it stays on Claude instead of handing off badly
Keep a portable context note / recap
so if a fallback does happen, you can re-inject the important state

So the short version is:

best continuity: stay on Claude, no cross-provider fallback

#

best resilience: keep a small session-state file / recap

If you want, I can help you phrase the fallback config change carefully for the bug report / workaround note.

quartz compass Apr 22, 2026, 4:29 AM

#

Disable / avoid cross-provider fallback doesn't work in this case, since session limit was maxed, any other existing provider fallback will continue to fail.

How do I "Keep a portable context note / recap"?

toxic stoneBOT Apr 22, 2026, 4:30 AM

#

Yep, fair point. If Claude is maxed, “just stay on Claude” is not a real workaround 😅

For the portable context note / recap, the idea is:

Keep one tiny plain-text summary outside the model

A single Markdown note is enough. Something like:

SESSION_STATE.md

# Session state

## Goal
What I’m trying to do right now.

## Current status

#

What already works, what broke, what changed.

## Important context
Facts the next model must know.
- ...
- ...
- ...

## Decisions made
- We chose X because Y.
- We ruled out Z.

## Important identifiers / paths
- session key:
- file paths:

#

- error strings:
- ticket / issue links:

## Next step
Exactly what should happen next.

How to use it

update it after major turns / milestones
especially update it before you think you might hit limits or switch models
keep it short, just the durable stuff
when the next model takes over, say:
- “Read SESSION_STATE.md first, then continue.”

What goes in it

Put in:

#

goal
current state
decisions
constraints
important IDs / file paths / errors
next step

Do not try to dump the whole chat into it.
Think “handoff note”, not “full transcript”.

Fastest practical version

If you don’t want a file, even this works:

Goal:
Current state:

#

Important facts:
Next step:

So the workflow is basically:

keep a tiny handoff note
refresh it occasionally
point the next model at it

That makes your context portable across providers, instead of trapped inside Claude’s hidden session state.

If you want, I can give you a super-short version optimized specifically for debugging / coding sessions.

quartz compass Apr 22, 2026, 4:31 AM

#

How would I tell the agent to keep it updated? Where should the file sit?

#Claude-CLI Context Reset

Easiest

If you want the raw launchd log file directly

Low-level RPC version

1. Claude’s local session files

2. OpenClaw’s local transcripts

3. If Claude usage resets later

What the results mean

What OpenClaw does today

What I would rely on today

Will OpenClaw keep a better local copy later?

Keep one tiny plain-text summary outside the model

How to use it

What goes in it

Fastest practical version