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

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

Start with ChatLifecycleCommandDispatcher and ChatComposerController.SendCoreAsync, then trace the _selectedSessionHandoff binding in OpenClawReactorChatRoot. Reproduce /new from an existing Main session and inspect the pending-selection and compose-only thread behavior. Done means the newly created empty session is selected and visible in the chat-area selector immediately after creation.