UX for switching chats/sessions isn't super clear

[RomneyDa]

@joelagnel

[clawsweeper]

Codex review: keeping this open for maintainer follow-up; there is still a little grit to resolve. Reviewed August 20, 2026, 3:14 PM ET / 19:14 UTC.

Summary
Keep open for member-led product scoping. Current main has two session-switching paths, but the report does not identify which user journey is unclear or what improvement is expected.

Reproducibility: no. Current main offers a Chat picker and an Open chat action, but the issue gives no user journey, expected result, or observed result to reproduce.

Ways to help us reproduce this

• Add expected vs actual behavior.
• Include redacted logs or terminal output.

Maintainer decision needed

Question	Recommendation
Which session-switching journey should this issue optimize: finding a prior conversation from Chat, opening one from the Sessions page, or both?	Capture the journey: Request a screenshot or short recording and the expected next action before selecting a UX change.

Why: Current main already provides both paths, and the report does not identify the confusing step. The answer determines whether the appropriate work is copy, layout, navigation, or a new interaction.

Next step
A maintainer must choose the intended user journey before a safe implementation boundary can be defined.

Review details

Best possible solution:

Define one observed switching journey, then make the Chat picker and Sessions-page route communicate it consistently with a focused interaction test and visible current-head proof.

Do we have a high-confidence way to reproduce the issue?

No. Current main offers a Chat picker and an Open chat action, but the issue gives no user journey, expected result, or observed result to reproduce.

Is this the best way to solve the issue?

Unclear. Selecting a UI change before identifying which existing route confused users would not be a well-scoped solution.

AGENTS.md: found and applied where relevant.

Remaining risk / open question:

• A change chosen without an observed user task could add a competing selection route or disturb the existing selected-thread handoff.

Codex review notes: model internal, reasoning high; reviewed against 3880b62dd517.

Label changes

Label changes:

• add P3: This is an underspecified UX-discoverability request with no reported availability, security, or data-loss impact.
• add impact:ux-friction: The stated concern is clarity while navigating between existing chat sessions.
• add issue-rating: 🦪 silver shellfish: Current issue advisory state selects this label.
• add clawsweeper:needs-info: Current issue advisory state selects this label.
• add clawsweeper:no-new-fix-pr: Current issue advisory state selects this label.
• add clawsweeper:needs-maintainer-review: Current issue advisory state selects this label.
• add clawsweeper:needs-product-decision: Current issue advisory state selects this label.

Label justifications:

• P3: This is an underspecified UX-discoverability request with no reported availability, security, or data-loss impact.
• impact:ux-friction: The stated concern is clarity while navigating between existing chat sessions.

Evidence reviewed

What I checked:

• Current in-chat route: The Reactor chat composer exposes an accessible session picker, marks the active session, and routes selection through the composer controller. (src/OpenClaw.Tray.WinUI/Chat/ReactorChatComposer.cs:562, 3880b62dd517)
• Current Sessions-page route: Each displayed session has an Open chat action that stores the target key and navigates to Chat. (src/OpenClaw.Tray.WinUI/Pages/SessionsPage.xaml.cs:389, 3880b62dd517)
• Selection ownership: The current chat root owns selected-thread state and binds the composer selection handoff to it. (src/OpenClaw.Tray.WinUI/Chat/OpenClawReactorChatRoot.cs:265, 3880b62dd517)
• Current implementation provenance: Blame attributes the current Reactor session-picker implementation to the composer ownership extraction. (src/OpenClaw.Tray.WinUI/Chat/ReactorChatComposer.cs:562, 686afdc8d4a2)
• Main versus release: The current picker commit is contained by v2026.7.2 alpha tags, while the provided latest release is v2026.7.1. (src/OpenClaw.Tray.WinUI/Chat/ReactorChatComposer.cs:562, 686afdc8d4a2)
• Report detail: The issue body only mentions another member and supplies no screenshot, steps, expected behavior, or affected switching surface.

Likely related people:

• Barbara Kudiess: Current blame attributes the Reactor composer session-picker lines to the composer ownership extraction. (role: current session-picker implementation author; confidence: high; commits: 686afdc8d4a2; files: src/OpenClaw.Tray.WinUI/Chat/ReactorChatComposer.cs)
• Scott Hanselman: Current blame attributes the Sessions-page Open chat control to this release-era commit, though older history is incomplete locally. (role: adjacent Sessions-page contributor; confidence: medium; commits: 4206611f2b2e; files: src/OpenClaw.Tray.WinUI/Pages/SessionsPage.xaml)

How this review workflow works

• ClawSweeper keeps one durable marker-backed review comment per issue or PR.
• Re-runs edit this comment so the latest verdict, findings, and automation markers stay together instead of adding duplicate bot comments.
• A fresh review can be triggered by eligible @clawsweeper re-review comments, exact-item GitHub events, scheduled/background review runs, or manual workflow dispatch.
• PR/issue authors and users with repository write access can comment @clawsweeper re-review or @clawsweeper re-run on an open PR or issue to request a fresh review only.
• Maintainers can also comment @clawsweeper review to request a fresh review only.
• Fresh-review commands do not start repair, autofix, rebase, CI repair, or automerge.
• Maintainer-only repair and merge flows require explicit commands such as @clawsweeper autofix, @clawsweeper automerge, @clawsweeper fix ci, or @clawsweeper address review.
• Maintainers can comment @clawsweeper explain to ask for more context, or @clawsweeper stop to stop active automation.