Bug type

Behavior bug (incorrect output/state without crash)

Beta release blocker

No

Summary

In Control UI / webchat, the normal "New Session" paths are not creating a genuinely fresh session the way backend session creation does.

What I verified:

• manually creating a new session key (test-fresh-1) produced a real fresh session with low context usage
• that new session appeared in the session dropdown and became active when selected
• context in that fresh session was about 18k/272k (7%)
• by contrast, the normal /new, /reset, and New Session button flows are not behaving like that fresh-session path and appear to keep routing back to the canonical main session instead of giving an actually separate fresh session

This means the backend can support the desired behavior, but the standard Control UI new/reset flows are not using it correctly.

Steps to reproduce

1. Open Control UI / webchat
2. Observe a long-lived main session with substantial inherited context
3. Use the normal fresh-start UX, for example:
   • type /new, or
   • type /reset, or
   • click the New Session button
4. Observe that the session does not behave like a truly fresh independent session
5. For comparison, create a distinct session key directly (example used during testing: test-fresh-1)
6. Select that new session from the session dropdown
7. Observe that this direct-created session does behave like a genuinely fresh session, including low context usage and independent session identity

Expected behavior

/new, /reset, and the New Session button should all converge on the same fresh-session behavior as direct session creation:

• create or switch to a genuinely fresh session
• give that session its own identity in the session selector
• start with low context usage rather than silently resuming agent:main:main
• not require manual session-key creation as a workaround

Actual behavior

• manual session creation produces the correct fresh-session result
• /new, /reset, and the New Session button do not appear to follow that same path
• the UI seems to route back to the canonical main session (agent:main:main) or otherwise fails to materialize the same kind of fresh independent session
• as a result, users can believe they started fresh when they did not

OpenClaw version

2026.4.15

Operating system

WSL2 / Linux

Install method

npm global

Model

openai-codex/gpt-5.4

Provider / routing chain

webchat / Control UI

Additional provider/model setup details

Gateway was healthy and local. The behavior was observed in Control UI with direct local webchat usage.

Logs, screenshots, and evidence

Fresh directly-created session status:
Session: agent:main:test-fresh-1
Context: 18k/272k (7%)

Observed prior investigation notes:
- Control UI/session-selection behavior appears more likely than auth token or browser cache issues
- fallback defaults around `sessionKey: "main"` and `lastActiveSessionKey: "main"` appear relevant when no saved session is available

Impact and severity

High UX impact for anyone trying to escape a polluted or oversized session:

• users expect /new, /reset, or New Session to actually start fresh
• debugging is confusing because the backend fresh-session path works
• current behavior makes the standard UI affordances unreliable as recovery tools

Additional information

Possibly related but not identical to these existing issues:

• [Bug]: WebChat session selector shows main session as “heartbeat” after a while, making /new feel like sessions disappear #66533, where session selector labeling makes /new feel like sessions disappear
• Bug: /new session can be stranded by routing-mode changes and resume an older session #47561, where /new can be superseded by routing changes
• [Bug]: Control UI /new or /reset can prepend stale system-summary text to the first message of a new session #58353, where /new or /reset can carry stale content into the first message

This report is specifically about the normal fresh-session UI flows not matching the behavior of a truly new independently created session.