Bug type

Regression (worked before, now fails)

Beta release blocker

No

Summary

In Control UI/WebChat, clicking New session makes the previous chat inaccessible even though WebChat is documented as session-based and able to switch between sessions.

Steps to reproduce

What is broken

In Control UI / WebChat, clicking New session makes the previous chat appear inaccessible from the UI.

Expected behavior

• Clicking New session should create/select a new session
• The previous chat should remain accessible
• The UI/session switcher should still allow returning to the old chat

Actual behavior

• After clicking New session, the previous chat is no longer visible/recoverable from the UI
• It appears as if the prior conversation has been lost

Observed evidence

OpenClaw docs indicate that WebChat is session-based and supports switching between sessions:

• docs/platforms/mac/webchat.md

  • WebChat defaults to the main session
  • “The UI can switch between sessions.”
  • Uses chat.history, chat.send, chat.abort, chat.inject

• docs/web/webchat

  • “Uses the same sessions and routing rules as other channels.”
  • “History is always fetched from the gateway”

This suggests previous chats should remain accessible rather than disappearing after New session.

Related investigation

There may be a related session-key handling problem.

Relevant existing issue:

• Bug: initSessionState uses raw session key while all read paths canonicalize — causes silent session loss on reconnect #29683 — initSessionState uses raw session key while read paths canonicalize

That issue describes a situation where session state is written under one key form and later read using another, which can make an existing transcript appear missing and cause a fresh session to be created.

I have not confirmed that this is the exact same root cause for the New session path, but it looks closely related.

Areas worth checking

• Control UI / WebChat new-session flow
• session switcher population logic
• chat.history lookup path
• initSessionState(...)
• resolveSessionKey(...)
• session-store read/write canonicalization

Why this matters

This is a session continuity / chat history UX bug. Users expect New session to preserve older chats, not make them effectively disappear.

Expected behavior

Clicking New session should start a new, empty chat without deleting, hiding, or orphaning previous chats. Older sessions should remain visible and reopenable from the session switcher/history UI, and their message history should still load normally via the gateway.

Actual behavior

Actual behavior

OpenClaw version

v2026.3.31

Operating system

MacOS Sequoia 15.7.5

Install method

mac app

Model

openai/gpt-5.4

Provider / routing chain

openclaw -> openai/gpt-5.4

Additional provider/model setup details

Tested in Control UI / WebChat. Effective model in the observed session was openai/gpt-5.4.

I have not verified whether any additional external proxy/router was involved in the request path, so no further routing assumptions are included here.

Logs, screenshots, and evidence

## Evidence

- In Control UI / WebChat, clicking **New session** caused the previous chat to become inaccessible from the UI.
- Local OpenClaw docs indicate WebChat is session-based and supports switching between sessions:
  - `docs/platforms/mac/webchat.md`
    - “The UI can switch between sessions.”
    - Uses `chat.history`, `chat.send`, `chat.abort`, `chat.inject`
  - `docs/web/webchat`
    - “Uses the same sessions and routing rules as other channels.”
    - “History is always fetched from the gateway”
- Local session investigation suggested that prior chat continuity was not behaving as expected in the session store / session resolution path.
- Potentially related existing issue:
  - `#29683` — raw vs canonical session-key mismatch causing apparent session loss

A screenshot of the UI state where the prior chat was no longer accessible can be attached here.

Impact and severity

No response

Additional information

No response