[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.

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

Codex desktop (Windows): follow-up messages in existing threads never send #45069
Windows desktop: existing-chat sends indefinitely blocked by loading-local-config / pending codex-home; main-window reload recovers, normal restart can recur #44342
Still reproducible on Windows Desktop 26.908.40834 — first turn completes, but follow-up message does not create a new turn/start #45315
Windows Codex Desktop: Send button becomes disabled after the first successful turn #45307
Windows: composer Send button stays disabled; voice and message editing still create turns #45305

Powered by Codex Action

Additional affected Windows machine, with a precise response-before-timeout signature on 2026-09-15. This blocks normal work in both local and SSH-backed desktop sessions.

Environment

Windows 10 Pro, 10.0.19045, x64.
Installed MSIX package: OpenAI.Codex 26.908.9136.0 (queried with Get-AppxPackage; not the About dialog version).
Desktop app-server: codex-cli 0.154.0-alpha.6.2.
Separately installed CLI: codex-cli 0.154.0.
Selected model: gpt-6-astra.

Symptoms and reproduction

Open the desktop app and an existing local project conversation.
Type a follow-up and attempt to send it.
The text stays in the composer as a draft; the Send arrow becomes gray or shows an indefinitely spinning indicator. No actionable error is shown.
The user also reports the same failure in SSH-backed conversations and previously in brand-new local conversations.
Restarting the app does not resolve the current failure. After the latest restart the Astra model is visible and selected, but sending is still blocked.

This has repeatedly interrupted work since at least September 11. Requiring a restart after each message is not a usable recovery path.

Observed desktop log evidence

The following are reduced excerpts from the same app launch. Timestamps are UTC; request identifiers are retained to demonstrate correlation. Paths, project names, conversation IDs, server addresses, and message contents are omitted.

2026-09-15T13:00:50.708Z info [AppServerConnection] response_routed durationMs=5 errorCode=null hadPending=true method=experimentalFeature/list originWebcontentsId=1 queueWaitMs=0 requestId=2a4490dd-c23b-41e2-9d00-9a91b75d77f3 targetDestroyed=false
2026-09-15T13:00:55.713Z warning [electron-message-handler] mcp_request_timeout method=experimentalFeature/list pendingCount=5 priority=critical queueWaitMs=0 rendererWebContentsId=1 requestId=2a4490dd-c23b-41e2-9d00-9a91b75d77f3 source=features timeoutMs=4999

2026-09-15T13:00:51.684Z info [AppServerConnection] response_routed durationMs=1 errorCode=null hadPending=true method=model/list originWebcontentsId=1 queueWaitMs=1 requestId=73d2862f-8712-4d4a-8d87-38b258921304 targetDestroyed=false
2026-09-15T13:00:56.684Z warning [electron-message-handler] mcp_request_timeout method=model/list pendingCount=4 priority=critical queueWaitMs=0 rendererWebContentsId=1 requestId=73d2862f-8712-4d4a-8d87-38b258921304 source=models timeoutMs=4999

2026-09-15T12:54:33.971Z info [AppServerConnection] response_routed durationMs=359 errorCode=null hadPending=true method=plugin/installed originWebcontentsId=1 requestId=c6ff22db-7383-4765-bc37-1d4b08088da7 targetDestroyed=false
2026-09-15T12:55:03.607Z warning [electron-message-handler] mcp_request_timeout method=plugin/installed pendingCount=3 rendererWebContentsId=1 requestId=c6ff22db-7383-4765-bc37-1d4b08088da7 timeoutMs=30000

For the specifically inspected local conversation, thread/resume returned successfully in 273 ms after the restart. No turn/start entry was found in the inspected post-restart main-process log, and its local session transcript contained only the earlier initial user prompt, not the follow-up stuck in the composer.

This differs from the no-timeout variant described in the original report: here the main process logs a successful routed response FIRST, then the renderer reports a timeout for that SAME request about 5 or 30 seconds later. This suggests a response delivery/consumption or pending-request bookkeeping issue, but does not establish the root cause.

Requested outcome

Please investigate the response-before-timeout sequence and the blocked composer across local and SSH sessions. The UI should preserve the draft, recover or offer an actionable retry, and allow follow-ups after a successful resume. Please share a confirmed workaround or the fixed Windows build when available; there is no confirmed app fix on this machine yet.

2026-09-16 follow-up: still blocked after clean state and official package comparison

The normal Windows desktop composer remains unusable on the currently affected machine. This follow-up was prepared with diagnostic assistance; it distinguishes backend health from actual user-operated UI success.

New checks

Current MSIX package: OpenAI.Codex 26.908.9136.0, x64.
Tested the official direct-download package 26.903.8094.0 after backing up the existing conversations, settings, databases, and browser profile. The package signature was valid.
The older version reproduced unresolved startup requests in both the previously prepared isolated state/profile and the original state/profile. It was not a successful workaround. The original 26.908.9136.0 version was then restored through Microsoft Store.
After restoration, the app was launched normally, with no inspector, remote-debugging, or profile-override arguments. The user again confirmed that sending a minimal message stalled. This final normal-launch result is FAIL, not an inferred UI pass from backend probes.

Narrowed failure boundary

Previously, direct GPT-5.6 Luna / low App Server responses succeeded, including conversation resumption after complete desktop/backend restarts. The real composer nevertheless stalled. No additional automatic model-response tests were requested for the package comparison.
On 26.903, several startup requests remained unresolved with timeout 0 for more than 68-80 seconds. Depending on the launch, these included account/read, getAuthStatus, experimentalFeature/list, config/read, model/list, and permissionProfile/list.
Fresh independent metadata/configuration requests through the existing desktop client still completed in approximately 5-12 ms while older startup promises remained unresolved.
Earlier passive tracing on 26.908 recorded main-process webContents.send calls for six response IDs that were absent from the renderer's early window-message recorder, although other responses were recorded normally. This supports a delivery/initialization boundary issue; it does not establish the ultimate implementation cause.
An inspected main-process chunked-message sender had no outstanding target/chunk queue during the earlier stall. Database quick checks passed.

Separate setup issue, already resolved

The isolated test environment also encountered helper_sandbox_lock_failed / SetNamedSecurityInfoW error 5. After a user-performed ownership repair on that single test directory, Windows setup completed with errors=[], and read-only sandbox commands succeeded before and after restart. The composer/startup-response problem persisted, so the setup issue is not the remaining blocker.

Limits and requested follow-up

Account switching preceded the original failure but has not been established as its cause. No installed app code was patched, no security protection was disabled by the diagnostic agent, and no stale request was expired/replayed to turn the comparison failures into apparent passes. Diagnostic ports are now closed and original data is preserved.

Could the team confirm whether the startup response-delivery failure is being investigated, and identify a supported recovery action or a Windows build containing a fix? Clean state and switching between these two official packages did not restore reliable normal operation.

Only this sanitized summary is shared. No credentials, account email, conversation contents, user filesystem paths, screenshots, raw logs, or session archives are attached.

Additional reproduction: first app-server instance hangs Desktop bootstrap; killing only app-server makes Desktop recover

I can reproduce what appears to be the same startup/bootstrap issue consistently on two different Windows PCs.

Versions

Codex Desktop: 26.924.2738.0
Embedded CLI/app-server: codex-cli 0.158.0-alpha.2.1
Authentication: ChatGPT (codex login status reports Logged in using ChatGPT)

Reproduction

Fully close Codex Desktop.
Start Codex Desktop normally.
Desktop remains indefinitely on the loading spinner.
While it is stuck, identify the codex.exe app-server child process spawned by ChatGPT.exe.
Kill only that codex.exe process, leaving ChatGPT.exe running:
```
Stop-Process -Id <app-server-pid> -Force
```
Desktop automatically spawns a new codex.exe app-server.
The UI immediately completes initialization and becomes usable.

The replacement process has:

the same ChatGPT.exe parent process;
the same codex.exe executable;

the same command line:

codex.exe -c features.code_mode_host=true app-server --analytics-default-enabled -c plugins.codex-app-tools@openai-bundled.mcp_servers.codex_app.enabled=true

Additional diagnostics

The first/stuck app-server is not simply failing to start. While Desktop is showing the spinner:

codex.exe remains alive;
it has an established outbound HTTPS connection;
authentication is valid;
previous startup logs showed successful HTTP responses;
running the same app-server command manually from PowerShell starts successfully and remains waiting on stdio as expected.

I also tested disabling features to isolate plugins/apps:

plugins=true,  apps=true  -> spinner
plugins=false, apps=true  -> spinner
plugins=false, apps=false -> spinner

Therefore disabling the general plugin/apps subsystems does not change the behavior.

The only deterministic recovery found so far is restarting only the app-server process. There is no need to restart the Desktop/Electron process.

This looks consistent with a startup/lifecycle or request-routing race between Desktop and the initial app-server instance: the first backend remains alive but Desktop never completes bootstrap; forcing the backend connection to be recreated allows the second initialization attempt to succeed.

The fact that this is reproducible on two separate Windows machines may also help rule out corruption specific to a single local installation.

I can provide startup logs comparing the stuck and successful initialization attempts if useful.

One additional data point that may be relevant: updating and reinstalling the Desktop app did not resolve the issue.

Before this debugging session, I had already:

reinstalled the application multiple times;
manually removed the local application/configuration files before reinstalling.

During this debugging session, I also updated Codex Desktop specifically to test whether a newer build fixed the startup issue. The problem remained reproducible after the update. The current package observed after updating is:

OpenAI.Codex_26.924.2738.0_x64__2p2nqsd0c76g0

After the update/reinstall attempts, the behavior is still the same:

Start Desktop
  -> first app-server starts
  -> UI remains on spinner
  -> kill only the app-server process
  -> Desktop automatically respawns app-server
  -> UI completes initialization

So this does not appear to be resolved by a clean reinstall, removal of local files, or updating to the newer Desktop build.

Additional cold-start instrumentation narrows the failure down substantially.

Environment: Windows 11, Codex Desktop 26.924.2738.0, bundled CLI/app-server 0.158.0-alpha.2.1. The behavior reproduces on two PCs and persisted across clean reinstalls and an app update.

On a fresh start, the initial app-server initializes successfully over stdio:

transport starts successfully
initialize_handshake_result: outcome=success, durationMs=118
connection transitions to connected with initialized=true
config/read, account/read, getAuthStatus, etc. return normally
account lookup reports authenticatedAccountPresent=true, authMethod=chatgpt, result=succeeded

Shortly afterward Desktop logs an electron-fetch-handler codex-home request. I cannot find a completion for that request before startup failure. About 121 seconds later Desktop records:

name=app_start
outcome=failure
reason=timeout
durationMs=121209.1
wallDurationMs=121208.7
initialSurface=home

The spinner remains indefinitely.

I then terminated only the first app-server process while leaving the Desktop/Electron process alive. At teardown Desktop reports the connection had been connected and initialized, with:

pendingClientRequests=0
pendingInternalRequests=0
wasInitialized=true

Desktop immediately respawns the same app-server executable with the same command. The replacement initializes successfully in ~108 ms. Recovery then logs another codex-home request, followed by app_server_restart_recovery_done and shortly afterward:

[startup][renderer] app routes mounted after 199103ms

At that point the startup spinner disappears.

This suggests the first app-server is not failing its startup/stdio handshake. The long-running codex-home stall is also not represented as a pending AppServerConnection request. The failure appears higher in the Desktop renderer/Electron bootstrap or request-routing/lifecycle path.

There is also a second-stage failure after recovery: the shell appears, but the sidebar remains on skeleton placeholders, the main panel is blank, and New chat does nothing.

During recovery the log records:

/wham/onboarding/context -> 500 Desktop network policy does not allow this destination
/settings/user -> 500 Desktop network policy does not allow this destination

and later:

/wham/tasks/list?limit=20&task_filter=current -> 499 Authenticated workspace changed
/wham/onboarding/context -> 499 Authenticated workspace changed

I do not see a later successful /wham/tasks/list retry in this reproduction. I also do not see thread/list or thread/read on the affected path. Meanwhile the replacement app-server continues answering other RPCs normally.

The renderer is not generally frozen: local UI controls remain responsive in the skeleton state, and Electron NetworkService has active established connections.

Strongest new signals:

initial app-server handshake succeeds;
codex-home starts but does not complete;
Desktop records app_start outcome=failure reason=timeout;
at app-server teardown pendingClientRequests=0;
app-server restart triggers recovery and route mounting;
task/history hydration then remains stuck after /wham/tasks/list returns 499 Authenticated workspace changed.

I have the full Desktop log from this reproduction and can provide a sanitized copy or additional event fields if useful.

Additional reproduction / workaround found after a full clean reinstall on Windows:

I completely removed Codex Desktop and all known local state before reinstalling:

removed the AppX package
removed .codex
removed Codex/OpenAI/ChatGPT AppData state
removed Codex runtimes/cache
removed the VS Code OpenAI/Codex extensions and staging directory
verified there was no codex command left
removed the remaining unregistered OpenAI.Codex_* package directories
rebooted Windows
installed Codex Desktop fresh from Microsoft Store

The exact same infinite startup spinner still reproduces.

I then found a reliable workaround:

Sign out of Codex Desktop.
Sign back in.
The application loads and works.
Fully Quit Codex Desktop.
Launch it again while the previously authenticated session is persisted.
The infinite startup spinner reproduces.
Signing out and signing back in makes the application load again.

So this now looks specifically related to the authenticated cold-start/bootstrap path rather than stale local installation state.

This also seems consistent with the earlier logs I posted here: the app-server successfully initializes, account/read / getAuthStatus succeed and report ChatGPT authentication, but the renderer/bootstrap remains stuck around the codex-home request until recovery. In other words, authentication itself can be valid while startup with an already-persisted authenticated session still stalls.

The full purge + reboot + clean Store reinstall rules out the previous local Codex state as a persistent cause in this reproduction.

Same symptoms here on Windows (26.928.40906 and 26.930.21537): the desktop log shows response_routed ... targetDestroyed=false for every request, but the window receives nothing, and a reload fixes it. While it was stuck, a message listener in the window recorded zero events for 12 s, and a probe request I sent was routed by the host but never arrived.

A likely cause is in the main process's chunked sender. Messages over 4 MiB are sent in parts, and the next part waits for the renderer's acknowledgeChunkedMessage, with no time limit. Meanwhile every other message to that window, small ones included, waits behind the transfer. One missing acknowledgement, plausibly a part that arrives before the renderer's handlers exist at startup, therefore blocks the window until a reload. Details and measurements: #50203

Navigation Menu

Repository navigation

[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) #45371

Summary

Environment

What the logs show

Why this machine hits it so often

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

Workarounds I am using

Suggestions

Environment

Symptoms and reproduction

Observed desktop log evidence

Requested outcome

2026-09-16 follow-up: still blocked after clean state and official package comparison

New checks

Narrowed failure boundary

Separate setup issue, already resolved

Limits and requested follow-up

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

[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) #45371

Description

Summary

Environment

What the logs show

Why this machine hits it so often

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

Workarounds I am using

Suggestions

Activity

github-actions commented on Sep 14, 2026

mower07 commented on Sep 15, 2026

Environment

Symptoms and reproduction

Observed desktop log evidence

Requested outcome

LeeDKuen commented on Sep 16, 2026

2026-09-16 follow-up: still blocked after clean state and official package comparison

New checks

Narrowed failure boundary

Separate setup issue, already resolved

Limits and requested follow-up

IvanTusset commented on Sep 26, 2026

IvanTusset commented on Sep 26, 2026

IvanTusset commented on Sep 26, 2026

IvanTusset commented on Sep 29, 2026

tomhda commented on Oct 2, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions