Bug Description

When the gateway experiences websocket instability or restarts, the sessions.json file can end up with sessionId and sessionFile pointing to different transcript files. This causes the UI (both WebChat and TUI) to read an older transcript file while the gateway continues writing to a different one, resulting in the user seeing stale conversation history.

Steps to Reproduce

1. Use WebChat for normal conversation
2. Gateway experiences websocket reconnections (e.g. due to network instability)
3. After reconnections, gateway continues writing to the active transcript file
4. But sessions.json entry for the session maps to an older transcript via sessionId
5. UI reads from sessionId → shows stale messages; new messages not visible

Environment

• OpenClaw version: 2026.4.2 (d74a122)
• OS: macOS
• Channel: webchat / openclaw-tui

Observed Behavior

sessions.json for agent:main:main:

{
  "sessionId": "f4b82d75-4541-4513-87a2-53ca5322e520",  // points to OLD transcript (stopped at 16:05)
  "sessionFile": "/path/to/77f85a38-6b3e-4900-8efa-0fc5f50eab97.jsonl"  // actual active transcript
}

• Old transcript last message: 2026-04-04T08:05:21.599Z (16:05 GMT+8)
• Active transcript last message: 2026-04-04T13:39:50.261Z (21:39 GMT+8, current)
• The gateway was writing to the active transcript but sessionId was never updated

Root Cause Hypothesis

The sessionId field in sessions.json is not being updated when the gateway switches to a new or different transcript file during websocket reconnection or restart. The gateway uses sessionFile (which is kept current) but the UI reads sessionId to locate the transcript, creating an inconsistency.

Impact

• Users see stale conversation history after any gateway reconnect/restart event
• Severity: HIGH — users lose visibility into recent conversation context
• Related to: #51549 (WebChat loses message queue and history on refresh), but distinct in that history IS being persisted, just to the wrong file

Suggested Fix

1. Ensure sessionId is always updated when a new transcript file is selected/written
2. Alternatively, make UI read from sessionFile instead of sessionId when looking up transcript
3. Add a consistency check on gateway startup to detect and repair mismatched sessionId/sessionFile pairs

Logs

Gateway log shows frequent websocket reconnections (20:14-20:19) followed by SIGTERM restart and delivery-recovery:

[delivery-recovery] Found 1 pending delivery entries — starting recovery

No explicit session routing error was logged, suggesting the split happened silently.

-- Reported via OpenClaw agent on behalf of the user.