[Windows] Codex app 26.908: app-server responses lost during the ~20 s renderer mount; composer spins forever, model picker disappears, follow-ups stay disabled (different PC from #42547, same signature as #34272)

Summary

On Windows, the Codex desktop app (26.908.40834, bundled app-server 0.154.0-alpha.6.2) intermittently stops delivering app-server responses to the primary renderer. When that happens the composer never leaves the "sending" state (spinner on the Send button), the model picker disappears from the composer, follow-up messages in an existing thread cannot be sent (Send stays disabled), and agent replies that the server already produced are not painted. The model side is healthy the whole time: thread/start and turn/start succeed, turns complete, and the same account works from the CLI, from the Chrome side panel, and in existing threads.

This is a different PC from my earlier report #42547 (that one was the blank client area on 26.831/26.901). The symptoms here match #34272 ("cannot send messages", Received turn/completed for unknown conversation), which is still open.

Environment

• Windows 10 Home 10.0.19045, AMD Ryzen 5 3400G (4C/8T), 32 GB RAM
• Codex app 26.908.40834 (MSIX OpenAI.Codex_26.908.4834.0), app-server 0.154.0-alpha.6.2, CLI codex-cli 0.154.0
• ChatGPT sign-in (not API key). Started 2026-09-11 right after switching accounts in the app; reproduced daily since, survived a full uninstall/reinstall of the app and a reboot.

What the logs show

Hung send (desktop log %LOCALAPPDATA%\Codex\Logs, app-server log ~/.codex/logs_2.sqlite):

05:24:08Z ROUTED configRequirements/read   -> renderer (wc=1)
05:24:09Z ROUTED config/read x3
05:24:14Z ROUTED thread/start 354ms  errorCode=null targetDestroyed=false
05:24:14Z ROUTED model/list, experimentalFeature/list x2
(nothing further; no "Conversation created", no turn/start, no error)

app-server side for the same request id: thread/started targeted_connections=0, session initialized normally. So main routed every response, but the renderer never continued.

Attaching a Node inspector to the main process and reading the renderer's React Query cache while hung: 73 queries were stuck in fetchStatus: "fetching" with no data and no error, including ["models","list","local","no-auth",100], ["experimental-features","list","local"], ["user-saved-config","local",null], ["config","requirements","local","auth","chatgpt"], and plain host IPC queries such as ["vscode","codex-home"] and ["vscode","locale-info"]. Calling query.cancel() then query.fetch() on each of them resolved every one in 10-200 ms, after which the app's deferred startup work ran (plugin reconcile, browser-use backend, computer-use pipe) and the model picker reappeared. So the responses are being lost between main and the renderer, not delayed by the server.

The renderer's request client never logs mcp_request_timeout in these instances (that path rejects with Error("Timeout"), which would have surfaced), and the main-side chunked-message transfer had zero targets (inlineThresholdBytes 4 MB never reached), so neither the request timeout nor the chunker is the blocker.

Same mechanism for follow-ups: in a thread that had already completed one turn, the composer's Send button was disabled while 16 queries were stuck (permission-profiles list, apps list installed, git-origins for each project, locale-info, get-global-state). Re-fetching them enabled the button immediately (and sent the pending draft). Agent replies also went missing: thread_history_1.sqlite had the agentMessage "OK" while the UI showed an empty reply bubble with only the action icons.

Why this machine hits it so often

The primary window takes 15-36 s to mount on this PC ([startup][renderer] app routes mounted after 18787ms, 21562ms, 25124ms; 21 launches measured today, and Sep 11 logs show the same range). A reload of the same renderer mounts in 4.4 s. A CPU profile of the first 40 s shows the renderer main thread ~100% busy from t=4 s to t=22 s: (program) 2.8-4.9 s, 246 lazy app:// script chunks, thread-catalog processing (replaceThreadSummaries, observeCatalogThreads, deep isEqual), React initial render. app is registered via registerSchemesAsPrivileged without codeCache: true, so the ~15 MB of bundles are recompiled on every cold start (Code Cache dir holds 4 files). Responses that arrive during that window (configRequirements/read at +4 s, model/list at +7 s in the example above) are the ones that get lost, and the app's post-auth startup sequence then stalls behind them.

Thread count is not the driver: temporarily archiving 185 of 281 threads changed mount time from 21.5 s to 19.3 s (and archived threads are fetched anyway via thread/list {archived:true}).

Things I found and fixed locally (they reduce how often it happens, not the bug)

• sites plugin was installed twice: the app bundles sites@openai-bundled 0.1.70, but the account catalog also listed sites@openai-curated-remote 0.1.62. The app-server rejected the bundled install every startup (plugin 'sites' was not found in marketplace 'openai-bundled') and rejected the remote copy after each download (failed to load plugin: missing or invalid plugin.json, plugin manifest is missing after installation staging, later os error 5 removing the stale cache), so the remote sync re-downloaded it in a loop (67 syncs / 22 flaps in one hour; plugin/installed took 5-12 s each time). codex plugin remove sites@openai-curated-remote fails with "not found in remote marketplace", so it cannot be removed by the user. Workaround: move the stale cache dir aside and codex plugin add sites@openai-bundled from the CLI, which succeeds.
• playwright MCP configured as npx @playwright/mcp@latest added 3-5 s of startup per thread; switched to a local install.
• A stuck third-party updater was pinning a core; unrelated to Codex but it widened the startup window.

Workarounds I am using

• If the composer spins or the model picker is missing right after launch: quit and relaunch the app (a plain reload is not enough; the reloaded renderer immediately loses models list / apps list again).
• Follow-ups in a thread whose Send button stays disabled: relaunch, or continue the same thread from the CLI or the Chrome side panel, which are unaffected.
• Keep the app running instead of restarting it, and avoid launching it while the machine is busy.

Suggestions

• Enable codeCache for the app scheme (or ship a V8 cache) so cold start is not a 20 s window.
• Make the renderer's request layer resilient to responses arriving before/while the app root mounts (or re-issue in-flight requests after app routes mounted), and give React Query fetches a hard timeout so a lost response surfaces as an error instead of a permanent spinner.
• Fix the sites bundled-vs-remote conflict so the remote copy is dropped when the bundled one exists.

I can provide the full desktop logs, the app-server sqlite log, and the CPU profiles on request.

No source file or test is named. Start at the renderer request client and the main-to-renderer routing path, then inspect the app routes mount and React Query startup work described in the logs. Done means responses arriving during the roughly 20-second mount no longer leave queries, the composer, model picker, or follow-ups permanently stuck.