openclaw - 💡(How to fix) Fix [Bug]: Control UI webchat session silently resets after network disconnect / sleep — previous session file renamed to .jsonl.reset.* and lost from sessions tab

Bug type

Behavior bug (incorrect output/state without crash)

Beta release blocker

No

Summary

When the host machine (MacBook Pro - Nov 2023 - Chip Apple M3 Max - MacOS Sequoia v15.7.1) goes to sleep or loses internet connectivity and comes back, the OpenClaw Control UI webchat appears to still show the ongoing conversation — but when I type a new message, the session silently resets. All previous messages disappear, the old .jsonl session file is renamed to {id}.jsonl.reset.{timestamp}, and the previous session is no longer visible in the sessions tab. I did not reload, navigate, or deliberately start a new session. Note: I am running the OpenClaw Gateway in Docker and access the Control UI via localhost from Chrome.

Steps to reproduce

1. Run the OpenClaw gateway using docker on my Mac

git clone https://github.com/openclaw/openclaw
cd openclaw
git checkout 01dda73e9bb1ecb787e2762612fc3bb586d731a0
./scripts/docker/setup.sh

1. Open the Control UI webchat on localhost using the Chrome browser

2. Exchange several messages with the agent.

3. Put the Mac to sleep (or disconnect from the internet).

4. After some time, wake the Mac / reconnect.

5. The webchat UI appears to still show the ongoing conversation.

6. Type a new message and send it

7. The UI instantly clears all previous messages as if a fresh session started.

8. Check ~/.openclaw/agents/main/sessions/ — the previous session's .jsonl file has been renamed to {id}.jsonl.reset.{timestamp} but the session is not visible in the UI sessions's tab.

Expected behavior

The session should resume normally after reconnection without data loss. The .jsonl file should remain at its original path and the session should stay visible in the sessions tab.

Actual behavior

The session is silently reset on the next message after a sleep/disconnect cycle. The old session file is renamed to a .jsonl.reset.* suffix, making it invisible to the sessions tab. The data is preserved on disk but cannot be browsed or resumed through the UI.

OpenClaw version

v2026.5.5

Operating system

macOS (host) → Linux (Docker container, arm64)

Install method

Docker (from GitHub repo)

Model

openrouter/deepseek/deepseek-v4-flash

Provider / routing chain

openclaw -> openrouter -> deepseek/deepseek-v4-flash

Additional provider/model setup details

No response

Logs, screenshots, and evidence

Disk contents after the bug manifests for the orphaned session:

Copy
-rw------- 1 node node    244 May 27 18:35 5aa2d7a3-....trajectory-path.json
-rw------- 1 node node   167K May 27 19:58 5aa2d7a3-....jsonl.reset.2026-05-28T14-13-43.760Z
-rw------- 1 node node   958K May 27 19:58 5aa2d7a3-....trajectory.jsonl

The .jsonl.reset.* file contains the full conversation history (valid JSONL with all user/assistant messages). The trajectory files remain untouched. Only the main session log is renamed.

Impact and severity

Affected: Control UI webchat users on any platform that may experience sleep/disconnect cycles (laptops, remote connections, unstable networks) Severity: Medium (workflow interruption — lose access to conversation history via the UI, cannot resume) Frequency: Every sleep/disconnect cycle that's long enough to trigger the reset Consequence: Users lose conversation continuity. Previous sessions disappear from the sessions tab. Data is intact on disk but requires manual file-level recovery.

Additional information

The mechanism appears to be that the webchat re-establishes its WebSocket/SSE connection after waking, but instead of rejoining the existing session, it initialises a fresh one — which triggers the session lifecycle code to rename the previous session file. Key observations:

• A small trajectory-path.json (244 bytes) also appears alongside the existing files after the reset
• The trajectory JSONL logs are not renamed, only the main session .jsonl is
• The user never clicked "new chat", reloaded the page, or navigated away — the UI appeared to still show the old conversation right up until the first new message was typed