After close to tray and open again list of sessions ALWAYS set on middle of list and not on last chat.

[danilovmy]

windows 10. Companion, Native chat.

I start the companion, after opening chat. In select box with sessions list the session from middle of list is choosen.

Start:

chat open, automatically choosen session with bonsai light.

I choose "reciept main session"

In this chat i perform my tasks succefully.

But suddenly i need to switch on other app in windows.
I close chat with "X", because i dont want to see minimized tab on task panel.

But the companion still works:

Next chat opening -> In select box with "sessions list" the session from middle of list is choosen, not the last active chat.

Awaited:
Last active chat is open. or setting, where i can say - which chat should be opened by default.

[clawsweeper]

Codex review: keeping this open for maintainer follow-up; there is still a little grit to resolve. Reviewed July 8, 2026, 10:09 AM ET / 14:09 UTC.

Summary
Keep open: current native chat appears to preserve the selected session only while the FunctionalUI tree stays mounted, while a remount falls back to the provider default session instead of the user's last active session.

Reproducibility: no. live Windows reproduction was run here. The reporter's screenshots plus source inspection give a medium-confidence path: select a non-default native chat session, close/reopen the chat surface, and observe the component remount defaulting to main/first rather than last selected.

Ways to help us reproduce this

• Add a screenshot or short recording showing the behavior.
• Add expected vs actual behavior.
• Include redacted logs or terminal output.

Next step
This is a narrow chat UX state bug with clear likely files and validation, but it still needs a Windows visible proof pass because I only established a source-level reproduction.

Review details

Best possible solution:

Persist the user's last selected native chat session and initialize remounted chat surfaces from it, falling back to the gateway default only when that session no longer exists.

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

No live Windows reproduction was run here. The reporter's screenshots plus source inspection give a medium-confidence path: select a non-default native chat session, close/reopen the chat surface, and observe the component remount defaulting to main/first rather than last selected.

Is this the best way to solve the issue?

Yes: restoring the last active session is the narrowest maintainable fix because current comments already intend native chat state preservation. A new default-session setting should wait unless maintainers want configurable behavior beyond fixing the lost selection.

AGENTS.md: found and applied where relevant.

Remaining risk / open question:

• I did not run a live Windows UI reproduction in this read-only Linux review; the conclusion is based on reporter screenshots plus source inspection.

Codex review notes: model internal, reasoning high; reviewed against 87634727b65b.

Label changes

Label changes:

• add P2: The bug affects a normal user-facing chat workflow with a manual reselect workaround and limited blast radius.
• add impact:session-state: The issue is about the native chat selection state drifting away from the user's last active session after close/reopen.
• add impact:ux-friction: Users can continue, but they must notice the wrong session and manually choose the last active chat each time.
• add issue-rating: 🐚 platinum hermit: Current issue advisory state selects this label.
• add clawsweeper:needs-live-repro: Current issue advisory state selects this label.

Label justifications:

• P2: The bug affects a normal user-facing chat workflow with a manual reselect workaround and limited blast radius.
• impact:session-state: The issue is about the native chat selection state drifting away from the user's last active session after close/reopen.
• impact:ux-friction: Users can continue, but they must notice the wrong session and manually choose the last active chat each time.

Evidence reviewed

Acceptance criteria:

• ./build.ps1
• dotnet test ./tests/OpenClaw.Shared.Tests/OpenClaw.Shared.Tests.csproj --no-restore
• dotnet test ./tests/OpenClaw.Tray.Tests/OpenClaw.Tray.Tests.csproj --no-restore
• Windows visible proof: open native chat with multiple sessions, select a non-default session, close with the X/hide to tray, reopen, and verify the same session is selected; repeat with the saved session removed to verify fallback.

What I checked:

• Reporter reproduction: The issue body provides Windows 10 native chat screenshots showing a non-default session selected, then the chat closed with the window X, and a later open selecting a different session instead of the last active one.
• Selection is local to the chat component: OpenClawChatRoot seeds selectedIdState from the initial thread and the composer OnChannelChanged handler only updates component-local state/ref; there is no host/provider callback that records the user's newly selected session for a later remount. (src/OpenClaw.Tray.WinUI/Chat/OpenClawChatRoot.cs:148, 87634727b65b)
• Tray chat remount has no selected-session handoff: ChatWindow mounts the native chat without an initialThreadId, so a recreated/remounted chat root relies on the provider's DefaultThreadId rather than the user's previous dropdown selection. (src/OpenClaw.Tray.WinUI/Windows/ChatWindow.xaml.cs:428, 87634727b65b)
• Provider default is main or first session: ResolveDefaultThreadIdLocked prefers the gateway main session, then the compose target, then the first session; RememberLastSessionStateLocked likewise records the main/first session rather than the UI-selected session. (src/OpenClaw.Tray.WinUI/Chat/OpenClawChatDataProvider.cs:5334, 87634727b65b)
• Existing tests pin main-session default behavior: OpenClawChatDataProviderTests assert that DefaultThreadId is the main session and specifically prefers IsMain, but I found no test that records or restores the user's last selected native chat session. (tests/OpenClaw.Tray.Tests/OpenClawChatDataProviderTests.cs:5553, 87634727b65b)
• Repository policy read: AGENTS.md was read fully; its tray/chat UX validation and proof guidance applies to any future fix, but this review made no repository changes. (AGENTS.md:1, 87634727b65b)

Likely related people:

• shanselman: Blame and PR metadata tie the selected-state initialization, provider default-session logic, and ChatWindow mount path to merged commit 4166e0f via Fix Tray UI test window hiding for release #897. (role: introduced behavior; confidence: high; commits: 4166e0fd63f8; files: src/OpenClaw.Tray.WinUI/Chat/OpenClawChatRoot.cs, src/OpenClaw.Tray.WinUI/Chat/OpenClawChatDataProvider.cs, src/OpenClaw.Tray.WinUI/Windows/ChatWindow.xaml.cs)
• calebeden: Recent merged chat work changed OpenClawChatDataProvider snapshot/queued-message behavior and chat root identity handling near the affected selection/defaulting path. (role: recent area contributor; confidence: medium; commits: f89a88a6baf4, c9b5476a873f; files: src/OpenClaw.Tray.WinUI/Chat/OpenClawChatRoot.cs, src/OpenClaw.Tray.WinUI/Chat/OpenClawChatDataProvider.cs, tests/OpenClaw.Tray.Tests/OpenClawChatDataProviderTests.cs)

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.

[clawsweeper]

🦞⚠️
Automatic implementation stopped before completion.
Reason: The automatic implementation worker stopped before all deterministic gates completed. Open the workflow run for the exact blocker.
Worker: https://github.com/openclaw/clawsweeper/actions/runs/28960259287

[danilovmy]

I find the rule, which session for chat will be selected right now as default. It is a First session from bottom in session list, completely below all sessions.