fix(chat): keep new sessions selected and usable after /new

[oywino]

Fixes #1411.

What Problem This Solves

Fixes an issue where users sending /new in Companion would return to Main and could not use the newly created empty conversation, despite successful Gateway session creation.

Why This Change Was Made

Keep the selected new session pending across stale snapshots until its real thread materializes or navigation supersedes it. Allow its compose-only conversation to settle into the existing Empty presentation even when Main exists. Existing picker insertion and composer routing remain in place.

The root retains ownership of selection and timeline composition; the existing pure ChatLifecycleSelectionPolicy owns the tested retention and compose-only eligibility decisions. This PR covers Bug A only.

Required proof pools

• windows-winui-interactive: current-head /new selection, chat-area picker visibility, usable Empty presentation, and first-message routing through a real Gateway. Developer-reported live chat proof passed under the /reset preparation described below. The posted screenshot/proof comment supports the live result. The declared accessibility gate passed: 22/22 tests, exit 0; details and TRX below.

Validation

• ./build.ps1: passed, all five build targets including WinUI.
• dotnet test ./tests/OpenClaw.Shared.Tests/OpenClaw.Shared.Tests.csproj --no-restore: 3,996 passed, 36 skipped, 0 failed.
• dotnet test ./tests/OpenClaw.Tray.Tests/OpenClaw.Tray.Tests.csproj --no-restore: 2,985 passed, 0 skipped, 0 failed.
• Focused regression filter (FullyQualifiedName~ChatLifecycleSelectionPolicyTests|FullyQualifiedName~SendAsync_AfterNew_FirstMessageTargetsPendingComposeOnlySession): 9 passed, 0 failed; also included in the final Tray run.
• git diff --check: passed.

The final build and suites ran sequentially. Earlier native-runtime failures were resolved by installing the required C++ runtime components; an existing voice-disposal timeout passed on recheck and in the final full suite. Local validation used an isolated local clone with all four changed files verified identical to the working patch.

Regression coverage includes repeated stale snapshots, fallback suppression, compose-only welcome eligibility with Main present, materialization, navigation away, unchanged unrelated compose-only behavior, and first-message routing through the controller seam. A temporary fault-injection run restoring premature pending retirement and the old welcome restriction produced 3 failures out of 9 tests. The fixed source was restored before final validation.

Rubber-duck review: independent source review found no actionable correctness, scope, or ownership issues. Final diff is limited to two source files and two test files.

Current-head WinUI accessibility gate (2026-09-15)

Ran in the existing isolated local PR checkout at c5d9d2a0dd7a05d51a67947979dd6016c91a3a82, using the existing Windows x64 environment:

.\scripts\run-proof-tests.ps1 -Project 'tests\OpenClaw.Tray.UITests\OpenClaw.Tray.UITests.csproj' -Filter 'Category=Accessibility' -ResultName 'winui-accessibility' -RuntimeIdentifier win-x64

• Result: PASS. 22 total, 22 passed, 0 failed, 0 skipped/not executed. Both dotnet test and the proof wrapper exited 0. Tests ran in real Windows processes with fixture-owned isolated tray data.
• Axe summary: all 18 page scans, including ChatPage, passed with zero non-excluded violations. The other 4 passing cases cover composer UIA layout and native chat identity/session-title behavior. No per-severity or excluded-finding totals are emitted by this harness, so this is not a claim of zero unfiltered Axe findings.
• Existing exclusions were unchanged: NameIsInformative, NameExcludesControlType, NameExcludesLocalizedControlType, SiblingUniqueAndFocusable; ConfigPage additionally excludes LocalizedControlTypeNotCustom.
• TRX: TestResults\ProofPools\winui-accessibility\winui-accessibility.trx. Published winui-accessibility.trx. The linked copy redacts Windows user, machine, and user-profile paths; test outcomes are unchanged. Published copy SHA-256: 23ff82bf78952c541c816d653382d2221312aa44a85da2e78b058fd9905f0631.
• Proof is linked as an artifact under the repository proof-package guidance. CI uses actions/upload-artifact for its own runs; this local TRX is published separately and is not represented as a CI artifact. No generated artifacts were committed.
• No source/test files, commits, branch history, or software installations changed for this validation.

Real behavior proof

Developer-reported live Windows WinUI proof on current head c5d9d2a0dd7a05d51a67947979dd6016c91a3a82, using the isolated PR build connected to the real Gateway.

Launch: ./run-app-local.ps1 -NoBuild -Isolated -AllowNonMain.

Preparation: the developer first issued /reset on Main, then /new, to avoid interference from the separately reproducible state-dependent WinUI crash. This preparation is part of the proof conditions.

Observed results:

• /new succeeded and the newly created session was immediately selected.
• The new session appeared in the chat session selector.
• The chat displayed a usable empty/new conversation.
• The first ordinary message, PR1420 LIVE PROOF, was routed to the newly created session.
• The reply arrived in that same session, and the session remained selected.

This verifies the reported Bug A flow under the stated preparation. These are the developer's live observations; they are not an automated UI test result. The posted current-head screenshot/proof comment shows the selected conversation and live-proof reply; the earlier empty state remains developer-reported. The accessibility gate passed as recorded above. A separate explicit-navigation-away live proof has not been reported as run.

Separate pre-existing WinUI crash (out of scope)

The developer also reproduced the state-dependent WinUI crash on the exact unmodified base commit bd9ce43b4d9c63fa90196a6a33b1c1be409850b2, built with the same environment/configuration in a separate isolated worktree and tested against the same Gateway. This establishes that the crash is not introduced by this PR. It can interfere with /new testing depending on the starting session state; the successful proof above followed /reset on Main.

The earlier isolated PR crash recorded System.ArgumentException: The parameter is incorrect (0x80070057) and WinUI fail-fast 0xc000027b. Its debugger failure bucket/hash matched the developer's pre-PR crash dump. The minidump did not retain the original stowed exception stack, so no specific native failing call is claimed from that dump.

The crash investigation remains separate from Bug A. No crash workaround or other code change is included in this proof update.

Local build environment: Windows x64, .NET SDK 10.0.401, Windows SDK 10.0.26100.0, with the previously installed Visual Studio Build Tools C++ runtime components used by native speech tests.

[clawsweeper]

🦞👀
ClawSweeper picked this up.

Pull request received. I will update this pull request when review starts.

ClawSweeper review complete

ClawSweeper finished reviewing this revision. The review result is being finalized.

View the workflow run.

[clawsweeper]

Codex review: needs maintainer review before merge. Reviewed September 15, 2026, 3:52 AM ET / 07:52 UTC (Revision 4).

ClawSweeper review

What this changes

Preserve newly created chat sessions across delayed updates, show their usable empty conversation, and add selection and first-message routing regression tests.

Merge readiness

✅ Ready for maintainer review

This fix remains necessary on current main. The previous proof follow-up is resolved, and the reviewed patch has no blocking correctness or security findings.

Priority: P2
Reviewed head: c5d9d2a0dd7a05d51a67947979dd6016c91a3a82

Review scores

Measure	Result	What it means
Overall readiness	🐚 platinum hermit (4/6)	A focused repair with regression coverage, sufficient real-session proof, and the previous accessibility follow-up completed.
Proof confidence	🐚 platinum hermit (4/6) ✨ media proof bonus	Sufficient (screenshot): The inspected screenshot and current-head Windows report connect the changed chat-root selection behavior to a real Gateway /reset then /new flow, immediate usable selection, and a first-message reply in that conversation. The empty state is developer-reported; the separate base-reproduced crash remains outside this repair. The linked accessibility artifact independently confirms 22 passing cases.
Patch quality	🐚 platinum hermit (4/6)	No actionable review findings were identified.

Verification

Check	Result	Evidence
Real behavior	Verified	Sufficient (screenshot): The inspected screenshot and current-head Windows report connect the changed chat-root selection behavior to a real Gateway /reset then /new flow, immediate usable selection, and a first-message reply in that conversation. The empty state is developer-reported; the separate base-reproduced crash remains outside this repair. The linked accessibility artifact independently confirms 22 passing cases.
Evidence reviewed	7 items	Current main still contains the defect: Current main clears pending selection when a synthetic thread matches, allowing a subsequent stale snapshot to fall back to Main. Its empty-conversation condition also excludes temporary sessions while real threads exist. The supplied release metadata and local tag identify this revision as v2026.9.4. Introduced repair preserves existing ownership: The pinned introduced diff retains pending selection until actual materialization or selection replacement and permits the matching temporary conversation’s welcome state. Existing picker insertion and controller routing consume that same effective thread; no parallel creation path or persistence format is added. Regression coverage and reported validation: Read the added stale-snapshot, materialization, navigation, welcome-eligibility, and first-message routing tests. The captured PR body reports a successful full build, Shared tests with 3,996 passed and 36 skipped, Tray tests with 2,985 passed, and nine focused cases passing. It also reports three failures when the original behavior was temporarily restored. This review ran no builds or tests; the read-only diff check passed.
Findings	None	None.
Security	None	None.

