Selecting /side from the slash menu should open the side chat immediately and focus its input#29976

opened7d agobyJjoshrad-dev

What happened

In the desktop app, choosing /side (or /btw) from the slash-command menu doesn't open a side chat. It replaces the typed text with "/side " in the composer, and you have to press Enter a second time to start the side chat.

Other built-in slash commands run as soon as they're chosen. For example, "/usag" + Enter runs /usage-limits, and "/mode" + Enter on /model opens the model picker. So /side feels inconsistent, as if Enter has to be pressed twice.

Related: once the side chat opens, keyboard focus stays in the main thread's composer. In the Codex desktop app, choosing /side opens the side chat and focuses its input straight away, so "/sid" → Enter → type the question is one quick motion.

Diagnosis

Same code in v0.1.6 (2359643c) and main (61c3794c):

  • apps/web/src/components/chat/ChatComposer.tsx, onSelectComposerItem: for item.command === "side" | "btw", the handler only calls applyPromptReplacement(..., /${item.command} ). Unlike the "model" branch and the /usage-limits provider-command branch, it doesn't run anything.
  • The side chat only starts on send: useComposerSend parses the whole message with parseSideChatCommand (composer-logic.ts, /side [prompt]) and calls onSideChat(prompt) → useSideChat.open(prompt).
  • useSideChat.start ends with useRightPanelStore.getState().openSideChat(threadRef, targetThreadId), which only adds and activates the side-chat surface. Neither that path nor SideChatPane.tsx moves focus into the side chat's composer.

Inserting "/side " looks deliberate, to allow "/side " on one line. Opening the side chat directly from the menu would drop that path unless the side chat's input is focused on open, so the two changes probably belong together:

  1. Choosing /side or /btw from the menu (with nothing else typed) calls sideChat.open() immediately and clears the trigger text, like /model.
  2. When a side chat is opened by the user from the composer, focus moves to the side chat's composer.

Steps to reproduce

  1. Open a thread in the T3 Code desktop app where side chats are available.
  2. In the composer, type "/sid". The menu shows /side.
  3. Press Enter. Expected: the side chat opens and its input has focus, ready to type. Actual: the composer now contains "/side " and no side chat opens.
  4. Press Enter again. The side chat opens, but focus doesn't go to the new side chat text box nor does it stay in the original text box.

For comparison: type "/mode", press Enter on /model, and the model picker opens immediately.

In this video, you can see me type "/sid", hit enter, then hit enter again. After that, I start typing and the text input doesn't go anywhere.

https://github.com/user-attachments/assets/d6e85f75-773a-469e-81fa-bf73f5ced85f

In this video, you can see me use the codex app to type "/sid", hit enter once, then I can immediately start typing in the side chat which is much quicker.

https://github.com/user-attachments/assets/ccdd07f3-e159-4f81-a02c-39c7ef0f8f54

Version

Reproduced on 0.1.6 and on the latest dev build (main at 61c3794c, 2026-11-02).

Environment

Desktop app on macOS (darwin arm64), local server.

Evidence

shell
1Code-level only (UX behaviour, no errors or logs). See the file references under Diagnosis.

No existing issue found for this. Related side-chat work: #26454, #15758 (feature requests that added side chats), #28905 (search in side chat). My other issue about using native Codex forks while a thread is running would also be useful in making side chats open quicker: #29963

Fix applied or workaround

Type the question on the same line: "/sid" → Enter → Enter again. That will properly open the side chat tab.

Filed by

Triaged with t3 triage using Claude Code (Claude Opus 5.5, claude-opus-5-5).