Repository navigation
[Bug]: A typed answer to an agent question is lost when you open a new thread #13856
Description
Activity
Confirmed on
main@95030dc67, the commit in the report. Still present. Checked from source only; this was not re-run in a client.The custom answer, selected options, and current question index live in
ChatViewstate:pendingUserInputAnswersByRequestIdandpendingUserInputQuestionIndexByRequestId(apps/web/src/components/ChatView.tsx:1755-1759). Typing writes the answer there (ChatView.tsx:8848-8854). The key isJSON.stringify([environmentId, threadId, requestId])(ChatView.tsx:2946-2950). Nothing else stores that text.New thread goes to
/draft/$draftId.ThreadRouteViewmounts a separateChatViewkeyed bydraftId(apps/web/src/components/ThreadRouteView.tsx:184-194). The thread you left unmounts, and that state goes with it. Coming back mounts a newChatView. The question is still pending because it lives on the thread, so the composer shows the question again with an empty answer.A normal composer draft survives because it is in the persisted composer draft store, not in
ChatView. Question attachments are already in that store (questionAttachmentDraftId), so those should still be there after the same navigation. The typed text, option selections, and which question you were on are not.Switching between two already-started threads does not hit this. Those routes share one unkeyed
ChatView(ThreadRouteView.tsx:41-42), and the map is keyed by thread. Leaving the thread route entirely does: settings and pull requests render<Outlet />instead ofThreadRouteView(apps/web/src/routes/_chat.tsx:203), so the same state is dropped.This is the web composer, so the desktop app and the website both hit it. Mobile already keeps these drafts in a keep-alive atom (
apps/mobile/src/state/use-selected-thread-requests.ts:38-40), outside the screen.Not a duplicate of #12569. That was clicking an option inside the thread, and #12577 puts the typed text back into the thread draft (
carryDisplacedCustomAnswerIntoPrompt). This path never gets there, because the component is gone. Not a duplicate of #13334 either: that is an unsaved citation comment discarded when a question replaces the editor document.The report's direction is right: keep the answers outside
ChatView, keyed by environment, thread, and request, and clear them when the question is answered or dismissed. There is no clear today, because the state dies with the component and is ignored once the request is no longer pending. A module-level map is enough for this remount (same reason painted timelines are remembered outsideChatView). The composer draft store would also survive a reload, which a normal draft already does.
Before submitting
Area
apps/web
Steps to reproduce
/grill-me-with-docswith Claude Code.Expected behavior
The answer you were typing is still in the composer, the same as for a normal message. If you type a normal message (no question pending), click New thread, and come back, the text is still there.
Actual behavior
The composer shows the question with an empty custom answer. Everything you typed is gone and can't be recovered.
This only happens while a question is pending. The normal composer draft for the same thread survives the same navigation.
Impact
Major degradation or frequent failure
In long question-and-answer sessions it's common to be halfway through a detailed answer and open another thread for a new idea. When you come back, the answer has to be rewritten from memory.
Version or commit
Source checked at
main@95030dc67.Environment
Provider: Claude Code.
Logs or stack traces
None. The text is lost silently, with no error.
Source notes
ChatView, not in the per-thread composer draft store (pendingUserInputAnswersByRequestId,pendingUserInputQuestionIndexByRequestId): https://github.com/pingdotgg/t3code/blob/95030dc67/apps/web/src/components/ChatView.tsx#L1755-L1759ThreadRouteViewrenders a differentChatViewelement there, keyed bydraftId. The old thread'sChatViewunmounts and its question state goes with it: https://github.com/pingdotgg/t3code/blob/95030dc67/apps/web/src/components/ThreadRouteView.tsx#L183-L208A likely fix is to keep the question answers in the per-thread draft store, keyed by thread and request ID, instead of in component state. The saved answer would also need to be cleared once the question is answered or dismissed.
Related issues
Workaround
Paste the answer somewhere else before opening another thread, or finish and send the answer first.
Drafted with Claude Opus 5.5 in Claude Code (via T3 Code).