How this fits together

Companion’s native chat combines Gateway session snapshots with local conversation selection. The selected conversation feeds the session picker, timeline, and message composer.

flowchart TD
  A[User sends new-session command] --> B[Gateway returns session key]
  B --> C[Pending local selection]
  D[Gateway session snapshots] --> E{Selected session materialized?}
  C --> E
  E -->|No| F[Temporary empty conversation]
  E -->|Yes| G[Materialized conversation]
  F --> H[Session picker and message composer]
  G --> H

Loading

Before merge

None.

Agent review details

Security

None.

Review metrics

Metric	Value	Why it matters
Production and test delta	Production +17/-5 lines; tests +85/-0 lines	The small production increase repairs existing selection behavior and is paired with focused regression coverage.
Accessibility evidence	22 executed, 22 passed; 18 page scans	The inspected artifact resolves the prior review’s declared proof-pool follow-up.

Root-cause cluster

Relationship: fixed_by_candidate
Canonical: #1411
Summary: This PR is the explicit candidate fix for the open session-selection bug.

Members:

• canonical: [Bug]: Companion /new creates session but does not select or materialize it in chat UI #1411 - The report describes the same successful creation and failed local-selection path targeted by this patch.

Proposal only: this assessment does not dispatch repair, suppress jobs, mutate sibling items, close, or merge anything.

Technical review

Best possible solution:

Keep selection lifetime in the existing chat root, using actual session materialization to retire temporary state while preserving normal navigation and composer routing.

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

Yes, from source: create a session while Main exists, render its temporary thread, then render another snapshot before materialization. Current main clears pending selection on the first render and permits fallback on the next; this review did not execute the app.

Is this the best way to solve the issue?

Yes. The patch repairs the existing selection policy and empty-state eligibility without duplicating Gateway creation, picker insertion, or message dispatch.

AGENTS.md: found and applied where relevant.

Codex review notes: model internal, reasoning medium; reviewed against 3c43751b2bac.

Labels

Label justifications:

• P2: This is a bounded repair to existing native-chat session selection with a documented manual recovery path.
• rating: 🐚 platinum hermit: Overall readiness is 🐚 platinum hermit; proof is 🐚 platinum hermit and patch quality is 🐚 platinum hermit.
• status: 👀 ready for maintainer look: ClawSweeper has no concrete contributor-facing blocker left for this PR. Sufficient (screenshot): The inspected screenshot and current-head Windows report connect the changed chat-root selection behavior to a real Gateway /reset then /new flow, immediate usable selection, and a first-message reply in that conversation. The empty state is developer-reported; the separate base-reproduced crash remains outside this repair. The linked accessibility artifact independently confirms 22 passing cases.
• proof: sufficient: Contributor real behavior proof is sufficient. The inspected screenshot and current-head Windows report connect the changed chat-root selection behavior to a real Gateway /reset then /new flow, immediate usable selection, and a first-message reply in that conversation. The empty state is developer-reported; the separate base-reproduced crash remains outside this repair. The linked accessibility artifact independently confirms 22 passing cases.
• proof: 📸 screenshot: Contributor real behavior proof includes screenshot evidence. The inspected screenshot and current-head Windows report connect the changed chat-root selection behavior to a real Gateway /reset then /new flow, immediate usable selection, and a first-message reply in that conversation. The empty state is developer-reported; the separate base-reproduced crash remains outside this repair. The linked accessibility artifact independently confirms 22 passing cases.

Evidence

What I checked:

