request_user_input_async question card is auto-dismissed when the turn's final message renders, leaving the question unanswerable

Version / environment

ChatGPT desktop app 26.901.51231 (Codex bundled runtime; model GPT-6-Astra), macOS
Subscription: ChatGPT Pro
Platform: Darwin 25.5.0 arm64 arm (macOS, Apple Silicon)

What issue are you seeing?

When Codex (GPT-6-Astra) asks a clarification question via the request_user_input_async tool in Default mode, the question card renders correctly while the turn is running. But the moment the assistant's final answer message begins rendering, the card is automatically dismissed — it is not pinned to the thread and is not rendered as a persistent message bubble.

The final message then references the now-invisible question (e.g. "Please answer the platform-scope questions above and I'll continue"), leaving the user with no way to review the question content or answer it.

Reproduced 3/3 times on 2026-09-08. The card is only visible for ~7 seconds before the turn completes (turns end in 16–18s because no work can proceed without the answer).

The rollout JSONL shows the async AgentMessage is delivered with full fallback text (content[]) and questions[] metadata (delivery: "async"), but the desktop client does not persist that message after task_complete.

Steps to reproduce

In the Codex desktop app (Default mode, not Plan mode), start a task with an up-front clarification need, e.g. send: "Before you start, ask me which platforms this feature should support."
Codex calls request_user_input_async; the question card appears in the conversation.
The tool immediately returns {"accepted":true} (async, non-blocking). With no answer-independent work to do, the model emits its final message ~7 seconds later.
When the final message starts rendering, the question card is dismissed and removed from view. The turn completes (task_complete, ~18s total).
The final message references "the questions above", but no question remains visible — the user cannot review or answer.

Rollout JSONL evidence (session 2026-09-08, UTC):

11:29:58.7 function_call request_user_input_async (2 questions)
11:29:59.2 function_call_output {"accepted":true}
item_completed AgentMessage: delivery="async", full fallback text in content[], questions[] metadata present
11:30:06 final message + task_complete (duration 18.4s)
No user reply exists after any of the 3 async questions in the session — the cards vanished before they could be answered.

thread_id: 01a080c7-e967-7921-8dcb-9054b86880ac

Expected behavior

An unanswered async question should remain available after the turn ends: either as a persistent, answerable card pinned to the thread, or at minimum rendered as a normal message bubble using the fallback text that is already present in the AgentMessage (content[] / questions[] exist in the rollout data).

The card's lifecycle should be tied to "question is unanswered" rather than "turn is still running". Final messages must not reference question content that is no longer visible.

Additional information

