Repository navigation
[Bug]: Thread shows Input for pending async questions that are not visible in the conversation #25806
Description
Before submitting
- I searched open and closed issues and relevant discussions; related reports are distinguished below.
- I included the observed state and reproduction limits.
Area
apps/web / apps/desktop, pending user-input presentation
Steps to reproduce
Observed in an existing long-running Codex thread on 27 October 2026. I have not created a separate minimal reproduction.
- The agent creates two
request_user_input_asyncquestions. - Neither is answered through the question UI. The conversation continues through multiple later turns, and the decisions become unnecessary.
- After the agent finishes a later turn, the thread card shows the purple question icon and Input.
- The user opens the conversation but cannot find a visible question to answer or dismiss.
Expected behavior
A pending question contributing to Input should be discoverable and actionable from the thread. Async questions should remain accessible for answering or dismissal even after their originating turn ends.
This report does not ask ordinary chat messages to implicitly answer or approve pending questions.
Actual behavior and verified state
The user supplied a screenshot of the Input card and reported that no question was visible in the conversation. Read-only MCP inspection found:
t3_thread_read:pendingRequestCount: 2.t3_pending_request(action: "list"): exactly two requests.- Reading each request returns one valid multiple-choice question, each with two options.
- Both IDs belong to the same older provider turn, rather than the latest completed turn.
- Several later turns have completed; the agent is able to continue working.
- The requests concern earlier alternatives that the task no longer needs. They have not been answered, dismissed or automatically superseded.
The badge therefore has real pending records behind it. The reported defect is their lack of a visible, reachable question/dismissal UI, not a fabricated count or a proven lost answer. Keeping unanswered async requests pending can be intentional; keeping them inaccessible while advertising Input leaves the user with no clear action.
Impact
Minor bug or occasional failure. The thread looks stalled and the user cannot tell what input is required.
Version or commit
0.1.3-nightly.20261027.3754, confirmed by the user's App settings screenshot. Update track: Nightly; the app reports Up to Date.
Source checkout inspected separately at 72dde22b6f092491fac4ddc480bc609bb8092bfd; this is not claimed to be the installed build's source revision.
Environment
T3 Code UI, Codex provider, gpt-6.1-sol, high reasoning effort. Observed 27 October 2026.
Related reports and limits
- [Bug]: Async questions make a running thread show as Awaiting Input #15258 was fixed by fix(clients): async questions keep a running thread Working #15430 for running-versus-input classification. Its final maintainer comment asks for a new issue for remaining stuck Input cases. This report concerns reachability of the older pending questions after later turns.
- [Bug]: Pending async questions lose their thread-list indicator while the agent keeps working #24914 concerns the opposite list-indicator issue while a run is active.
- [Bug]: iOS 1.0.3 hides async questions while Settle is blocked #10192 concerns older iOS clients dropping optionless questions. These requests have options; an iOS-only cause is not established.
- [Bug]: Submitted question replies are hidden in collapsed work #17226 / discussion Give user-question exchanges a dedicated Q&A UI outside tool logs #16965 concern already-answered exchanges hidden in history. These two requests remain unanswered.
- Discussion [Feature]: Let a chat reply answer a pending question, and close the question card #22317 proposes treating ordinary chat replies as answers. That behavior change is not required by this report.
The screenshot contains private project identifiers and is retained privately. Full-thread client rendering, reload behavior and a fresh synthetic reproduction have not been independently checked. No provider restart, request response, database write or app-source change was performed.
Activity
seankoji commentedon Oct 29, 2026
A further occurrence was observed on 29 October 2026 with server identity
0.1.4-nightly.20261029.3853, a Linux x64 host, and Codexgpt-6.1-solat high reasoning effort. The client version and platform are unknown; this server version does not establish a source revision.The user supplied a screenshot showing the purple Input badge and reported no remaining input to provide. Read-only MCP inspection found exactly one older async publication question. Its decision had been explicitly superseded by a later owner instruction and approval, and that publication had already completed. No response or dismissal of the older question was sent through the request API.
A separate investigation-model question was then answered through the picker and disappeared. Listing pending questions again returned only the same older publication question. This adds a one-request occurrence on a newer nightly server, with a separate picker answer clearing successfully while the older request persisted.
There is a real pending record behind the count. This does not establish a fabricated count, a lost answer, or a requirement for ordinary chat to approve or dismiss questions automatically. The expected behavior remains that every question contributing to Input is discoverable and actionable, including explicit dismissal when its decision is no longer needed. The practical impact is a stale attention signal that makes continuing work look blocked.
Limits: the question-card rendering, dismissal controls and reload behavior were not independently driven, and no fresh synthetic UI reproduction was performed. No workaround or fix was tested. The screenshot contains private project details and is retained privately; thread, request and project IDs are omitted.
This supports the existing visibility/dismissal report here. #15258 / #15430 addressed Working-versus-Input classification; #24914 concerns a missing indicator while running. The Claude abort/steer race in #15517 is not established for this Codex observation, and Discussion #22317's chat-as-answer proposal is not required for this report.
pjacobr commentedon Oct 29, 2026
I am seeing the same user-facing symptom in the macOS desktop UI on 29 October 2026: a thread shows the purple Input badge, but selecting it opens a long conversation without revealing the question I need to answer. I cannot quickly find which request needs my response.
My two screenshots show the sidebar badge and the selected conversation with no question visible in the current view. They contain private project information, so I have kept them out of this public comment. The exact app version was not captured. I have not independently reproduced this in a fresh thread or inspected this thread's pending-request records, so I cannot confirm that it has the same underlying cause as the earlier occurrences.
The practical need is a direct route from Input to the actual unanswered request, even if it comes from an older turn. I opened a separate Ideas discussion for a clickable badge, an input inbox, and Next input navigation: #27064.
Drafted with Codex in T3 Code on my behalf.