Windows composer enables before turn completion; immediate follow-up is dropped
What version of the Codex App are you using (From “About Codex” dialog)?
26.707.9564.0
What subscription do you have?
ChatGPT Pro
What platform is your computer?
Microsoft Windows NT 10.0.26200.0 x64
What issue are you seeing?
The Windows Desktop app enables the composer after rendering the final assistant response but before the authoritative turn completion/idle transition. A follow-up submitted in that interval appears as an optimistic user bubble and then fails with Error submitting message.
In a captured incident:
- Final assistant response persisted at 14:36:46.953.
- task_complete arrived at 14:36:50.172 (about 3.22 seconds later).
- The follow-up text was absent from the task JSONL.
- No new turn/start, turn/steer, user-message event, or new turn id was persisted.
- Restarting the app immediately restored submission.
A read-only sample of 71 completed turns over two days showed a median final-message-to-task_complete gap of 3.048 seconds, p90 3.32 seconds, and maximum 3.972 seconds. desktop.followUpQueueMode was already set to queue.
The same failure is reported more often after switching from mobile back to Windows, and after a long idle period. These look like triggers that expose the stale-state window, not unsupported usage.
What steps can reproduce the bug?
- Run a normal or long task in the Windows Codex app.
- As soon as the final assistant response is visible and the composer becomes enabled, immediately submit a short follow-up.
- Observe the user bubble appear, followed by Error submitting message.
- Inspect the task rollout: the submitted user text and a new turn are absent.
- Fully restart Codex; submissions work again in the same task.
The race is timing-sensitive. Switching from mobile back to Windows or replying after a long idle period appears to make it easier to reproduce.
Affected task / private feedback tracking id: 019f5bc4-93ee-7972-9c54-41d3724780ae
Affected completed turn: 019f5f17-e3a4-7da2-86f1-28b55ad63a0c
What is the expected behavior?
The composer should remain disabled until the authoritative thread state is idle/completed, or the client should safely queue/retry the input. User input must not be discarded. The UI should also retain the underlying JSON-RPC error details rather than replacing every failure with a generic message.
Additional information
Private diagnostic logs for the affected task were uploaded through Codex's built-in feedback/upload channel.
Potentially related issues: #30710, #23644, #20754, #19690.
No project content, account email, prompt content, or raw local paths are included in this public report.
2 Comments
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action
Thanks — I reviewed #31874. The two issues appear related at the task/turn state-synchronization layer, but #32982 does not appear to be a duplicate.
The failure directions are different:
task_completehas not arrived yet. A follow-up submitted during this window is rejected and lost withError submitting message.For the captured #32982 incident, the follow-up was not persisted at all: there is no user-message event,
turn/start,turn/steer, or new turn ID in the session JSONL. The measured final-answer-to-task_completegap was about 3.22 seconds; across 71 completed turns, the median gap was 3.048 seconds (p90 3.32 seconds).#31874 was self-closed after the reporter said it no longer reproduced, without a linked fix. #32982 remains reproducible on Windows and has a distinct “composer enabled before authoritative completion / dropped input” signature.
Please keep #32982 open as a separate bug, while treating #31874 as a related task-vs-turn state-boundary issue. #30710 and #23644 may also be closer to the immediate-submit/stale-state symptoms here.