Codex desktop (Windows): early vscode://codex/* fetch responses are silently lost at startup → Scheduled / Keyboard shortcuts pages stuck loading, cannot send messages, UI sometimes falls back to English #47795

Environment

• Codex desktop (MSIX) 26.917.9434.0, app-server 26.917.71314
• Electron 153.0.8010.53 (Chrome 153.0.8010.53, Node 24.19.0)
• Windows 11 Pro, build 26200, x64 (24 logical cores, 64 GB RAM; system idle during tests)

Symptoms (intermittent, but currently reproduces on almost every cold start)

• The Scheduled tasks page stays on "正在加载已安排任务" ("Loading scheduled tasks") forever.
• The Keyboard shortcuts page never finishes loading.
• In existing conversations, pressing Send does nothing: the app-server never receives a turn/start request.
• The UI sometimes shows English even though [desktop] localeOverride = "zh-CN" is set.
• There is no error in the UI, and no error in the desktop or app-server logs.

Reproduction

1. Cold start Codex desktop.
2. Open the Scheduled tasks page (or Keyboard shortcuts).
3. The page stays in the loading state indefinitely.

A clean reinstall does not avoid it. I removed the MSIX package, ~/.codex, %LOCALAPPDATA%\OpenAI and the Chrome native-messaging host key, then reinstalled from the Store. With the freshly created data directory and no projects, the problem still reproduces with a normal Start-menu launch. With local projects added the problem appears more often (the startup window during which messages are lost gets longer), but projects are not required.

What I found

I instrumented the main process (wrapping ipcMain handler codex_desktop:message-from-view and webContents.send) and the renderer (a window message listener installed in the main world at about 2.2 s, before the affected requests).

1. The renderer sends the requests. At about 3.4–3.6 s after launch, the renderer sends a burst of fetch requests:
   • vscode://codex/list-automations
   • vscode://codex/inbox-items
   • vscode://codex/codex-command-keymap-state
   • vscode://codex/locale-info
   • vscode://codex/codex-home
   • vscode://codex/get-global-state (keys copilot-default-model, selected-remote-host-id)
   • vscode://codex/paths-exist (when projects exist)
   • vscode://codex/global-dictation-hotkey-state
2. The main process answers every one within 1–30 ms. The fetch-response messages go out through webContents.send on codex_desktop:message-for-view to the correct webContents (the main window).
3. The renderer never receives most of them. In one trace, main sent about 20 messages between t=3417 ms and t=3502 ms, a mix of fetch-response and shared-object-updated. The renderer's window message listener received only one of them. The rest never arrived, even after 30 s. Messages sent just before (t=3164) and after (t≥4670) were received normally.
4. The renderer was not blocked. It received other messages immediately at t≈4680 ms.
5. There was no navigation. No main-frame navigation, reload, or render-process event occurred in that window. I checked did-start-navigation, did-navigate, did-frame-navigate, render-process-gone and others.
6. The queries stay pending forever. In React Query, the affected queries stay status: pending, fetchStatus: fetching indefinitely.
7. Re-requesting works immediately. If I cancel and refetch the same queries later in the same renderer (for example ["vscode","list-automations"]), main answers in 2 ms and the page loads. The IPC channel itself works; only responses sent during that early startup window are lost.
8. It is timing-sensitive. Enabling the renderer CPU profiler during startup made the problem disappear in that run: the responses arrived about 500 ms late but did arrive.
9. Reloading the renderer avoids it. Reloading the main window's webContents after startup (6/6 runs) loads correctly. Opening "File → New window" helps only if startup has fully settled.

Suspected area: delivery of codex_desktop:message-for-view IPC messages to the preload during early startup. The preload re-dispatches every message synchronously as window.dispatchEvent(new MessageEvent('message', …)) with no buffering or acknowledgement for non-chunked messages. The renderer's fetch client drops responses silently if it misses them. There is no timeout or retry for vscode://codex/* requests, so a single lost response leaves the query pending forever.

Suggestions

• Add a timeout and retry, or a re-request on reconnect, for vscode://codex/* fetches, so a lost response doesn't wedge a page forever.
• Investigate why webContents.send messages sent during the early startup burst are not delivered to the renderer.
• Provide a "Reload window" command in the View menu as a user-level workaround.

Possibly related (same user-visible symptoms, may share this root cause): #46763, #47316, #46590

(Logs are not attached because they contain private local file paths. I can share specific sanitized excerpts on request.)