[Bug]: Incoming agent questions replace an unfinished message and redirect subsequent typing #11116
Description
Area
apps/web, including the shared desktop composer.
Summary
When an agent asks a question while I am halfway through typing, the composer switches to a separate, empty question answer. If I keep typing and press Send, only the text entered after the question arrived reaches the agent. The first half remains in the original draft.
This breaks the meaning of the message I was composing. That draft might already answer the question, clarify its premise, or give an instruction that makes the question unnecessary. T3 cannot assume that text is unrelated and move my ongoing input into a different answer.
Steps to reproduce
- Start a Codex task and, while the agent is running, begin typing a follow-up in the composer.
- Have the agent issue a structured question before you finish typing. Observed with the newer question flow while Codex continues working.
- Continue typing without deliberately changing input fields or choosing to answer the question.
- Press Send.
- After the question clears, inspect the original draft and the message sent to the agent.
Expected behavior
A question arriving leaves the current text, cursor, focus, and send behavior intact. Continued typing completes the same message, and sending includes the whole message.
Questions and suggested answers can appear without taking over the composer. The user decides whether their message answers, clarifies, or supersedes the question.
Actual behavior
The interaction feels like two composers: one retains the unfinished prompt, while a clean one receives subsequent typing. Sending submits the second half as a question answer. The original draft reappears after the question clears.
Preserving the first half in storage does not preserve the composition. The user has already sent an incomplete message and has to reconstruct what they intended to say.
Impact
Major degradation or frequent failure. Typing while an agent works can silently produce an incomplete instruction.
Version or commit
Source investigated at 061543e9e5b54ec0048725c37d52fef2962df173. The installed version at the time of the reported occurrence was not captured.
Environment and supporting evidence
Observed with Codex. Source inspection identifies shared web/desktop behavior with no provider-specific guard:
- ChatComposer changes the editor value from the message draft to the pending question's custom answer.
- Subsequent edits update the question answer instead of the message draft.
- Send advances/submits the pending question before reaching the normal message path.
The literal appearance of two simultaneous editors has not been reproduced independently. The source confirms the automatic switch between separate drafts and submission paths. No browser reproduction or recording is attached.
Related issue
#808 reports the same interruption, including that the text already being typed could answer the incoming question. It was closed because normal drafts and question answers were stored separately.
This report follows up on the unresolved UX behavior: keeping two drafts does not fix the automatic replacement of active input or the change in what Send submits. Please assess composition continuity, not just whether the original text can be recovered.
Activity
juliusmarminge commentedon Sep 10, 2026
Triage
Confirmed in current
main(502131adf). This is the same interruption as #808, but #808 was closed because the thread draft and the question answer are stored separately. That isolation is real — and it is also why this feels like two composers. Storage continuity is not composition continuity.What happens
When a pending user-input question becomes active (including Codex async questions that arrive while the turn continues):
ChatComposerbinds the editor toactivePendingProgress.customAnswerinstead of the thread draft.onChangeActivePendingUserInputCustomAnswer.ChatViewadvances/submits the pending question and never reaches the normal message path.The first half of the in-progress message stays in the original draft and comes back after the question clears. Send has already gone out as only the text typed after the switch.
Source (current lines; same design as the cited
061543e9):apps/web/src/components/chat/ChatComposer.tsx(editorvalueandonPromptChange)apps/web/src/components/ChatView.tsx(if (activePendingProgress) { onAdvanceActivePendingUserInput(); return; })apps/web/src/pendingUserInput.tspackages/client-runtime/src/pendingRequests.ts,docs/user/providers-codex.mdDesktop shares this composer. Mobile is a related, stronger takeover (the questionnaire replaces the composer slot).
Related work
Not marking as duplicate of #808. That ticket is closed as resolved for a different success criterion.
Recommended direction
A question should appear without taking the focused editor, cursor, or Send. The in-progress message stays the in-progress message. Options, dismiss (async), and an explicit “answer this question” path can live on the question panel. The user decides whether their text answers, clarifies, or supersedes the question.
#9117 is worth landing for cancel/Stop draft loss, but it still accepts the takeover.
Labels
bug,accepted,via-triage(removeneeds-triage)josephv123 commentedon Sep 29, 2026
+1, I'm hitting this too, and not only with Codex. It also happens with the Claude provider on macOS desktop when Claude calls
AskUserQuestion.What I see: I'm partway through typing a prompt, the question UI shows up, and the rest of what I type goes into the question's custom-answer field. After I finish answering, the prompt I started earlier comes back in the composer as a saved draft. This is confusing when I was already trying to send something to the model, because my message ends up split between the answer and the leftover draft.
I agree with the direction in the triage comment: an incoming question shouldn't take over the focused editor or Send.
juliusmarminge commentedon Oct 9, 2026
Note
Grok responding on behalf of Julius.
Fixed by #17637, which just landed on
main. Pending questions and approvals now wait while you're typing in the focused composer, and only appear after 1.5 seconds of idle time, a send or queue, or blur, so the rest of your message no longer gets redirected into the question answer. Closing this out; if you still see a question take over mid-sentence on a build that includes #17637, reply here and we'll reopen.