Issue Station
Sign In
Tools hereToolbox

openclaw - ✅(Solved) Fix [Bug]: WebChat loses message queue, conversation history, and draft on browser refresh [1 pull requests, 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#51549•Fetched 2026-04-08 01:09:46
View on GitHub
Comments
1
Participants
2
Timeline
9
Reactions
0
Author
ukr-coderukr-coder
Participants
RyceRyceukr-coderukr-coder
Timeline (top)
cross-referenced ×4referenced ×4commented ×1

WebChat UI loses all state on browser refresh (F5): pending message queue, conversation history, and draft text in the input box. This was previously reported in #8331 but auto-closed as stale without a fix. Still reproducible in 2026.3.13.

Root Cause

All three forms of state exist only in React component state (memory). No persistence layer. The gateway already stores the session transcript in .jsonl files, but WebChat does not query it on reconnect.

Fix Action

Fixed

PR fix notes

PR #53651: fix(webchat): restore chat history, queue, and draft on page refresh

Description (problem / solution / changelog)

Fixes #51549 - WebChat loses message queue, conversation history, and draft on browser refresh

  • Add chat tab loading in refreshActiveTab() to load history on reconnect
  • Add persistence functions for chat queue, draft, and attachments
  • Use localStorage for queue persistence (survives refresh)
  • Use sessionStorage for draft and attachments (per-session)
  • Persist queue when adding messages
  • Restore queue, draft, and attachments on refresh

Summary

Describe the problem and fix in 2–5 bullets:

  • Problem:
  • Why it matters:
  • What changed:
  • What did NOT change (scope boundary):

Change Type (select all)

  • Bug fix
  • Feature
  • Refactor required for the fix
  • Docs
  • Security hardening
  • Chore/infra

Scope (select all touched areas)

  • Gateway / orchestration
  • Skills / tool execution
  • Auth / tokens
  • Memory / storage
  • Integrations
  • API / contracts
  • UI / DX
  • CI/CD / infra

Linked Issue/PR

  • Closes #
  • Related #
  • This PR fixes a bug or regression

Root Cause / Regression History (if applicable)

For bug fixes or regressions, explain why this happened, not just what changed. Otherwise write N/A. If the cause is unclear, write Unknown.

  • Root cause:
  • Missing detection / guardrail:
  • Prior context (git blame, prior PR, issue, or refactor if known):
  • Why this regressed now:
  • If unknown, what was ruled out:

Regression Test Plan (if applicable)

For bug fixes or regressions, name the smallest reliable test coverage that should have caught this. Otherwise write N/A.

  • Coverage level that should have caught this:
    • Unit test
    • Seam / integration test
    • End-to-end test
    • Existing coverage already sufficient
  • Target test or file:
  • Scenario the test should lock in:
  • Why this is the smallest reliable guardrail:
  • Existing test that already covers this (if any):
  • If no new test is added, why not:

User-visible / Behavior Changes

List user-visible changes (including defaults/config).
If none, write None.

Security Impact (required)

  • New permissions/capabilities? (Yes/No)
  • Secrets/tokens handling changed? (Yes/No)
  • New/changed network calls? (Yes/No)
  • Command/tool execution surface changed? (Yes/No)
  • Data access scope changed? (Yes/No)
  • If any Yes, explain risk + mitigation:

Repro + Verification

Environment

  • OS:
  • Runtime/container:
  • Model/provider:
  • Integration/channel (if any):
  • Relevant config (redacted):

Steps

Expected

Actual

Evidence

Attach at least one:

  • Failing test/log before + passing after
  • Trace/log snippets
  • Screenshot/recording
  • Perf numbers (if relevant)

Human Verification (required)

What you personally verified (not just CI), and how:

  • Verified scenarios:
  • Edge cases checked:
  • What you did not verify:

Review Conversations

  • I replied to or resolved every bot review conversation I addressed in this PR.
  • I left unresolved only the conversations that still need reviewer or maintainer judgment.

If a bot review conversation is addressed by this PR, resolve that conversation yourself. Do not leave bot review conversation cleanup for maintainers.

Compatibility / Migration

  • Backward compatible? (Yes/No)
  • Config/env changes? (Yes/No)
  • Migration needed? (Yes/No)
  • If yes, exact upgrade steps:

Failure Recovery (if this breaks)

  • How to disable/revert this change quickly:
  • Files/config to restore:
  • Known bad symptoms reviewers should watch for:

Risks and Mitigations

List only real risks for this PR. Add/remove entries as needed. If none, write None.

  • Risk:
    • Mitigation:

Changed files

  • ui/src/ui/app-chat.ts (modified, +33/-0)
  • ui/src/ui/app-render.ts (modified, +12/-3)
  • ui/src/ui/app-settings.ts (modified, +3/-0)
  • ui/src/ui/storage.ts (modified, +142/-0)
RAW_BUFFERClick to expand / collapse

Summary

WebChat UI loses all state on browser refresh (F5): pending message queue, conversation history, and draft text in the input box. This was previously reported in #8331 but auto-closed as stale without a fix. Still reproducible in 2026.3.13.

Environment

  • OpenClaw version: 2026.3.13 (61d171a)
  • OS: Windows 11 (24H2)
  • Channel: webchat
  • Browser: Chrome (latest)

Steps to Reproduce

  1. Open WebChat UI at http://127.0.0.1:18789/
  2. Send a message that triggers a long-running operation (e.g. subagent spawn via sessions_spawn + sessions_yield)
  3. While the agent is processing, type and send 2-3 additional messages → they queue with "X pending" indicator
  4. Press F5 (or close and reopen the tab)

Expected Behavior

  1. Queued messages should persist and be submitted when the agent finishes
  2. Conversation history should be restored from the gateway session transcript
  3. Any unsent draft text in the input box should be preserved

Actual Behavior

  1. Queued messages are lost — user must retype them
  2. Conversation history is gone — blank screen
  3. Draft text is gone

Root Cause

All three forms of state exist only in React component state (memory). No persistence layer. The gateway already stores the session transcript in .jsonl files, but WebChat does not query it on reconnect.

Proposed Fix (expanded from #8331)

1. Queue persistence (original #8331 scope)

  • Store pending messages in localStorage keyed by session ID
  • Key format: oc-webchat-queue-${sessionId}
  • On reconnect, restore the queue and submit when agent is ready
  • TTL: 24h — remove stale entries on load

2. Conversation history persistence

  • On WebChat load/reconnect, query the gateway for recent turns from the active session transcript
  • Render them in the chat area so the user sees conversation context
  • This is the highest-impact improvement — users lose visual context of the entire conversation on any refresh
  • The gateway already has this data; WebChat just doesn't fetch it

3. Draft persistence

  • Store unsent input text in sessionStorage (or localStorage) keyed by session ID
  • Key format: oc-webchat-draft-${sessionId}
  • Standard UX pattern — most chat apps (Slack, Discord, Telegram Web) preserve drafts

4. Reconnect indicator

  • Show a brief toast: "Reconnected — restored X messages" so the user knows state was recovered

Alternative Architecture Consideration

Instead of client-side queue persistence, consider a server-side queue: when WebChat sends a message while the agent is busy, the gateway could accept and queue it server-side. This would make the queue persistent across devices, tabs, and refreshes without any localStorage dependency.

Impact

This affects any user who:

  • Accidentally refreshes during a long operation (subagent spawns can take 1-10 minutes)
  • Has the browser auto-refresh (extensions, dev tools)
  • Closes and reopens the tab
  • Uses multiple tabs (each loses the other's context)

References

  • Original report: #8331 (closed as stale, never fixed)

extent analysis

Fix Plan

To address the issue of WebChat UI losing state on browser refresh, we will implement the following fixes:

  • Queue persistence: Store pending messages in localStorage keyed by session ID.
  • Conversation history persistence: Query the gateway for recent turns from the active session transcript on WebChat load/reconnect.
  • Draft persistence: Store unsent input text in sessionStorage keyed by session ID.
  • Reconnect indicator: Show a brief toast indicating that state was recovered.

Example Code

// Queue persistence
const queueKey = `oc-webchat-queue-${sessionId}`;
const storedQueue = localStorage.getItem(queueKey);
if (storedQueue) {
  const queue = JSON.parse(storedQueue);
  // Restore the queue and submit when agent is ready
  queue.forEach((message) => {
    // Submit the message
  });
  // Remove the stored queue
  localStorage.removeItem(queueKey);
}

// Conversation history persistence
fetch(`https://gateway.example.com/session-transcript/${sessionId}`)
  .then((response) => response.json())
  .then((transcript) => {
    // Render the conversation history
    transcript.forEach((turn) => {
      // Render the turn
    });
  });

// Draft persistence
const draftKey = `oc-webchat-draft-${sessionId}`;
const storedDraft = sessionStorage.getItem(draftKey);
if (storedDraft) {
  // Restore the draft text
  inputBox.value = storedDraft;
  // Remove the stored draft
  sessionStorage.removeItem(draftKey);
}

// Reconnect indicator
toast("Reconnected — restored X messages");

Verification

To verify that the fix worked, follow these steps:

  1. Open WebChat UI and send a message that triggers a long-running operation.
  2. While the agent is processing, type and send additional messages.
  3. Press F5 or close and reopen the tab.
  4. Verify that the queued messages are restored and submitted when the agent is ready.
  5. Verify that the conversation history is restored and rendered in the chat area.
  6. Verify that the draft text is preserved and restored.

Extra Tips

  • Consider implementing a server-side queue to make the queue persistent across devices, tabs, and refreshes.
  • Use a TTL (time to live) to remove stale entries from localStorage and sessionStorage.
  • Test the fixes thoroughly to ensure that they work as expected in different scenarios.

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#ssr#installation#tensor shape#conversation history#request timeout

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 - ✅(Solved) Fix [Bug]: WebChat loses message queue, conversation history, and draft on browser refresh [1 pull requests, 1 comments, 2 participants]