request_user_input_async was introduced in Codex 0.153.0 (PR Add structured asynchronous user input requests #42178); hotfixes [0.153 hotfix] Update Astra async-question guidance #42809 and [0.153 hotfix] Qualify Astra async-question guidance by tool availability #42878 adjusted Astra's guidance around async questions. This report is specifically about the desktop client's rendering lifecycle of the async AgentMessage — the question data reaches the client correctly, but the UI unloads the card when the final message renders.
Workaround: forcing the synchronous request_user_input tool (via config flag default_mode_request_user_input=true plus AGENTS.md instructions) blocks the turn until answered, which avoids the card being unloaded.
In-app feedback was also submitted from the app (no feedback ID was shown after submission).

Potential duplicates detected. Please review them and close your issue if it is a duplicate.

Codex desktop: pending question interface disappears after switching tabs and does not return #43057

Powered by Codex Action

Reviewed #43057 — related but not a duplicate, and this report may help isolate the open question in that thread.

Codex desktop: pending question interface disappears after switching tabs and does not return #43057: the pending card disappears after switching tabs (trigger: tab switch).
This issue (request_user_input_async question card is auto-dismissed when the turn's final message renders, leaving the question unanswerable #43803): the card is dismissed when the turn's final message renders / task_complete, with no tab switching involved. Reproduced 3/3, with rollout JSONL evidence (async AgentMessage contains full fallback text + questions[] but is not persisted after the turn ends).

#43057 explicitly notes that "whether assistant completion affects this behavior have not yet been isolated" — the reproduction here isolates exactly that: assistant turn completion alone unloads the card, even without tab switching. The shared root cause appears to be that the async question card is scoped to the active turn/view rather than to the unanswered question state (related: #32458, timed auto-dismissal in the VS Code extension).

Happy to consolidate if maintainers prefer tracking these together; otherwise keeping this open as it provides a distinct, no-interaction reproduction path plus rollout evidence.

I'm having the same issue. I have to ask Codex to keep the turn open so that the question picker stays active.

Additional user report on ChatGPT desktop 26.908.40834, macOS 26.3.1 (Apple Silicon Mac Studio), September 14, 2026.

An unanswered request_user_input_async question contained a Terminal command to run on a second computer (a MacBook Pro). The user copied the command, ran it there, and returned to find the question gone, with no apparent way to reopen or answer it. The user frequently steps away while the assistant works, so a transient question card makes this workflow unreliable.

This is a user-observed occurrence, not an independently reproduced test. We have not isolated whether turn completion, switching context, or another event caused the disappearance, so it may also relate to #43057.

Requested behavior:

Keep unanswered questions accessible until answered or explicitly dismissed, including after the assistant finishes its turn.
Preserve the full question text and any commands in durable conversation history.
Provide a persistent pending-question indicator and a way to reopen and answer a question later.
Retain answered or dismissed questions in history so their context is not lost.

Submitted on the affected user's behalf with their authorization. The report was also provided through the official Help Center chat, which could not supply a case number or email follow-up and pointed to GitHub for a tracked report.

Additional reproduction data point (Codex desktop app, macOS, Default mode, 2026-09-15/16):

Multiple tasks in one session called request_user_input_async with a single question and 2-3 suggested options. The card renders while the turn is running, then becomes unanswerable once the turn's final message renders - same behavior as described above (the ~7s visibility window matches our experience).
Re-sending the identical question 2-3 times in the same session only occasionally produced an answerable card. When an answer did come through, it arrived as a <send_user_message_question_reply> user message.
Synchronous fallback is unavailable outside Plan mode: calling request_user_input in Default mode returns request_user_input is unavailable in Default mode, so there is no blocking/wait-for-reply variant to switch to.
Impact example: confirmation-heavy flows (per-item contract confirmations, and a workspace rule that requires an explicit backup/no-backup choice before running mutating SQL) silently lose the user's answer and have to be re-asked as plain text.

Workaround in use: treat the async card as best-effort - if it disappears, repeat the question in the final message and collect the answer as ordinary chat text.

Suggestion (same as OP): persist the async question as a durable, answerable message after task_complete, or document its lifetime/hide conditions and offer a wait-for-reply mode outside Plan mode.

补充 Windows 桌面端复现（2026-09-23，桌面应用自报版本 26.917.51856）：

默认模式调用 request_user_input_async 后返回 {"accepted":true}，选项正常出现。
用户确认可以进入该交互并看到选项，但浮层不会常驻；收起后需要在任务中自行寻找。尚未独立验证选项收起后的提交结果，因此不主张“选项被销毁”或“必定无法回答”。
本机只读检查显示，当前客户端给浮层设置约 30 秒的展开期限，并在轮次结束时收起当前选中的问题。原始会话仅证明受理回执先于轮次结束，不能单凭该顺序认定问题数据丢失。
期望未回答的问题持续明显可见，或至少保留固定、易发现的待回答入口，直到用户提交、跳过或主动关闭。

此评论不含账号信息、令牌、私有项目内容或原始日志。与本问题原报告的区别是：本机用户能够重新找到选项，主要障碍是入口不常驻、不醒目。

Another macOS Codex app user is hitting this repeatedly during a long-running task. request_user_input_async presents a question or approval-looking choice for a moment, then the card disappears. There is no persistent pending-question indicator or obvious way to find and answer it afterward. The agent can appear to be sitting idle, waiting for input the user cannot see. In this case, the user had to ask repeatedly whether they were blocking the task and where the requested action was.

This is a workflow failure, not just a cosmetic one: the question may concern deployment approval or a decision, so losing it leaves the user unable to tell what has been authorized or what is holding up progress. The agent has worked around it by putting required decisions in ordinary chat messages and ending the turn clearly, but the app should preserve unanswered questions and show a durable, actionable "needs your input" state in the task/sidebar until they are answered or dismissed. The UI should also distinguish a question posed from an approval actually granted.

No private task content or logs are included here. This is reported at the affected user's explicit request.

Additional affected-user report from a long-running Codex desktop task (2026-09-23). The user explicitly asked that this be reported.

Questions sent with functions.request_user_input_async sometimes disappear from the user's view. The user described the failure as “you asked something and it’s gone.” The trigger was not isolated; I cannot say whether turn completion, navigation, or another event caused it in this occurrence.
The user also reported pressing Answer on interactive questions, then seeing the assistant continue as if no answer had arrived: “questions dissapear or i press answer and you don’t get it”. This is the user's observation, not proof that a submitted answer was lost in transport. There is no captured client/server trace or deterministic reproduction for this path.
Delivery is intermittent in this task: some answers did reach the agent as <send_user_message_question_reply> messages. When no answer appeared, the agent sometimes treated the question as unanswered and asked again.

Expected: unanswered question cards remain accessible until resolved; after submission, the UI clearly shows whether the answer is pending or delivered; a submitted answer reaches the active task reliably. If delivery fails, the user and agent should see a recoverable error rather than silently disagreeing about the question state.

Read-only environment check on the reporting Mac: installed /Applications/ChatGPT.app version 26.917.51856 (build 10492); macOS 26.5.1 (Darwin 25.5.0 arm64). The exact app build at the earlier affected moments was not independently recorded. Frequency and exact reproduction steps are unknown. The disappearance and apparent missed-answer symptoms may or may not share a cause. No private task content, logs, or screenshots are included.

Same behavior here: the question stays available while the assistant continues working, but when the assistant's turn ends with a question, the card closes. Mid-turn questions don't close this way.

Additional user-reported occurrence on ChatGPT desktop 26.915.31945 (Codex task), macOS 26.4, Darwin 25.4.0 arm64 arm, September 27, 2026 (America/Denver).

Sequence observed in the task:

The assistant called request_user_input_async with a free-text request for the user to complete an external sign-in.
The tool returned {"accepted":true}.
The assistant continued independent work, then sent a final response while the request remained unanswered.
The user subsequently reported that they could not approve/complete the last request on their laptop.

This is consistent with the lifecycle issue described here, but the disappearance itself was not independently captured on the laptop. The request was a sign-in handoff, not a tool-permission approval, which also caused confusion. The assistant referred to a browser window being open; its availability on the user's laptop was not established.

Please investigate whether unanswered free-text async requests in this app version remain reachable after the final response, and clearly distinguish them from permission approvals. No account details, credentials, project contents, or private logs are included.

I think the lifecycle boundary here is slightly different from a rendering bug:

accepted: true is admission of the async question, not resolution of the human obligation.

That suggests the card should be owned by the unresolved question, not by the assistant turn that happened to create it.

A minimal state machine would be:

question_created
→ pending_human_input
→ answered | dismissed | expired | cancelled | replaced

and importantly:

task_complete != question_resolved
final_message != question_resolved
tab switch     != question_resolved

So if the turn finishes while the question is still pending, the client should still have an authoritative pending object to render/reopen.

This also helps with the reports above where a user clicks Answer but the agent later behaves as if nothing arrived: the UI can distinguish at least three states instead of one transient card:

pending
answer_submitted
answer_delivered/resolved

If submission fails, the boundary stays recoverable rather than silently disappearing.

This seems closely related to #39426's proposed output-only human-input lifecycle. A core-owned opaque request ID plus a paired clear/resolution event would let the desktop UI, sidebar, and passive observers all converge on the same source of truth without inferring state from whether the turn is still rendering.

I would also keep machine cleanup semantically distinct from a human answer: timeout/cancellation/turn teardown should clear with explicit non-human provenance, not look like the question was answered.

I implemented that last invariant in a small control-plane prototype after seeing the same class of ambiguity in approval flows:
hippoley/HumanQueue#17

The project itself is not the proposed fix here; the useful part is the state-machine constraint: an unanswered human boundary must outlive the turn that created it.

Additional affected-user report, 2026-10-01, macOS. Submitted at the user's explicit request.

Current installed desktop bundle: com.openai.codex, version 26.928.31416, build 12553; macOS 27.0. This is the version checked during this investigation, not proof of the build used for every earlier occurrence.

The user reports that outside Plan mode, an Ask question card disappears shortly after it appears; if they do not click promptly, they cannot find an obvious button to reopen and answer it.

Evidence from two existing tasks:

In today's affected task, the recorded sequence is a structured question with three options, immediately followed by a final message telling the user to choose "above". The turn is completed/idle, and no human answer appears in the retrieved task record. The user reports that the choice UI is no longer accessible. This matches the final-message sequence in this issue; it is not an independently captured visual reproduction.
In a separate task on September 28, a test deliberately kept the assistant turn running. The user explicitly answered: "The card automatically collapses; I need to find it again before I can submit." That answer did reach the assistant as a structured question reply. Keeping the turn running therefore did not ensure that the card stayed expanded, but collapse did not necessarily destroy the question or its answer channel.

Please distinguish question persistence from overlay expansion/discoverability. We are not claiming all collapsed questions are deleted, or that a specific timer caused today's occurrence.

Requested behavior:

Keep a persistent, clearly labelled "Pending questions / Answer / Reopen" control in the originating task (and ideally an attention badge in the sidebar) until the user answers or explicitly dismisses the question.
Preserve question text and options in durable chat history across final messages, turn completion, and navigation.
Reopening should restore an actionable question and any unsent draft. If an existing reopen control is intended to do this, please document its location and investigate why it is not discoverable in this case.
Distinguish pending, submitted, delivered, and dismissed states. Neither accepted:true nor collapse/turn completion should count as a human answer.
Please confirm the tracking issue and any fixed version or supported workaround. Requiring Plan mode or repeated re-asking is disruptive for ordinary asynchronous tasks.

Evidence limit: the official computer-use tool disallows inspection of the Codex app itself in this session, so the current button location and visual disappearance could not be independently verified. No private task IDs, project contents, transcripts, screenshots, or raw logs are attached. Related: #43057 and #48563.

I can reproduce what appears to be the same issue on a newer version of Codex Desktop for macOS.

Environment

Codex Desktop: 26.928.31416
Platform: macOS

Reproduction

The assistant shows a user-choice card and asks the user to select an option.
Before the user finishes answering, the assistant continues generating text.
The assistant continues for about 5 seconds and then finishes the turn.
At the exact moment the turn finishes, I hear a macOS-style “dong” notification sound.
The pending choice card immediately disappears.
Since I have not finished selecting an answer, there is no longer any way to complete the interaction.

Observed behavior

The pending user-input card is removed when the assistant finishes the turn, even though the user has not completed the selection.

Expected behavior

The user-input card should remain visible and interactive until one of the following happens:

The user submits an answer.
The user explicitly cancels/dismisses it.
The request is explicitly invalidated by the assistant/system.

Finishing the assistant turn should not automatically remove an unanswered input card.

Additional observation

There is a notification sound at almost exactly the same moment the card disappears.

I have not confirmed whether the sound itself is related to the bug. It may simply be the normal macOS/Codex turn-completed notification occurring at the same time.

The behavior strongly suggests that the pending input UI may be tied to the assistant turn lifecycle (task_complete / turn completion), rather than to whether the input request has actually been answered.

Useful reproduction case

Trigger an async user-input / choice card.
Do not wait for the user to answer.
Continue assistant output for roughly 5 seconds.
Finish the turn.
Check whether the unanswered card is removed when the turn completes.

This is still reproducible on Codex Desktop 26.928.31416.

Additional user-confirmed occurrence on 2026-10-01 in the Codex desktop app on macOS (Default mode). The user explicitly requested that this UI bug be reported.

Observed sequence:

The assistant called request_user_input_async with four questions. The tool returned {"accepted":true}.
The user reported that the selection UI appeared only briefly, then disappeared; repeating the four-question call did not make it persist.
A retry with just one question allowed one structured answer on one attempt. Subsequent single-question attempts again appeared briefly and vanished before the user could answer.
We switched to persistent ordinary chat text, and the user successfully supplied the requested answers there.

This corroborates the disappearing/unanswerable question-card symptom. The exact client event causing dismissal was not independently instrumented, so this report does not assert that final-message rendering is the sole trigger. Exact app/runtime versions and a clean-session reproduction have not been collected.

Expected: an unanswered question remains visible and answerable after the assistant turn ends, or the question is retained as normal transcript text with a usable fallback. accepted must not be confused with a submitted answer.

No private project contents, session transcript, credentials, screenshots, or logs are included.

Additional occurrence reported on 2026-10-02 in the desktop app.

Environment read from the installed application metadata:

App version: 26.928.40906, build 12694.
Display name: ChatGPT; bundle identifier: com.openai.codex.
macOS 27.0.1 (26A434), Apple Silicon; uname -mprs: Darwin 27.0.0 arm64 arm.

Observed conversation sequence:

The user requested clickable multiple-choice questions to make five pending decisions.
The assistant called request_user_input_async with five questions, each containing three options.
The tool returned {"accepted":true}.
The assistant emitted its final response referring to the question cards above.
The user reported that every on-screen question with options closes automatically, preventing the decision workflow from being completed, and requested that the bug be reported to OpenAI.

The user-visible disappearance is reported by the user; its exact timing was not independently observed through UI automation. The tool call, accepted response, final message, and subsequent user report are present in the conversation. No answer to this batch was received.

Expected: unanswered question cards remain readable and answerable after turn completion, or can be reopened from the conversation. Missing input must not be treated as acceptance of the recommended/preselected option.

This appears consistent with this issue and #45646, and occurs on a newer desktop version. No private project content, session transcript, screenshots, or logs are attached.

Additional Windows reproduction on 2026-10-07, submitted at the affected user's explicit request.

Environment:

Codex desktop app on Windows, Default mode.
Model shown in the affected conversation: GPT-6.1 Sol, Medium.
A related affected conversation's rollout reports bundled Codex runtime 0.160.1. The desktop app version/build has not been independently collected.

Observed comparison in the same troubleshooting conversation:

The assistant called request_user_input_async with one question and three suggested options. The tool returned {"accepted":true}.
The assistant immediately finished its turn with a final message telling the user that the question had been sent.
The user reported that the card appeared briefly and then disappeared. Their screenshot after completion shows the final message and normal composer, without the question card.
The assistant issued a second single question with two options, received {"accepted":true}, and deliberately kept the turn running while waiting.
The user selected the option meaning "Yes, it stays visible now." The answer reached the assistant as a structured send_user_message_question_reply message.
A user-provided screenshot of this second attempt shows the visible Question card, both clickable options, and Send/Skip controls while the assistant is still running.

A preceding conversation also recorded two accepted async question calls followed by final messages, after which the user reported that the options were not available.

This comparison supports an association with turn completion, but we have not instrumented the frontend dismissal event or established its implementation-level cause. We also have not established whether the first question was deleted or merely collapsed into an undiscoverable state. Keeping the turn open worked for the short second test; it does not establish persistence over longer waits.

Expected: an unanswered question should remain visibly answerable after the assistant completes its turn, or have a clearly discoverable persistent reopen/answer control. Preserve the question text/options in the transcript. accepted:true must not be treated as a human answer.

This adds Windows/GPT-6.1 Sol evidence to this existing issue. Screenshots were inspected locally; raw logs, screenshots, private project content, local paths, account information, and conversation identifiers are not attached.

Navigation Menu

Repository navigation

request_user_input_async question card is auto-dismissed when the turn's final message renders, leaving the question unanswerable #43803

Version / environment

What issue are you seeing?

Steps to reproduce

Expected behavior

Additional information

Environment

Reproduction

Observed behavior

Expected behavior

Additional observation

Useful reproduction case

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

request_user_input_async question card is auto-dismissed when the turn's final message renders, leaving the question unanswerable #43803

Description

Version / environment

What issue are you seeing?

Steps to reproduce

Expected behavior

Additional information

Activity

github-actions commented on Sep 8, 2026

ZhangWen-Leo commented on Sep 8, 2026

wadejbeckett commented on Sep 10, 2026

gitFactoryAI commented on Sep 14, 2026

zhang19980518 commented on Sep 16, 2026

sociaphobia commented on Sep 23, 2026

NikTarasov commented on Sep 23, 2026

rexsacrorum commented on Sep 23, 2026

rafaself commented on Sep 24, 2026

ehcsual commented on Sep 27, 2026

hippoley commented on Sep 28, 2026

felixlark commented on Oct 1, 2026

jasonblack1027 commented on Oct 1, 2026

Environment

Reproduction

Observed behavior

Expected behavior

Additional observation

Useful reproduction case

duesentriebsrakete commented on Oct 1, 2026

edercnj-llm commented on Oct 2, 2026

Cemilcanoz commented on Oct 7, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions