Bug type

Behavior bug (incorrect output/state without crash)

Beta release blocker

No

Summary

WebChat can show stale or missing conversation history after a browser refresh when the most recent transcript records are dominated by internal tool calls/tool results/NO_REPLY events rather than user-visible chat messages.

Steps to reproduce

1. Use a WebChat direct session on OpenClaw 2026.5.12.
2. Run a long agent task that emits many tool calls/tool results and/or scheduled heartbeat/internal-event turns into the same session transcript.
3. Refresh the OpenClaw Control UI/WebChat page for that session.
4. Observe that the visible chat history loses earlier human-visible conversation context or shows stale/misleading session preview text.

Expected behavior

Refreshing WebChat should restore the recent human-visible conversation, even if the transcript tail contains many internal tool-call/tool-result records. Session preview/title data should also reflect recent visible user/assistant messages instead of stale internal/silent records.

Actual behavior

The session transcript on disk still contains the earlier conversation, but the refreshed WebChat view can appear to lose pieces of history. In the observed session, session list metadata showed a stale derived title from the first VPN message and lastMessagePreview: "NO_REPLY", despite later user messages. The recent transcript tail was dominated by internal tool traffic, so the default recent-history window contained very few user-visible records after client-side filtering.

OpenClaw version

OpenClaw 2026.5.12 (f066dd2)

Operating system

Ubuntu 26.04 LTS 7.0.0-15-generic (x86_64)

Install method

npm global

Model

openai/gpt-5.5

Provider / routing chain

OpenClaw -> OpenAI Responses API

Additional provider/model setup details

Main WebChat session for agent lily; session metadata reported model gpt-5.5.

Logs, screenshots, and evidence

# Session list metadata from the affected session:
key: agent:lily:main
channel: webchat
derivedTitle: "[Sun 2026-05-17 04:01 EDT] ya it's essential a free vpn,…"
lastMessagePreview: "NO_REPLY"
transcriptPath: /home/claude/.openclaw/agents/lily/sessions/389acebf-6aec-4b5f-943a-f12624b10c07.jsonl

# Transcript size/shape:
lines=5159
bytes=9433755
max_line=468
max_len=29084

# Tail-window analysis of the transcript using a client-like visible-message filter:
last 30: visible=3, toolish=26
last 50: visible=3, toolish=46
last 100: visible=5, toolish=94
last 200: visible=29, toolish=170

# Relevant implementation observations from installed 2026.5.12 dist:
# - Control UI WebChat requests chat.history with limit: 100 and maxChars: 4000.
# - The frontend filters tool calls/tool results/silent replies client-side.
# - chat.history reads a bounded transcript tail and returns the latest records before the client filter.
# - Session preview/title code scans only bounded tail windows:
# readLastMessagePreviewFromOpenTranscript: last 16 KiB / 20 lines
# readSessionPreviewItemsFromTranscript: fixed read sizes and last 200 lines

Impact and severity

Affected: WebChat/Control UI users with long-running tool-heavy sessions or sessions receiving heartbeat/internal events.

Severity: Medium to high. The transcript is not deleted, but the UI can make conversation context appear lost across refreshes, which undermines trust and makes it hard to continue ongoing work.

Frequency: Observed in one active WebChat session after a long tool-heavy workflow; likely reproducible whenever the recent transcript window is mostly internal records.

Consequence: Users may believe conversation history was lost, may lose visible context needed to continue a task, and session list previews can point at stale or silent messages.

Additional information

I don't get any responses to the questions i ask unless I refresh, and then the question disappears like i never asked it.

I see maybe it's been reported already - #51549

Current main appears to restore visible conversation history from the gateway via chat.history.
The remaining broken pieces are queued messages and unsent draft text.
chatMessage and chatQueue still initialize from component memory, so a full browser refresh rebuilds them empty.
Queue mutations append/remove entries from the in-memory host.chatQueue; no storage-backed restore path was found.
Draft edits update in-memory state.chatMessage; no sessionStorage/localStorage persistence was found.
Current per-session queue preservation only helps in-app session switching; it uses in-memory chatQueueBySession, so it does not survive F5/tab close.
Source-level evidence from the review pointed at:
ui/src/ui/app.ts for initial chatMessage / chatQueue
ui/src/ui/app-chat.ts for queue enqueue/flush
ui/src/ui/chat/input-history.ts for draft-change handling
ui/src/ui/app-render.helpers.ts for in-memory per-session queue handling
ui/src/ui/controllers/chat.ts for existing history reload
Open questions/risk:
Restored queued messages must not submit too early while an agent run is active.
Attachments need explicit handling if queued messages can include files/media.
Draft/queue retention needs a product/privacy decision: sessionStorage is safer/shorter-lived; localStorage survives browser restarts but leaves prompts on disk longer.
No live browser F5 repro was performed in the bot review; the remaining failure was verified from source behavior.
Short version: history refresh is partly fixed, but queue + draft persistence are still real gaps unless a newer PR landed after that review.