• Current main still contains the defect: Current main clears pending selection when a synthetic thread matches, allowing a subsequent stale snapshot to fall back to Main. Its empty-conversation condition also excludes temporary sessions while real threads exist. The supplied release metadata and local tag identify this revision as v2026.9.4. (src/OpenClaw.Tray.WinUI/Chat/OpenClawReactorChatRoot.cs:136, 3c43751b2bac)
• Introduced repair preserves existing ownership: The pinned introduced diff retains pending selection until actual materialization or selection replacement and permits the matching temporary conversation’s welcome state. Existing picker insertion and controller routing consume that same effective thread; no parallel creation path or persistence format is added. (src/OpenClaw.Tray.WinUI/Chat/OpenClawReactorChatRoot.cs:137, c5d9d2a0dd7a)
• Regression coverage and reported validation: Read the added stale-snapshot, materialization, navigation, welcome-eligibility, and first-message routing tests. The captured PR body reports a successful full build, Shared tests with 3,996 passed and 36 skipped, Tray tests with 2,985 passed, and nine focused cases passing. It also reports three failures when the original behavior was temporarily restored. This review ran no builds or tests; the read-only diff check passed. (tests/OpenClaw.Tray.Tests/ChatComposerControllerTests.cs:275, c5d9d2a0dd7a)
• Inspected current-head live proof: Inspected the prepared screenshot from fix(chat): keep new sessions selected and usable after /new #1420 (comment). It shows connected native chat, a selected conversation, and the live-proof reply. The captured body reports immediate selection, picker visibility, usable empty state, and first-message delivery on the pinned head through a real Gateway after /reset followed by /new. The empty state is developer-reported, not directly pictured. The separate crash was reportedly reproduced on the unmodified base. (c5d9d2a0dd7a)
• Previous accessibility follow-up resolved: Retrieved and parsed the linked TRX at https://gist.github.com/oywino/b1a42d2668ff92c72feb7a21790cd978. Its SHA-256 matches the captured body: 23ff82bf78952c541c816d653382d2221312aa44a85da2e78b058fd9905f0631. Counters show 22 executed, 22 passed, zero failed or skipped, including all 18 page scans and ChatPage. The source scan rejects non-excluded Axe violations. The body now links the screenshot and accurately describes exclusions, satisfying the previous review’s concrete follow-up. (.github/proof-pools.json:428, c5d9d2a0dd7a)
• Existing issue owns the reported problem: [Bug]: Companion /new creates session but does not select or materialize it in chat UI #1411 remains open and describes successful Gateway creation followed by failed local selection. This PR explicitly targets that issue; neither item should close before the fix lands.

Likely related people:

• calebeden: Suggested for follow-up; no historical authorship or introduction is verified. (role: unverified routing candidate; confidence: low)
• bkudiess: Suggested for follow-up; no historical authorship or introduction is verified. (role: unverified routing candidate; confidence: low)

Rating scale

Score	Internal tier	Crab rank	Meaning
6/6	S	🦀 challenger crab	Exceptional readiness
5/6	A	🦞 diamond lobster	Very strong readiness
4/6	B	🐚 platinum hermit	Good normal PR; ordinary maintainer review
3/6	C	🦐 gold shrimp	Useful, but confidence is limited
2/6	D	🦪 silver shellfish	Proof or implementation needs work
1/6	F	🧂 unranked krab	Not merge-ready
N/A	NA	🌊 off-meta tidepool	Rating does not apply

Overall follows the weaker of proof and patch quality.
Shiny media proof means a screenshot, video, or linked artifact directly shows the changed behavior. Runtime, network, CSP, and security claims still need visible diagnostics.

Workflow

• 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.

History

Review history (3 earlier review cycles)

• reviewed 2026-09-14T13:05:20.485Z sha c5d9d2a :: needs real behavior proof before merge. :: none
• reviewed 2026-09-14T14:30:06.449Z sha c5d9d2a :: needs real behavior proof before merge. :: none
• reviewed 2026-09-14T14:34:34.098Z sha c5d9d2a :: needs changes before merge. :: none

[oywino]

Current-head WinUI live proof after /reset → /new: newly created session selected and first-message reply received in the same session.

[oywino]

@clawsweeper re-review

[clawsweeper]

🦞🧹
ClawSweeper re-review requested.

I asked ClawSweeper to review this item again.
Action: item re-review queued (workflow sweep.yml, event exact_review_queue).
Result: when the review finishes, ClawSweeper will create the durable review comment if needed or update the existing comment in place.

Re-review progress:

• State: Complete
• Detail: The durable review result and its route handoff completed.
• Run: https://github.com/openclaw/clawsweeper/actions/runs/34856776133
• Updated: 2026-09-14T14:37:27.391Z

[oywino]

@clawsweeper re-review

[clawsweeper]

🦞🧹
ClawSweeper re-review requested.

I asked ClawSweeper to review this item again.
Action: item re-review queued (workflow sweep.yml, event exact_review_queue).
Result: when the review finishes, ClawSweeper will create the durable review comment if needed or update the existing comment in place.

Re-review progress:

• State: Complete
• Detail: The durable review result and its route handoff completed.
• Run: https://github.com/openclaw/clawsweeper/actions/runs/34944017749
• Updated: 2026-09-15T07:53:39.501Z

[oywino]

Friendly maintainer ping: PR #1420 is now ClawSweeper-ready for maintainer review, with live WinUI proof and the accessibility gate passing 22/22. The head remains unchanged at c5d9d2a.

The remaining GitHub Actions runs still show action_required. Could a maintainer please approve the workflows and review the PR when convenient?