Repository navigation
[Windows][26.825.4187.0] Startup blocked for 5+ minutes by pending in-app update policy after AppX transition #41339
Description
What version of the Codex / ChatGPT Desktop app are you using?
26.825.4187.0
Package:
OpenAI.Codex_26.825.4187.0_x64__2p2nqsd0c76g0
Platform
Windows x64, Windows build 10.0.26200.0.
What issue are you seeing?
After the Microsoft Store/AppX package transitioned from 26.820.9563.0 to 26.825.4187.0, launching the Windows desktop app could block for more than five minutes before the UI appeared.
The user clicked the desktop icon several times because there was no visible window. This produced multiple launch attempts, but the important failure was that each attempt stopped at the same startup gate. The final attempt eventually continued after the wait timed out.
This is not the same as a normal multi-instance warning, and it is not a renderer-only hang. The app's main process was created, but the startup critical path did not proceed to the app-server or visible window until the update-policy wait expired.
Evidence from the app logs
On the affected launch:
2026-08-28T14:01:33.160Z [sparkle] in_app_updates_policy_wait_started timeoutMs=300000
2026-08-28T14:07:10.475Z Failed to load shell env caller=startup detail="Timed out after 5000ms" durationMs=337306 status=timed_out
2026-08-28T14:07:10.476Z [sparkle] in_app_updates_policy_timeout policy=pending timeoutMs=300000
2026-08-28T14:07:12.887Z [StdioConnection] stdio_transport_spawned ... codex.exe
2026-08-28T14:07:13.569Z [startup] Host startup critical-path phases completed startupElapsedMs=341110
2026-08-28T14:07:14.260Z [window-manager] window ready-to-show appearance=primary
The durationMs=337306 value is approximately 5 minutes 37 seconds and overlaps the pending update-policy wait. The shell env message therefore appears to be a downstream timeout/reporting symptom rather than the initial cause.
Five earlier launch attempts on the same day produced only the initial startup lines and stopped at the same gate:
in_app_updates_policy_wait_started timeoutMs=300000
Launching app ... platform=win32
Appshot hotkey inactive ...
They did not reach StdioConnection, window ready-to-show, or the normal startup completion log.
Relevant Windows AppX timeline
Windows AppX logs show the following sequence:
21:45:21: deployment processing began for the Codex package.21:48:37: the old26.820.9563.0desktop AppX container was destroyed.21:48:38: the package state was updated successfully.21:48:39: registration of26.825.4187.0completed successfully; the registration performance summary reports about2344 ms.22:01:31: the new package launchedChatGPT.exesuccessfully.22:07:10: the in-app update-policy wait timed out.22:07:13: the app-server initialized and the main frame finished loading.
This suggests that AppX registration itself was successful and took seconds, while a subsequent startup coordination/update-policy state remained pending and blocked the app for several minutes.
Additional observations
Get-AppxPackage OpenAI.Codexcurrently reportsStatus: Okand version26.825.4187.0.- Windows NTFS health events reported all volumes healthy during the same period.
- No Application Error, Windows Error Reporting, or Application Hang event was recorded for the final launch window.
codex.exestarted successfully immediately after the policy wait timed out.- A stale
vendor_imports\\skills\\.git\\info\\sparse-checkout.lockcaused recommended-skills sync to fail later, but it did not explain the pre-window startup delay. - Some post-start API requests returned
401 Unauthorized; these occurred after the window was available and are unrelated to the startup delay.
Steps to reproduce / observed behavior
- Have the Windows Store version of Codex Desktop installed.
- Start the app around an AppX version transition or after the package has been updated.
- Observe that the app process is created but no visible window appears.
- Repeated launch attempts may create additional startup attempts that also stop at
in_app_updates_policy_wait_started. - Wait several minutes.
- The policy wait times out, then
codex.exestarts and the desktop window appears.
Expected behavior
The desktop window should become available promptly. An update-policy check should not block the entire startup critical path for five minutes. If the update policy is still pending, the app should continue starting and handle the update state asynchronously or fail it quickly with a recoverable result.
Actual behavior
The app waits approximately 5 minutes 37 seconds before continuing startup. During that time the user sees no usable desktop UI and cannot tell whether the launch succeeded.
Related issues / distinction
This appears distinct from:
- [Windows] Desktop app can remain headless for a prolonged period during startup before recovering #38766: the present reproduction is specifically tied to a pending in-app update-policy wait after an AppX version transition, with a measured 337-second startup delay.
- Codex suddenly won't open; only the animation plays #41015: that report describes the app remaining on an animation; this reproduction has a logged startup gate and eventual recovery after timeout.
- [Windows][26.820.9563.0] ChatGPT Desktop launches headless after upgrade from Classic; no renderer/window created #41179: that report describes a headless launch with no renderer/window created; here the renderer/window appears after the policy wait expires.
The issue is reproducible in the sense that multiple launch attempts on the same machine during this state stopped at the same startup gate, although the exact trigger for the pending policy state is not yet known.
Activity
github-actions commentedon Aug 28, 2026
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action
etoqeyeyise49-lang commentedon Aug 28, 2026
I can reproduce this repeatedly on the same Store build, including two separate launches on the same day. This adds a control showing that the local shell itself is fast while the pending update-policy gate remains on the startup critical path.
Environment
OpenAI.Codex_26.825.4187.0_x6426200Reproduction
Sanitized timelines
Launch A:
Launch B:
An earlier launch on the prior Store build showed the same downstream shell-env signature and recovered after about 602 seconds, but did not contain the update-policy lines in the filtered excerpt:
Shell control
Fresh local measurements:
There are no user or system PowerShell profile files on this machine. This makes a genuinely slow interactive PowerShell startup unlikely to explain the 387–506 second waits.
Interpretation
For the two current-build launches, the
Failed to load shell envduration overlaps the pending in-app update-policy wait and is logged at essentially the same moment asin_app_updates_policy_timeout. Once that gate returns, app-server initialization and window loading are fast. This supports the issue's conclusion that the update-policy state is the upstream blocker and the shell-env warning is a downstream/coincident symptom.I have intentionally omitted full raw logs because they contain local paths and workspace metadata. Sanitized excerpts can be expanded if maintainers need additional event names.
xxh16384 commentedon Aug 28, 2026
Independent reproduction on the same Windows Store build (
26.825.4187.0). This run is slightly different from the original report and may help narrow down the blocking point.Observed process state before the UI appeared
Get-AppxPackage OpenAI.CodexreportedStatus: Ok.--type=rendererprocess was present.ChatGPT.exeprocesses hadMainWindowHandle = 0and reportedResponding = True.Sanitized timeline
Notable difference from the original reproduction
In this run, the app recovered after about 282.3 seconds (~4m42s), i.e. before the configured
300000 msupdate-policy timeout. The captured log did not contain anin_app_updates_policy_timeoutline before the app-server spawned and the window appeared.The unusual part is that the shell-env operation reports
timeoutMs=5000but actually remained on the startup path for276754 ms. Once that call returned,codex.exespawned about 4 seconds later and the window became ready about 1 second after that.This suggests the pending update-policy state and shell-env/startup coordination are strongly correlated, but the UI may not be blocked strictly on the 300-second policy timeout itself. The renderer/window is never created during the long wait; after the wait clears, the rest of startup completes normally within a few seconds.
Full raw logs are omitted because they contain local paths and environment entries, but I can provide additional sanitized events if useful.
88766lawrence commentedon Aug 29, 2026
Independent reproduction on Windows with the same Microsoft Store build.
Environment
OpenAI.Codex_26.825.4187.0_x64__2p2nqsd0c76g0Reproduction
The behavior had also occurred the previous night. The app was usable the next morning, but restarting Windows reproduced the long invisible startup again.
Sanitized startup log
The UI became visible only after the wait period, at roughly
00:10Z. This independently confirms that the application can look completely dead during the pending update-policy gate and then recover without another launch attempt.No private paths or full raw logs are included.
Haoting-wang commentedon Aug 29, 2026
Independent reproduction on Windows with Codex Desktop
26.825.4187.0.What I observe
Codex (6)), including a main process using several hundred MB of memory.Troubleshooting already tried
The problem persists after reinstalling the same Store build.
Sanitized latest startup log
The log does not progress to
StdioConnection,startup critical-path phases completed, orwindow ready-to-show.This is slightly worse than the recoverable cases already described in this issue: on this machine the app can remain headless indefinitely rather than merely showing the UI after the ~300 s policy wait. Resetting and reinstalling do not clear the state.
I am omitting full raw logs because they contain local paths/user information, but I can provide additional sanitized events if maintainers need them.
redniu123 commentedon Aug 29, 2026
I can reproduce this issue on Windows with Codex Desktop 26.825.4187.0.
Package:
OpenAI.Codex_26.825.4187.0_x64__2p2nqsd0c76g0
After an update, Codex launches background ChatGPT.exe processes but no visible window appears.
My latest startup log stops at:
I confirmed that if I launch Codex once and wait for approximately 5 minutes, the application eventually opens successfully.
Reinstalling Codex did not fix the issue.
This strongly suggests the pending update-policy check is blocking the startup critical path.
Please do not block application startup on this update-policy state. The update check should run asynchronously, or fail quickly and allow the UI to start.
A five-minute invisible startup with background processes running makes the application appear completely broken and causes users to repeatedly launch or reinstall it unnecessarily.
redniu123 commentedon Aug 29, 2026
This behavior is unacceptable for production software.
A desktop application should NEVER block its entire startup path for five minutes just because an update-policy state remains pending. An updater is a secondary component. It should not be allowed to make the core application appear completely dead.
What makes this especially bad is the user experience:
From the user's perspective, the application is simply broken.
This design actively encourages users to repeatedly click the application, kill processes, reinstall Codex, reset application data, clear caches, and potentially put valuable local sessions and configuration at risk — all because a non-critical updater component is blocking the startup critical path.
That is not a minor UX issue. It is a serious reliability and architectural failure.
An update check should be asynchronous. If the update service is unavailable, stuck, or returns a pending state, Codex should start normally and handle the update in the background. Under no reasonable design should an updater be able to hold the entire application hostage for five minutes.
I reproduced this on Codex Desktop 26.825.4187.0. The log clearly shows:
After approximately five minutes, Codex finally opens.
Please treat this as a high-priority regression.
More importantly, please reconsider the architecture that allows an update-policy check to block application startup at all. A failure in an optional update mechanism must never translate into a five-minute failure of the primary product.
For a developer tool that users may depend on for important projects and valuable local work, this level of startup reliability is simply not acceptable.
Ever-scut commentedon Aug 29, 2026
Independent reproduction on Windows with Codex Desktop package
OpenAI.Codex_26.825.4187.0_x64__2p2nqsd0c76g0.Additional data point
On this machine, a normal launch created the ChatGPT/Codex background process group but no visible window. The startup log contained:
The UI finally became visible at approximately 15:41 local time (UTC+8), i.e. roughly 8 minutes after the logged startup gate began. This is longer than the configured 300,000 ms policy timeout and suggests that some affected launches can remain blocked substantially beyond five minutes.
Workaround test
Before this launch, the app was started with the process environment variable:
and launched from the installed AppX package. The log still reported:
so disabling Sparkle through this environment variable did not bypass the pending update-policy startup gate on this build.
No private paths or full raw logs are included. This appears to be the same startup-blocking regression described in this issue, with a longer observed recovery time.
yuyi-coder commentedon Aug 29, 2026
Independent follow-up after a full Windows restart. The issue persists on a newer Store package, so restarting Windows did not clear the condition and the regression is not limited to
26.825.4187.0.Environment
OpenAI.Codex_26.825.4187.0_x64__2p2nqsd0c76g0OpenAI.Codex_26.825.5331.0_x64__2p2nqsd0c76g0Latest sanitized timeline
The UI was unavailable for about 397.7 seconds (6m38s). Once the pending update-policy wait returned,
codex.exespawned and the window became ready in roughly four seconds.Additional controls
0.25-0.32 s.314.2 sand360.9 s; this latest build measured397.7 s.The reported shell-env duration again ends at essentially the same instant as
in_app_updates_policy_timeout, despite its nominaltimeoutMs=5000. This makes the shell-env warning look downstream or coincident rather than the primary cause. The strongest correlation remains the pending update-policy gate on the startup critical path.Full raw logs are intentionally omitted because they contain local paths, environment entries, and workspace metadata.
etoqeyeyise49-lang commentedon Aug 29, 2026
Additional independent reproduction on the newer Store package, with a substantially longer delay than the earlier reports.
Environment
OpenAI.Codex_26.825.5331.0_x640.151.0-alpha.7.126200User-visible result
The app was launched normally at approximately 21:36 local time (UTC+8). Background processes existed, but the usable main window did not finish loading until approximately 21:49. No reset, reinstall, cache deletion, or forced termination was performed; the app eventually recovered on its own.
Sanitized startup timeline
Total measured startup time was 736,783 ms (12m16.8s). The nominal five-minute update-policy timeout did not return until approximately 729 seconds had elapsed. After
in_app_updates_policy_timeoutwas logged, app-server initialization and main-frame loading completed in about 6.6 seconds.Why this is useful
This confirms that the regression persists on
26.825.5331.0with the newer bundled app-server0.151.0-alpha.7.1, and that affected launches can exceed both the nominal 5-second shell-env timeout and the 300-second update-policy timeout by a large margin. The tight timestamp alignment again indicates that the shell-env warning is downstream or coincident, while the strongest observable startup gate remains the pending update-policy wait.Full raw logs are intentionally omitted because they contain local paths and workspace metadata. No sensitive paths, environment values, account identifiers, or project content are included above.
yuan86927 commentedon Aug 29, 2026
Independent reproduction on another Windows system with the same Codex App version:
26.825.4187.0.I encountered almost exactly the same startup behavior.
Initial symptom
Launching Codex created multiple
ChatGPT.exeprocesses, but no visible window appeared.Get-AppxPackageshowed that the package itself was correctly installed:The Start menu registration was also present:
Window state
I checked all Codex/ChatGPT processes with:
There were six responsive
ChatGPT.exeprocesses, but every process showed:So this was not an off-screen or hidden window: no main window had been created.
config.toml exclusion test
I temporarily renamed
%USERPROFILE%\.codex\config.tomland launched Codex without the configuration file.The behavior was unchanged:
ChatGPT.exeprocessesMainWindowHandle = 0I therefore restored the original configuration.
Long startup observation
I terminated all existing processes, launched Codex exactly once using:
Then I monitored the processes every 10 seconds.
The result stayed unchanged for the full 420-second observation period:
Immediately after this observation period completed, the Codex desktop window appeared.
Subsequent launch
After the first successful startup, I closed Codex, terminated the processes, and launched it again.
This time:
The GUI appeared normally within approximately five seconds.
Conclusion
This independent reproduction strongly matches the behavior described in this issue:
In my case, removing
config.tomldid not change the behavior, and AppX package registration remained healthy throughout.I did not reset or reinstall the application. Simply allowing the initial startup to continue long enough eventually resolved the state.
Hopefully this additional reproduction helps confirm the scope of the Windows startup issue.
etoqeyeyise49-lang commentedon Aug 30, 2026
Additional same-day control on the newer Store package: one launch completed normally in 7.5 seconds, while a later launch on the same machine and configuration was blocked for 10m11.5s. This makes the intermittent/race-like nature of the update-policy startup gate especially clear.
Environment
OpenAI.Codex_26.825.6671.0_x640.151.0-alpha.7.226200Fast control launch
The main window became available in 7,544 ms (7.5s) even though the update policy later remained
pending. In this launch, policy evaluation did not block first-window creation.Slow launch later the same day
The slow launch took 611,546 ms (10m11.5s). Once the update-policy timeout returned, app-server initialization and main-frame loading completed within roughly six seconds.
Four intervening launch attempts produced only the initial
in_app_updates_policy_wait_startedandLaunching applines, without reaching app-server initialization or window creation. This is consistent with repeated user attempts while the application remained invisible, rather than ordinary slow rendering.Interpretation
Both the fast and slow launches began update-policy evaluation, and the fast launch demonstrates that a
pendingpolicy state does not inherently require blocking the UI. The failure appears intermittent: in the healthy path, the main window starts while policy evaluation remains pending; in the failing path, the same policy state blocks the startup critical path for approximately ten minutes. This comparison may help isolate a latch/coordination race rather than a consistently slow dependency.Full logs and local paths are intentionally omitted.
etoqeyeyise49-lang commentedon Sep 3, 2026
Follow-up from the same machine on 2026-09-03: prolonged startup has recurred after updating to a newer desktop package, following several much faster launches in the intervening days.
Affected version
OpenAI.Codex_26.901.1978.0_x640.153.0-alpha.5Latest completed launch — sanitized timeline (UTC)
The app reports 594,322 ms (9m54.3s) for this completed launch. After the policy timeout was logged, main-frame loading completed in about 6.4 seconds; the app-server handshake itself took 991 ms.
Three earlier attempts at 09:47:47, 09:51:04, and 09:54:32 UTC contain the initial policy-wait/launch messages but no startup-completion or window-load event. The span from the earliest attempt to the eventual window load was approximately 21m36s. That is a multi-attempt wall-clock span, not the duration of one continuously running startup.
Intermittency and interpretation limits
26.901.1978.0; it does not by itself prove that this update introduced a new regression.Please investigate why these early-startup operations can exceed their nominal 5-second and 300-second timeouts while delaying the first usable window. Full raw logs, local paths, environment values, account details, and workspace content are intentionally omitted.
etoqeyeyise49-lang commentedon Sep 5, 2026
再次上报：2026-09-05 仍然出现同样超慢启动
今天再次命中同类现象（同上次 #41339/#41539 的行为）：
C:\Users\13711\AppData\Local\Codex\Logs\2026\09\05\codex-desktop-0e237c5e-cc72-4a5b-968b-6ffcea6abf83-30212-t0-i1-153025-0.log2026-09-05T15:30:25.199Zin_app_updates_policy_wait_started timeoutMs=3000002026-09-05T15:38:36.219ZFailed to load shell env caller=startup detail="Timed out after 5000ms." durationMs=4910182026-09-05T15:38:36.220Zin_app_updates_policy_timeout policy=pending timeoutMs=3000002026-09-05T15:38:39.632Z[startup] Host startup critical-path phases completed startupElapsedMs=4948192026-09-05T15:38:40.115Zwindow ready-to-show ... startupElapsedMs=4216补充：同一天 15:15 与 15:24 的启动也只停在
in_app_updates_policy_wait_started，未继续；另有一次t2启动显示 WSL 检测返回二进制错误。建议与 #41539 的同步修复归并看待：
in_app_updates_policy_wait与Failed to load shell env挂起/计时异常仍在临界路径上iiiiiiiii111iii commentedon Sep 6, 2026
Independent reproduction on Windows with newer Codex Desktop package
26.901.6511.0_x64; the previous26.901.5280.0_x64package was also affected.Latest launch:
Previous package:
Controls:
This supports an intermittent Codex startup-path/timer defect rather than a consistently slow user shell. Please enforce the five-second timeout without blocking first-window creation.
No usernames, private paths, credentials, session content, or complete logs are included.
luaelsia commentedon Sep 11, 2026
I'm experiencing this issue repeatedly.
The logs from the update through the first successful launch show the following sequence:
0x80073D02 (ERROR_PACKAGES_IN_USE)ForceTargetApplicationShutdownOptiondllhost.exe (COM Surrogate)associated with the old Codex package hitMoAppHangTerminateApplicationsthen succeeded and package registration completedChatGPT.exeand GPU/network/storage processes started, but no renderer or window was createdObserved sequence:
update → 0x80073D02 → forced-shutdown retry → ~94s termination stall / dllhost MoAppHang → update completes → first launch has no renderer for ~4 min → GUI appears → subsequent launches normalI haven't confirmed a direct causal relationship between the update/termination failure and the subsequent ~4-minute startup stall, but they occurred consecutively during the same update transition.
aiken070707 commentedon Sep 17, 2026
Also reproducing this on Windows, on two separately managed devices, on
26.908.9136.0. Same pairing you describe: in_app_updates_policy_wait_started
timeoutMs=300000 followed by a shell-env step whose 5000 ms timeout returns
after 158-684 seconds. Posting 11 measurements and a runtime-extraction
correlation in #41539 to keep it in one place.
tolga-guldutuna commentedon Sep 25, 2026
One caution from a related workaround I am using: I would not describe
CODEX_SPARKLE_ENABLED=falseas a direct fix for this specific startup-policy stall. This thread already contains evidence that, on26.825.4187.0, the app still loggedenableUpdater=trueand enteredin_app_updates_policy_wait_startedeven when the environment variable was set.What has been useful operationally is preventing the machine from entering these unattended post-update transitions in the first place:
AutoDownload=2policy;OpenAI.Codexpackage is the intended version andStatus: Ok, then re-block.I documented the backup/unblock/manual-update/re-block workflow here:
#25770 (comment)
So this is only a preventive maintenance workaround, not a bypass for the pending-policy gate shown in this issue. The Store policy is also machine-wide, so it affects automatic updates for all Store apps.