[Windows Desktop] GUI stops accepting messages; successful backend replies time out in renderer

What version of the Codex App are you using (From “About Codex” dialog)?

OpenAI.Codex Windows package 26.901.6511.0; active runtime CLI 0.153.4 (verified from installed package/runtime, not About dialog).

What subscription do you have?

Pro

What platform is your computer?

Microsoft Windows NT 10.0.26200.0 x64

What issue are you seeing?

• Windows desktop package OpenAI.Codex 26.901.6511.0; active runtime CLI 0.153.4.
• Observed 2026-09-07. All times below are UTC.
• Local desktop stops accepting messages across chats and Plugins remains loading. Background agent work and remote interaction continue according to the user.
• Restart temporarily restores message processing, but the failure returns. Sign-out/sign-in did not restore usability in the latest incident. Ctrl+Shift+P does not respond while stuck; New Window is not exposed in this user's menu.

Verified log correlation

Before restart, all 20 observed mcp_request_timeout events had earlier successful response_routed entries for the same request IDs and primary webcontents 1, with no server error. Server durations were 57-4583 ms; GUI timeout was 30000 ms.

After restart:

• 12:09:11.334: bundled_plugins_reconcile_started.
• 12:09:17.166: bundled_plugins_reconcile_completed.
• Request a58a7d8c-7e41-4f0f-bf9e-c27e8f5669c4, method plugin/installed: response routed 12:09:19.410, duration 2241 ms, errorCode=null, targetDestroyed=false, originWebcontentsId=1. Same request times out in GUI at 12:09:47.178, pendingCount=2.
• Request 5521e764-e8ee-4f11-8f39-1dffafb3b431, method plugin/installed: response routed 12:09:23.816, duration 2384 ms, errorCode=null, targetDestroyed=false, originWebcontentsId=1. Same request times out at 12:09:51.130, pendingCount=7.

response_routed is logged before client-message delivery; it does not prove renderer receipt. Backend synchronization succeeding did not restore the GUI.

What steps can reproduce the bug?

1. Use desktop with existing chats and background work. Exact initial trigger unknown.
2. Local input/reply display stalls while remote work continues.
3. Restart desktop. New process started at 11:49:14; renderer processed skills results and reasoning summaries at 11:50:44, with zero UI timeout events in that initial capture.
4. Plugins remains stuck loading; user signs out/in around 12:09.
5. Backend plugin reconciliation completes, but local GUI requests again time out despite successful backend replies. User reports local message submission no longer works.

What is the expected behavior?

The GUI should consume successful backend responses and remain usable, or explicitly report and recover from a message-delivery failure. Plugins should stop loading after successful reconciliation. Preserve active work and unsent drafts during recovery.

Additional information

Related: #38385. That report describes six dispatched requests without routed responses; this report instead correlates successful routed responses with later GUI timeouts. Shared root cause is unconfirmed.

Candidate mechanism, not confirmed root cause

Read-only inspection and an offline test of the installed host-to-renderer sender found that an unacknowledged chunk transfer blocks subsequent ordinary messages without a recovery timer, while small critical messages can pass. The test used synthetic serialization, delivery and timers; it did not connect to or modify the running app. This is a plausible mechanism, not proof of a lost acknowledgement in the live incident. Please investigate acknowledgement lifecycle and message delivery after the response-routing log.

Diagnostic caveats and request

A separate fully isolated diagnostic desktop profile with distinct CODEX_HOME was also running. Earlier shared-home testing caused separate conflicts; those are not being presented as the cause of this incident. Configuration parsing and configured runtime-path checks pass. No data reset, package patch, forced process termination, or configuration repair was applied during this freeze investigation.

Please advise on a supported recovery or fixed desktop build and any additional non-disruptive diagnostics needed. Sanitized request-pair captures and the offline test are available. This report excludes raw logs, chat contents, usernames, machine names, account identifiers and local project paths; request IDs above are diagnostic correlation IDs.

Start at the response_routed-to-client-message delivery path and trace the host-to-renderer sender's acknowledgement lifecycle, especially after an unacknowledged chunk transfer. Use the reported request correlations and available offline sender test as diagnostics. Done means successful backend replies reach the renderer, Plugins finishes loading, and the GUI recovers or reports delivery failure without losing drafts or active work.