Selecting /side from the slash menu should open the side chat immediately and focus its input#29976
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:
- Choosing /side or /btw from the menu (with nothing else typed) calls sideChat.open() immediately and clears the trigger text, like /model.
- When a side chat is opened by the user from the composer, focus moves to the side chat's composer.
Steps to reproduce
- Open a thread in the T3 Code desktop app where side chats are available.
- In the composer, type "/sid". The menu shows /side.
- 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.
- 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
| 1 | Code-level only (UX behaviour, no errors or logs). See the file references under Diagnosis. |
Related issues
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).