feat(cli,app): answer /btw side questions from the app

[chphch]

Fixes #1226.

/btw <question> in a Claude chat now opens a panel with Claude's answer instead of reaching Claude as an ordinary message, where Claude Code replies "/btw isn't available in this environment" because it runs that command only in its terminal UI. The SDK offers the same feature as the side_question control request — Claude answers once from the live conversation, with no tools, nothing is written to the transcript, and it works while a turn is running — so the CLI registers a side-question session RPC that hands the question to the running query, and the app intercepts /btw in Claude chats and shows the answer in a panel over the top of the chat that takes follow-ups (sent with the earlier exchanges, as Claude Code's own panel does). The panel leaves the rest of the screen usable, and the thread is kept per chat outside the screen: leaving the chat for the session list or another chat keeps the question running, the chat shows the thread again on the way back, and closing the panel ends it with nothing left behind. A bare /btw answers with its usage in the chat, as Claude Code does, and opens nothing. Each answer has a copy button that copies the answer alone, as c does in Claude Code's panel, to paste into the chat. /btw is also listed among the slash suggestions for Claude chats.

Proof

The thread survives leaving the chat, on web through the session list and on Android through Back, including an answer that arrived while another chat was on screen:

Both are live runs on a local stack (standalone server, a happy-cli daemon and real Claude), the first in Expo web and the second on an Android emulator (x86_64 debug build) against the same server. On web, /btw goes out in one chat, a click on another chat in the session list leaves while Claude is answering, and the CLI log has the answer 7.6 s later, with one side-question call per question, so nothing was cancelled on the way out. On Android a follow-up from the panel's field was answered 12 s after Back took the app to the list. A scripted run of 25 checks covers both widths on web, and that a closed panel stays closed when the chat is opened again.

Answered mid-turn, with a follow-up, and nothing left in the chat (captured with the first commit, when the thread still sat in a modal sheet):

The first message gives Claude a code word and asks for a ~1200-word story. While it writes, /btw asks for the code word (answer: PINEAPPLE-42.) and a follow-up asks for the keeper's name (Ada.); after the turn ends a third /btw asks what the story is about. The CLI log has the first two side questions arriving at 14:16:49 and 14:16:54 and the third at 14:17:35, around the turn's result at 14:17:31. After the thread is closed, the chat holds neither the questions nor the answers.

Notes for review

• The 30 s RPC cutoff. The server drops an RPC after 30 s (RPC_CALL_TIMEOUT_MS), and an answer over a long conversation can take longer, so no RPC waits for the whole answer: ask starts the question and waits up to 20 s, wait picks it up again by id, and cancel drops it (sent when the panel is closed). A question nobody collects is dropped after 10 minutes.
• One question at a time per chat. The composer stays usable while the panel is open, so /btw can arrive while an answer is still coming. It waits its turn and is then asked with that answer in its history, as a follow-up is. The thread lives in memory (sync/sideQuestionThreads.ts), so an app restart starts without it.
• Query.askSideQuestion ships in the SDK runtime but is missing from its public typings (checked through 0.3.286), so it is typeof-gated the same way as the usage seed in claudeRemote.ts.
• When it cannot answer. Claude running in the terminal, or no Claude process yet (remote mode starts Claude with the first message), comes back as unavailable: local | not-started, and the panel says what to do. A session still running a CLI from before this change gets RPC method not available (after the server's 15 s grace for a handler to register), and the panel asks to update the CLI and restart the session, since a running session keeps the CLI it started with. Offline sessions are caught before the call.
• Not the side chat. That forks a full child session with tools; /btw asks the running Claude in place and leaves no session behind.
• Tests. claude/sideQuestion.test.ts (CLI), sync/sideQuestion.spec.ts, sync/sideQuestionThreads.spec.ts (a thread outliving its screen, a late answer after a close, the queue), suggestionCommands.spec.ts, and firstSendComposers.test.ts, whose explicit scope gains the three names the send handler now calls. App and CLI typecheck clean. The app suite passes apart from components/sessionPresentation.test.ts, which fails the same way on main (__DEV__ is not defined while loading expo-modules-core).

🤖 Generated with Claude Code

[chphch]

Follow-up commit: the /btw thread survives leaving the chat

Using this on my own build turned up a gap. The answer lived in a modal sheet, so whatever took the sheet away took the thread with it: on a wide screen a tap on the session list behind the sheet landed on its backdrop and closed it, and on a phone Back did the same. Closing cancelled the question still being answered, and coming back to the chat found nothing.

783c987 keeps the thread outside the screen, one per chat in memory (sync/sideQuestionThreads.ts), and draws it as a panel over the top of the chat instead of a modal, so the session list stays usable. Leaving the chat keeps the question running; coming back shows the thread with any answer that arrived meanwhile. Only the panel's close button ends it. Because the composer stays usable, /btw can now arrive while an answer is still coming, so a thread answers one question at a time and asks the next with the earlier answer as history.

Web, through the session list (the answer reached the app 7.6 s after leaving):

Android emulator, x86_64 debug build, through Back (answer 12 s after leaving; with the keyboard up the panel shrinks and keeps its field visible):

Re-verified on this head: app typecheck clean, the side-question tests plus the new sideQuestionThreads.spec.ts pass, and a scripted live run passed 25/25 checks. The PR description now describes the panel.

[chphch]

Follow-up commit: a bare /btw answers with its usage

4783bd2 matches Claude Code for /btw with no question. Claude Code 2.1.301 replies Usage: /btw <your question> and asks nothing; the app used to open an empty panel instead. Now the same line shows in the chat as a notice that stays on the device (it never reaches the agent or the server, via a small sync.showLocalNotice), and no panel opens. The panel's focus request and its empty-thread placeholder had no other use, so they are gone.

Live run on a local stack with a paired daemon: a bare /btw showed the line once, opened no panel and cleared the composer, and /btw what is one plus one still opened the panel (5/5 checks). The side-question tests, including a new one for the bare case, pass, and the app typecheck is clean.

[chphch]

Follow-up commit: copy a /btw answer into the chat

8c3acd1 adds what Claude Code's panel offers as c to copy. In Claude Code 2.1.301 that key copies the answer alone, without the question, so it can go into the main conversation. Each answer in the side panel now carries the same copy button the chat's own messages use (MessageCopyButton, exported from MessageView for this): it copies the answer text and shows a tick for a moment. A canned stand-in answer has none.

Live run on a local stack with a paired daemon and real Claude (8/8 checks): /btw In one short sentence: what is two plus two? came back as "Four.", the button switched to "Copied", the clipboard held Four. and not the question, and Cmd+V in the chat composer pasted exactly that. App typecheck is clean and the side-question tests pass.

[chphch]

Withdrawn: continue a /btw question in a new session

Removed from this PR: the button's commit and its revert cancelled each other out, so a force-push dropped both, and the branch is back at 7b46adb with the same code as before the button. The button forked the chat into a new session, which is not what Claude Code's f does: there the question goes to a forked subagent and the answer comes back into the main conversation. The app has no way to start that subagent (the SDK has no request for it, and /fork and /subtask are unavailable headless), so the button is gone rather than standing in for something it isn't.

[chphch]

The failing smoke-test-linux (20) check is not caused by this PR. Since vitest 4.1.12 was published on 2026-10-15, npm 10 (the npm Node 20 ships) crashes while installing the packed happy-server-self-host, and packs built from main crash the same way. #1905 fixes the workflow by upgrading npm on the Node 20 leg; the cause and the reproduction are in its description.