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?

1. Run a normal or long task in the Windows Codex app.
2. As soon as the final assistant response is visible and the composer becomes enabled, immediately submit a short follow-up.
3. Observe the user bubble appear, followed by Error submitting message.
4. Inspect the task rollout: the submitted user text and a new turn are absent.
5. 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.