[Bug]: Companion /new creates session but does not select or materialize it in chat UI

[oywino]

Summary

In Windows Companion v2026.9.3, typing /new successfully creates a new Gateway session, but Companion does not switch to that session and does not expose the empty session in the chat-area session selector.

The newly created session is visible immediately in Companion's Gateway session list as New session, so session creation itself succeeds. The failure is in Companion's local selection/materialization behavior.

Environment

• Windows Companion: v2026.9.3
• Gateway: OpenClaw 2026.9.4
• Windows 11 x64
• Existing selected chat/session: Main

Reproduction

1. Start with Main selected in Companion.
2. Type /new in the Companion composer.
3. Click Send once.
4. Do not select anything else.

Actual behavior

• Companion remains on Main; the chat view does not change.
• A new session named New session appears immediately in Companion's Gateway session list.
• The new session is absent from the chat-area session selector below the conversation.

Additional controlled verification:

5. In ControlUI, select the newly created New session and send one message (test).
6. The session becomes a normal/materialized chat and appears in Companion's chat-area selector as Direct message.
7. Companion still remains on Main.
8. Manually selecting Direct message in Companion works normally and shows the message.

So the created session is healthy; Companion simply does not perform the expected local handoff to it.

Expected behavior

After successful /new session creation, Companion should immediately select the newly created session and make it usable in the chat UI, even before the session has received its first message.

Source behavior in v2026.9.3

The current lifecycle path appears intended to do exactly that:

• ChatLifecycleCommandDispatcher parses /new, calls CreateSessionAsync(...), and returns Succeeded: true with NewSessionKey when creation succeeds.
• ChatComposerController.SendCoreAsync(...) then invokes _selectedSessionHandoff(sessionKey) when NewSessionKey is returned.
• OpenClawReactorChatRoot binds that handoff to local selection and maintains _pendingSelectedThreadId / a compose-only thread so a newly created session can be selected before it is materialized by history/content.

Observed behavior indicates that this selection/materialization handoff is not taking effect.

Notes

• This is not the same as Add "New Chat" / "New Session" action to Windows Companion — currently only past conversations are selectable #1271, which requests a visible New Chat/New Session UI action. Here /new exists and session creation succeeds, but Companion fails to transition to the newly created session.
• No crash behavior is part of this report; the reproduction above is a functional failure only.

[clawsweeper]

Codex review: keeping this open for maintainer follow-up; there is still a little grit to resolve. Reviewed September 14, 2026, 1:35 PM ET / 17:35 UTC.

Summary
Current main retains the reported selection defect. The author’s open fix PR now owns this work, superseding the previous review’s recommendation to dispatch a separate repair.

Reproducibility: yes. from source: send /new while Main exists, render the temporary new thread, then render again before it materializes. Pending selection is cleared prematurely, enabling fallback; no runtime tests were executed during this read-only review.

Next step
Review and land or resolve #1420 (fix(chat): keep new sessions selected and usable after /new); its explicit ownership rules out another repair dispatch.

Review details

Best possible solution:

Retain pending selection until the real thread appears or explicit navigation replaces it, while keeping the empty conversation visible and routing its first message to the new session.

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

Yes, from source: send /new while Main exists, render the temporary new thread, then render again before it materializes. Pending selection is cleared prematurely, enabling fallback; no runtime tests were executed during this read-only review.

Is this the best way to solve the issue?

Yes. Repairing pending-selection lifetime and empty-conversation eligibility within the existing selection owner is narrower than adding another session-creation path.

AGENTS.md: found and applied where relevant.

Remaining risk / open question:

• The linked PR’s reported successful live run required /reset preparation; an independently reported state-dependent WinUI crash can interfere with validation and remains separate.

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

Label changes

Label justifications:

• P1: An existing chat command fails its session handoff for a reported current-release user, matching the human-assigned priority.
• impact:session-state: Gateway session creation succeeds while Companion loses the intended local selection.
• impact:ux-friction: The reporter can recover through another client and manual selection, but the normal new-conversation flow fails.

Evidence reviewed

What I checked:

• Current-main selection defect: The chat root clears pending selection when effectiveThread matches it, including when that thread was only synthesized by CreateComposeOnlyThread. A subsequent render without a materialized session can therefore fall back to Main. Empty presentation also excludes compose-only threads whenever existing threads are present. (src/OpenClaw.Tray.WinUI/Chat/OpenClawReactorChatRoot.cs:136, bd9ce43b4d9c)
• Existing behavior contract: Tests explicitly require a pending newly created session to survive stale snapshots and suppress fallback. The controller separately tests handing the canonical new session key to local selection. (tests/OpenClaw.Tray.Tests/OpenClawChatDataProviderTests.cs:425, bd9ce43b4d9c)
• Open implementation candidate: GitHub confirms fix(chat): keep new sessions selected and usable after /new #1420 (fix(chat): keep new sessions selected and usable after /new) remains open and unmerged. Its supplied body explicitly closes this issue and reports successful real-Gateway selection and first-message routing after /reset preparation. (c5d9d2a0dd7a)
• Release remains affected: The same premature pending-selection clearing exists in v2026.9.3, whose commit is 84928c4. GitHub identifies v2026.9.3 as the latest release; no implemented fix is established on current main. (src/OpenClaw.Tray.WinUI/Chat/OpenClawReactorChatRoot.cs:136, 84928c4370bc)
• Ownership boundary: The architecture ledger retains selected/materialized/compose-only thread selection in the chat root and delegates composer workflow to the controller. (docs/ARCHITECTURE.md:253, bd9ce43b4d9c)
• Feature-history routing: Path history associates native lifecycle commands with commit 2fb1da2; GitHub maps its author to calebeden. Composer-extraction history identifies karkarl at 686afdc. These are routing signals, not verified introduction of the defective lines. A deeper --follow query failed while retrieving a historical object with HTTP 403. (src/OpenClaw.Tray.WinUI/Chat/ChatLifecycleCommandDispatcher.cs, 2fb1da26c175)

Likely related people:

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

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.