[Bug]: Clicking a question option discards text typed into the composer

[myfunc]

Area

apps/web (shared desktop composer)

Summary

While an agent is running, a structured question (single-choice options plus an editable answer field) takes over the composer. If I type into the composer while that question is active and then click one of the options, the text I typed is discarded immediately. Nothing brings it back: it is not in the thread draft, not in the answer, not in the message sent to the agent.

Steps to reproduce

1. Start a Claude Code task (desktop app, Windows) and wait for the agent to work.
2. Start typing a follow-up in the composer.
3. The agent issues an AskUserQuestion-style question with several options.
4. Type (or continue typing) some text into the composer. With the question active, the composer edits the question's custom answer.
5. Click one of the options.

Expected behavior

Choosing an option must not destroy text the user has typed. Either the text stays visible (as clarification or as the pending follow-up message), or it moves back to the thread draft. The user decides what to do with it.

Actual behavior

The composer is emptied the moment an option is clicked. The typed text is gone with no recovery path.

Source

Confirmed from source at dfbb11bdd7c3f1a5575cb55d3e3abb12be025727 (main), same code as the installed build.

• Selecting an option rebuilds the draft answer with customAnswer: "", so any text typed into the answer field is dropped by design:

  t3code/apps/web/src/pendingUserInput.ts

  Lines 96 to 106 in dfbb11b

  	return {
  	customAnswer: "",
  	...(nextSelectedOptionValues.length > 0
  	? { selectedOptionValues: nextSelectedOptionValues }
  	: {}),
  	};
  	}
  	return {
  	customAnswer: "",
  	selectedOptionValues: [optionValue],

• The option handler in ChatView also resets the shared prompt ref to an empty string:

  t3code/apps/web/src/components/ChatView.tsx

  Line 8835 in dfbb11b

  promptRef.current = "";

• The editor is bound to activePendingProgress.customAnswer while a question is active, so the emptied answer is what the user sees:

  t3code/apps/web/src/components/chat/ChatComposer.tsx

  Lines 6806 to 6811 in dfbb11b

  	isComposerApprovalState
  	? ""
  	: activePendingProgress
  	? activePendingProgress.customAnswer
  	: prompt
  	}

The behaviour dates back to the original user-input implementation (12edc3455) and is covered by unit tests as intended (togglePendingUserInputOptionSelection returns customAnswer: ""). The design reason is that a non-empty custom answer takes precedence over selected options in resolvePendingUserInputAnswer, so the two are treated as mutually exclusive. That makes sense for the answer model, but it turns a click into silent data loss for text the user was composing.

Relation to existing issues

• [Bug]: Incoming agent questions replace an unfinished message and redirect subsequent typing #11116 (accepted) covers the wider takeover: the composer switches to the question answer and Send routes to the question. This report is the destructive sub-case: even under the current takeover model, clicking an option should not delete typed text. A small fix is possible without the redesign (for example, move a non-empty custom answer back into the thread draft when an option is selected, instead of discarding it).
• [BUG] Textarea being reset #808 (closed) reported the reset when the question appears; that text is preserved in the thread draft. This case is different: the text is lost.

Impact

Major degradation or frequent failure. Typing while the agent works is normal use, and a single click deletes the message.

Version or commit

Installed desktop build 0.0.42 (t3codeCommitHash 719a76ca1dbf). Source checked at dfbb11bdd.

Environment

Windows 11 Home 10.0.26200, T3 Code desktop (Alpha), provider Claude Code.

Workaround

Do not type while a question is active, or press Send with the typed text as the custom answer instead of clicking an option.

_{^{lovely composed in pair with Claude Fable 5.1 in Claude Code}}

[juliusmarminge]

Triage

Confirmed in current main (dfbb11bdd). This is not a duplicate of #11116. That ticket is the composer takeover (thread draft is kept; Send routes to the question). This ticket is the destructive sub-case: text typed while the question is active is the question's customAnswer, and clicking an option deletes it. Nothing writes that text back to the thread draft.

What happens

While a pending user-input question is active, the shared web/desktop composer is bound to the question answer, not the thread draft:

1. ChatComposer sets the editor value to activePendingProgress.customAnswer.
2. onPromptChange writes keystrokes through onChangeActivePendingUserInputCustomAnswer and returns before setPrompt.
3. Clicking an option calls togglePendingUserInputOptionSelection, which always rebuilds the draft with customAnswer: "".
4. onSelectActivePendingUserInputOption also sets promptRef.current = "" and resets the cursor.

resolvePendingUserInputAnswer prefers a non-empty custom answer over selected options, so the two are treated as mutually exclusive. That is a reasonable answer model. The bug is that option selection implements exclusivity by deleting the typed text instead of moving it.

For single-select questions the loss is immediate: ComposerPendingUserInputPanel.handleOptionSelection auto-advances ~200ms after the click, and on the last question that submits the option. The typed text is not in the thread draft, not in the submitted answer, and not recoverable.

Unit tests encode the wipe as intended (togglePendingUserInputOptionSelection returns customAnswer: ""). The behaviour has been in the answer helper since multi-select landed (11d456f6c).

Surfaces

• Web / desktop: shared composer path above. Desktop is the reported surface.
• Mobile: not a composer takeover (dedicated PendingUserInputCard field), but the same helper in apps/mobile/src/lib/threadActivity.ts still sets customAnswer: "" on option press, so typed custom-answer text is discarded there too.

Related work

Item	Relevance
#11116 (open, accepted)	Takeover / Send routing. Draft typed before the question is preserved. Does not track this wipe.
#808 (closed)	Reset when the question appears. That text returns with the thread draft.
#809 (closed)	Closest redesign: keep the main composer on the thread draft; answer on the question card.
#8963 / #9117 (open)	Typed text lost on Stop during a pending prompt. Same class of loss, different trigger.

Not marking as duplicate of #11116. Fixing the takeover would also prevent this, but this ticket has its own success criterion and a smaller fix that does not require that redesign.

Recommended direction

Selecting an option must not destroy non-empty typed text. Smallest fix, still under the current takeover model:

• When togglePendingUserInputOptionSelection / onSelectActivePendingUserInputOption clears customAnswer, park that string on the thread draft (and do not zero promptRef until it is parked).
• Keep custom vs option exclusivity in resolvePendingUserInputAnswer so the clicked option is what gets submitted.
• Apply the same park-don't-delete rule to the mobile copy in threadActivity.ts.
• Update the unit tests that currently require customAnswer: "" with no relocation.

#11116 remains the longer-term fix (question UI should not own the focused editor or Send).

[myfunc]

Reproduced on a local dev build from dfbb11bdd (web client, Claude Code provider, Windows 11):

1. Agent asks a single-choice AskUserQuestion (three options).
2. Type into the composer while the question is active.
3. Click an option. On the last question this submits immediately.

Result on main: the typed text is gone. It is not in the answer, not in the thread draft, not in any message.

A small fix that keeps the current answer model works: when an option is selected and the custom answer field holds text, move that text into the thread draft (appended after whatever was already drafted) instead of dropping it. After the question clears, the text is back in the composer and Send submits the whole message. The same change also resyncs the composer's shared prompt ref when the question clears; until then the ref kept the last answer text while the editor showed the thread draft, so a Send with no further typing read the wrong value.

Verified on the dev build: text typed during the question survives the option click and is sent as the follow-up message. Fix is in #12575.

_{^{lovely composed in pair with Claude Fable 5.1 in Claude Code}}

[cestercian]

Working on a fix so clicking a question option does not discard composer text.