Windows Codex desktop: follow-up submission spins indefinitely #42952

Activity

1. github-actions

   added

   bugSomething isn't workingSomething isn't working

   appIssues related to the Codex desktop appIssues related to the Codex desktop app

   windows-osIssues related to Codex on Windows systemsIssues related to Codex on Windows systems

   on Sep 5, 2026
2. github-actions commented on Sep 5, 2026

   

   github-actionsBot

   on Sep 5, 2026 – with GitHub Actions

   Contributor

   More actions

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

   • Codex freezing when submitting prompt #42120
   • Can't submit a prompt in Codex #42472

   Powered by Codex Action
3. zouyu9631 commented on Sep 5, 2026

   

   zouyu9631

   on Sep 5, 2026

   Author

   More actions

   Additional environment information, checked on September 5:

   • Installed desktop app package.json version: 26.901.41600
   • Windows package version: 26.901.5280.0
   • Local Codex executable version: 0.153.4
   • OS: Windows 11 Home Chinese edition, 10.0.26200, x64

   I still experience the follow-up submission problem after updating.

   The September 5 desktop logs also contain these potentially relevant
   messages (UTC):

   07:30:09.108 — Received turn/started for unknown conversation
   07:30:14.065 — Received turn/completed for unknown conversation
   07:30:54.533 — Timed out while fetching post-login Statsig bootstrap
   07:31:09.249 — No promise for request ID

   These are diagnostic leads, not confirmed causes. The exact failed
   manual submission still needs to be correlated with its timestamp,
   conversation ID, and renderer/window ID.

   Related reports: #42120 and #42472. This report additionally includes
   successful CLI submissions to the same existing conversation and the
   absence of a second turn/start or turn/steer in the captured reproduction.
4. 84dnnvbdvp-debug commented on Sep 5, 2026

   

   84dnnvbdvp-debug

   on Sep 5, 2026 – with ChatGPT Codex Connector

   More actions

   One discriminator may separate an app-server lifecycle problem from a desktop submit/request-bookkeeping problem here.

   Current app-server protocol says a completed ordinary turn ends with turn/completed; a later user message on the same resumed thread is sent with turn/start. turn/steer is specifically for an already in-flight regular turn and requires the exact active expectedTurnId; it should fail if there is no active turn. thread/read also exposes the server-side thread status (and, where applicable, canAcceptDirectInput).

   So immediately after the first successful turn/completed, before clicking Send again, it would be useful to capture thread/read on the same app-server connection, then correlate the failed click with the client-side RPC dispatch/request-id registration:

   • If app-server reports the thread no longer has an active turn / accepts direct input, but the desktop spinner appears and no turn/start or turn/steer reaches app-server, the failure is upstream of the server turn lifecycle — likely the desktop submit gate / request-promise bookkeeping. That would make the later No promise for request ID line especially worth correlating, without assuming it is causal.
   • If app-server still reports an active/in-progress turn after the observed turn/completed, that instead gives a concrete server/session-state mismatch to chase.

   This also fits the existing evidence that CLI submissions to the same conversation succeed: it avoids treating thread persistence or the model/backend as the primary suspect until the desktop-vs-app-server boundary is measured. A regression could assert: after turn/completed, a second desktop submit allocates one client request id and emits exactly one accepted follow-up RPC (turn/start unless an actual turn is still in flight), rather than entering a spinner-only pending state.
5. zouyu9631 commented on Sep 5, 2026

   

   zouyu9631

   on Sep 5, 2026

   Author

   More actions

   Thanks for the diagnostic suggestion. I #checked the existing desktop debug capture more closely:

   • Of 91 enqueued requests, 89 have a matching renderer completion/failure log. The remaining two are startup account/read and getAuthStatus requests. Both have backend response_routed records, but no matching renderer completion record.
   • The first manual turn/start has a complete enqueue → dispatch → transport → response → renderer completion sequence. No subsequent turn/start or turn/steer appears during the captured follow-up failure.
   • This capture contains no No promise for request ID error.
   • The “turn/completed for unknown conversation” error refers to a different thread, marked ephemeral in the logs, not the affected conversation.

   The two unmatched startup requests are only a lead; the first message succeeded while they were already outstanding.

   Could you provide concrete, read-only steps to capture thread/read through the affected Windows desktop app’s existing app-server connection, together with the composer’s pending submission state? Ideally, we would capture both immediately after the first reply and again while the second submission is spinning, without restarting or launching another app-server.
6. zouyu9631 commented on Sep 7, 2026

   

   zouyu9631

   on Sep 7, 2026 – with ChatGPT Codex Connector

   Author

   More actions

   Update: after a subsequent Codex desktop upgrade, the issue is resolved on my Windows machine. I can now send follow-up messages in the same conversation without the submission spinner getting stuck.

   I have not isolated the first fixed version or the underlying cause, so the earlier diagnostic leads should not be treated as confirmed causes.

   Closing as resolved on my end. Thanks for the diagnostic suggestions and help investigating.
7. zouyu9631

   closed this as completedon Sep 7, 2026