Issue Station
Sign In
Tools hereToolbox

openclaw - 💡(How to fix) Fix Control UI webchat loses all chat history on page reload — no history hydration [1 comments, 2 participants]

Official PRs (…)
ON THIS PAGE

Recommended Tools

×6

Utilities matched from this issue’s tags and category — try them while you read without losing context.

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

Helpful · Quick feedback

Loading…
GitHub stats
openclaw/openclaw#68795•Fetched 2026-04-19 15:07:21
View on GitHub
Comments
1
Participants
2
Timeline
1
Reactions
0
Author
alexprime1889-progalexprime1889-prog
Participants
alexprime1889-progalexprime1889-proggongli0929gongli0929
Timeline (top)
commented ×1

Reloading the Control UI webchat page (/chat?session=<key>) wipes the entire visible conversation. The server-side transcript is intact on disk; the UI simply never asks for it on load.

Root Cause

Reloading the Control UI webchat page (/chat?session=<key>) wipes the entire visible conversation. The server-side transcript is intact on disk; the UI simply never asks for it on load.

Fix Action

Fix / Workaround

Workarounds currently in use

  • Use Telegram/Discord channel — those clients are stateless w.r.t. history and the channel renders prior messages.
  • Avoid reloading the webchat tab.
  • Manually read tail -f ~/.openclaw/agents/main/sessions/<uuid>.jsonl.
RAW_BUFFERClick to expand / collapse

Summary

Reloading the Control UI webchat page (/chat?session=<key>) wipes the entire visible conversation. The server-side transcript is intact on disk; the UI simply never asks for it on load.

Version

  • OpenClaw 2026.4.19-beta.1 (4862d34)
  • Host: macOS 15.x, Node 25.4.0, Chrome 140

Evidence

After location.reload() on http://127.0.0.1:18790/chat?session=agent:main:main, Chrome DevTools Network panel shows 36 requests, all of which are:

  • static assets (/assets/*.js, /assets/*.css)
  • /__openclaw/control-ui-config.json
  • /avatar/main?meta=1, /favicon.svg

Zero requests to any /api/sessions/…, /messages, /history, or /session/*/transcript endpoint.

localStorage on the same origin contains only UI preferences (openclaw.control.settings.v1) and device identity — no messages, history, or transcript keys.

Meanwhile, the server-side session file is healthy and being updated: ~/.openclaw/agents/main/sessions/<uuid>.jsonl grows normally during the conversation.

Expected

On page load (or on WS (re)open), the client should fetch — or receive via the WS handshake — the last N messages for sessionKey, so the user sees the same conversation they had before refresh.

Suggested fix

One of:

  1. REST: GET /api/sessions/<sessionKey>/messages?limit=N&cursor=<...>, consumed by the chat view on mount.
  2. WS handshake: client sends {type: "resume", sessionKey, sinceCursor?} on open, server streams back the tail of the transcript.

Impact

For local/web users this makes webchat effectively single-session-per-tab-lifetime. Any accidental refresh, crash, or tab restore loses all visible context. (Backend data is preserved, so it's purely a UI-layer regression/miss.)

Workarounds currently in use

  • Use Telegram/Discord channel — those clients are stateless w.r.t. history and the channel renders prior messages.
  • Avoid reloading the webchat tab.
  • Manually read tail -f ~/.openclaw/agents/main/sessions/<uuid>.jsonl.

extent analysis

TL;DR

The most likely fix involves implementing a mechanism for the client to fetch or receive the last N messages for a session on page load or WebSocket handshake, such as sending a GET /api/sessions/<sessionKey>/messages?limit=N&cursor=<...> request or including a {type: "resume", sessionKey, sinceCursor?} message in the WebSocket handshake.

Guidance

  • Verify that the client is not making any requests to fetch session messages on page load by checking the Network panel in Chrome DevTools for requests to /api/sessions/…, /messages, /history, or /session/*/transcript endpoints.
  • Consider implementing one of the suggested fixes, such as sending a GET /api/sessions/<sessionKey>/messages?limit=N&cursor=<...> request on mount or including a {type: "resume", sessionKey, sinceCursor?} message in the WebSocket handshake.
  • Check the localStorage for any relevant data that could be used to resume the conversation, although currently, it only contains UI preferences and device identity.
  • Test the implementation by reloading the page and verifying that the conversation history is preserved.

Example

// Example of sending a GET request to fetch session messages on mount
fetch(`/api/sessions/${sessionKey}/messages?limit=N&cursor=${cursor}`)
  .then(response => response.json())
  .then(messages => {
    // Update the chat view with the fetched messages
  });

Notes

The provided information suggests that the issue is specific to the webchat UI and does not affect other channels like Telegram or Discord. The server-side session data is intact, and the issue is purely a UI-layer regression.

Recommendation

Apply a workaround by implementing one of the suggested fixes, such as sending a GET /api/sessions/<sessionKey>/messages?limit=N&cursor=<...> request or including a {type: "resume", sessionKey, sinceCursor?} message in the WebSocket handshake, as this will allow the client to fetch or receive the last N messages for a session on page load or WebSocket handshake.

Vote matrix · Quick signals

Works
Did the solution work? Tap to confirm.
Easy Fix
Was it a quick fix?
Time Saver
Did it save you time?
Blocking
Was it severely blocking?
Common Issue
Are others likely hitting this too?
Flaky / Intermittent
Is it intermittent?
Verified / Reproducible
Can you reproduce it reliably?
Loading…
#api#tool integration#LLM response#prompt template#agent execution

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

Back to top recommendations

TRENDING

openclaw - 💡(How to fix) Fix Control UI webchat loses all chat history on page reload — no history hydration [1 comments, 2 participants]