[Windows][26.825.4187.0] Startup blocked for 5+ minutes by pending in-app update policy after AppX transition

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 old 26.820.9563.0 desktop AppX container was destroyed.
• 21:48:38: the package state was updated successfully.
• 21:48:39: registration of 26.825.4187.0 completed successfully; the registration performance summary reports about 2344 ms.
• 22:01:31: the new package launched ChatGPT.exe successfully.
• 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.Codex currently reports Status: Ok and version 26.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.exe started successfully immediately after the policy wait timed out.
• A stale vendor_imports\\skills\\.git\\info\\sparse-checkout.lock caused 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

1. Have the Windows Store version of Codex Desktop installed.
2. Start the app around an AppX version transition or after the package has been updated.
3. Observe that the app process is created but no visible window appears.
4. Repeated launch attempts may create additional startup attempts that also stop at in_app_updates_policy_wait_started.
5. Wait several minutes.
6. The policy wait times out, then codex.exe starts 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:

• #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.
• #41015: that report describes the app remaining on an animation; this reproduction has a logged startup gate and eventual recovery after timeout.
• #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.

Start at the Windows desktop startup path around the logged in_app_updates_policy_wait_started gate and reproduce an AppX transition while capturing startup logs. Trace why the pending policy wait blocks app-server and window creation; done means the window becomes available promptly without waiting five minutes, with coverage for the pending-policy state.