Summary

When a message is in queued state in the Control UI (waiting for an active run to finish), navigating to a different session causes that message to disappear silently — it never gets processed and leaves no trace in the transcript.

Steps to Reproduce

1. Open a session in the Control UI webchat
2. Send message A → it starts processing (agent run active)
3. While message A is still processing, send message B → it shows as queued
4. Switch to a different session in the Control UI
5. Switch back to the original session

Expected: Message B is still visible and gets processed after message A finishes.
Actual: Message B has disappeared — not in the transcript, not processed, no error shown.

Environment

• OpenClaw version: 2026.4.26
• Channel: webchat (Control UI)
• Browser: Chrome

Root Cause Hypothesis

The "queued" state appears to be client-side only (optimistic rendering). When the user navigates away, the WebSocket context for that session is likely torn down before the queued message is durably committed to the gateway. The gateway never receives it.

Related Issues

• Webchat: messages lost during WebSocket reconnect (no client-side queue/ACK) #45952 — messages lost on WebSocket reconnect (related but different trigger)
• [Bug]: WebChat loses message queue, conversation history, and draft on browser refresh #51549 — message queue lost on browser refresh (related but different trigger)

Impact

Any queued follow-up message sent while an agent is running is silently dropped if the user navigates to another session — no feedback, no retry, no persistence.