Summary

When pressing F5 (browser refresh) in the WebChat UI, the entire visible conversation and queue state is lost. The chat area resets to empty, and there is no indication of:

• What messages were pending/queued
• What the agent is currently working on
• What tool calls are in progress
• How far along a multi-step operation is

For power users who rely on WebChat as their primary interface, this makes it very difficult to maintain situational awareness of what the agent is doing — especially during long-running operations.

Steps to Reproduce

1. Open WebChat, start a conversation
2. Send a message that triggers a multi-step operation (e.g., spawning sub-agents, running multiple tool calls)
3. Press F5 (or browser refresh)
4. Result: Chat is empty. No history loaded. No queue state visible. No way to know what the agent is doing.
5. Must wait for the agent to finish and respond, with no visibility into progress.

Expected Behavior

After refresh, the UI should:

1. Reconnect to the gateway WebSocket
2. Restore recent conversation history (at minimum the current session's messages)
3. Show current queue state (pending messages, active tool calls)
4. Resume showing streaming output if the agent is mid-response

Current Behavior

• Chat area is completely blank after refresh
• No conversation history is loaded
• No queue or processing state is shown
• The agent continues working server-side, but the user has zero visibility
• When the agent finishes, the response appears — but without the original question/context

Impact

This is particularly painful for:

• Power users who use WebChat as their primary daily interface
• Multi-step operations (sub-agent spawns, file operations, research tasks) where you need to track progress
• Accidental refreshes (F5 muscle memory, browser auto-refresh, network hiccup)
• Mobile browsers that may reload tabs from memory

Enhancement Proposal: Queue Visibility & Session Persistence

Drawing inspiration from how other AI interfaces handle this:

A. Session History Persistence (like Claude.ai, ChatGPT)

Proposal: On WebSocket reconnect, fetch the current session's message history from the gateway (the data exists server-side in sessions store) and render it. This should be the default behavior — users should never see a blank chat after refresh.

B. Queue & Processing State Panel

A persistent, lightweight status area (could be a collapsible panel, sidebar section, or header bar) showing:

┌─────────────────────────────────────────┐
│ 🔧 Agent Status: Working               │
│                                         │
│ Queue depth: 2                          │
│ ├─ 🔄 [active] Executing: exec (pid    │
│ │     12345) — running 15s              │
│ ├─ ⏳ [queued] web_search: "openclaw    │
│ │     upgrade guide"                    │
│                                         │
│ Sub-agents: 1 running                   │
│ └─ 🔄 research-task (45s, 30% context) │
│                                         │
│ Session: agent:main:main                │
│ Context: 44% (89k/200k)                │
│ Model: claude-opus-4-5                  │
└─────────────────────────────────────────┘

This gives the user:

1. Is the agent doing something? (not just a blank screen or spinner)
2. What specifically? (tool name, command, search query)
3. How long has it been running? (elapsed time per operation)
4. What's queued next? (pending operations)
5. Sub-agent status (spawned tasks and their progress)
6. Resource awareness (context %, model in use)

C. Activity Feed / Event Log

A scrollable event log (like a terminal or CI/CD pipeline view) that shows real-time events:

14:31:02  Message received from user
14:31:03  Agent thinking...
14:31:05  Tool call: exec (powershell -Command "openclaw --version")
14:31:06  Tool result: 2026.1.30 (exit 0)
14:31:06  Tool call: session_status
14:31:07  Tool result: OK (context 44%)
14:31:08  Agent composing response...
14:31:10  Response delivered (245 tokens)

This is different from the chat view — it's a machine-readable audit trail that power users can glance at to understand exactly what happened, especially after a refresh.

D. Reconnection Resilience

When the WebSocket reconnects (after refresh, network drop, or tab wake):

1. Immediately: Show "Reconnecting..." with last known state
2. On connect: Fetch session history + current queue state
3. If agent is mid-response: Resume streaming from current position
4. If agent finished while disconnected: Show the completed response with a "delivered while you were away" indicator

E. Keyboard Shortcut Guard

Optionally intercept F5/Ctrl+R with a confirmation dialog when the agent is actively processing:

"The agent is currently working on your request. 
Refreshing will hide the progress view. Continue?"
[Refresh] [Cancel]

This is a common pattern in web apps with unsaved state (Google Docs, Figma, etc.).

Implementation Notes

• Session message history already exists server-side — the WebSocket sessions.history method can fetch it on reconnect
• Queue depth is available via the collect queue state (already shown in session_status)
• Tool call events are already emitted over WebSocket — just need UI rendering
• The Activity Feed could reuse existing gateway log events

Environment

• OpenClaw 2026.1.30
• Windows 10, Chrome/Edge
• WebChat as primary interface