[Windows][26.825.4187.0] Headless startup investigation: 300s update-policy gate persists after repair/reinstall

What version of the Codex App are you using (From “About Codex” dialog)?

26.825.4187.0

What subscription do you have?

ChatGPT Plus

What platform is your computer?

Microsoft Windows NT 10.0.26200.0 x64

What issue are you seeing?

Related to #41339. cc @selfrestart — this is a separate, detailed reproduction and exclusion log from another affected Windows system with the same Codex version and Windows build.

Environment

• Package: OpenAI.Codex_26.825.4187.0_x64__2p2nqsd0c76g0
• Codex App: 26.825.4187.0
• Windows: Microsoft Windows NT 10.0.26200.0 x64
• Subscription: ChatGPT Plus
• Chromium runtime reported by the app: 151.0.7922.174
• Microsoft Store product: 9PLM9XGG6VKS

ChatGPT Classic 1.2026.190.0 was also installed, but it used a separate package, executable path, and user-data directory. The investigation confirmed that the new Codex app was not loading binaries from the Classic package.

Initial symptom

Immediately after the Store update, clicking the Codex/ChatGPT icon produced no visible window and no taskbar entry.

The package's main ChatGPT.exe remained alive and spawned crashpad, GPU, network-service, and storage-service processes. However:

• No renderer process was created.
• No codex.exe app-server child process was visible.
• Every Codex ChatGPT.exe process reported MainWindowHandle: 0.
• There was no window title.
• The processes remained responsive according to Windows.
• Windows Application logs contained no corresponding crash or WER event.

The application therefore appeared to be running in the background, but no usable UI existed.

Startup-log evidence

A launch with Chromium logging enabled consistently reached:

[sparkle] in_app_updates_policy_wait_started timeoutMs=300000
Launching app ...
[AppServerConnection] Initializing app-server transport
[AppServerConnection] Starting app-server connection hostId=local transport=stdio

It did not proceed to a successful stdio transport spawn, app-server initialization handshake, renderer creation, or window ready-to-show during the short diagnostic observation windows.

This matches the startup gate described in #41339.

What steps can reproduce the bug?

The following investigation was performed in order to avoid assuming that this was only a damaged cache or mixed-version installation.

1. Package and process-path verification

   • Get-AppxPackage reported OpenAI.Codex version 26.825.4187.0, status Ok.
   • All new-app processes came from the current OpenAI.Codex_26.825.4187.0 package.
   • ChatGPT Classic processes came from their separate OpenAI.ChatGPT-Desktop_1.2026.190.0 package.
   • No cross-package executable reference was found.

2. Process/window verification

   • Main, crashpad, GPU, network, and storage processes existed.
   • No renderer and no app-server process existed.
   • Every main-window handle was zero.

3. Clean user-data test

   • Launched with a new temporary --user-data-dir.
   • The log confirmed that the temporary directory was selected.
   • The symptom remained unchanged.
   • The existing %USERPROFILE%\.codex, sessions, database, configuration, and auth.json were not deleted or reset.

4. GPU exclusion

   • Launched with --disable-gpu and --disable-gpu-compositing.
   • No renderer or window appeared.

5. File integrity and Windows security checks

   • Compared ACLs for ChatGPT.exe and bundled resources\codex.exe; permissions were equivalent.
   • Both executables had valid Authenticode signatures.
   • No Codex-specific block appeared in Code Integrity, AppLocker, Application Error, or Windows Error Reporting logs.
   • A Nahimic/A-Volute DLL event referred only to ChatGPT Classic and was unrelated.

6. Package recovery

   • Fully terminated the Codex process tree.
   • Relaunched through the registered AppsFolder application ID.
   • Used Windows Settings > Apps > ChatGPT > Repair.
   • Re-registered the existing AppxManifest.xml with Add-AppxPackage.
   • Removed only OpenAI.Codex.
   • Reinstalled Microsoft Store product 9PLM9XGG6VKS with winget.
   • The fresh installation again reported version 26.825.4187.0, status Ok, and reproduced the same headless startup state.

7. Important timing observation

   • During troubleshooting, controlled launches were observed for about 10–20 seconds and then terminated before the next isolation test.
   • Those restarts likely reset the timeoutMs=300000 update-policy wait each time.
   • This explains why the tests never reached the eventual recovery described in #41339: every attempt was stopped well before the five-minute policy timeout could expire.

Reproduction summary:

1. Update/install Codex Desktop 26.825.4187.0 from Microsoft Store.
2. Launch the app after the AppX transition.
3. Observe background ChatGPT.exe processes but no window, renderer, or app-server.
4. Observe in_app_updates_policy_wait_started timeoutMs=300000 in the startup log.
5. Repeated relaunch attempts restart the apparently blocked startup sequence.

What is the expected behavior?

The desktop window and renderer should become available promptly, and the bundled app-server should initialize without waiting for the in-app update-policy timeout.

The update-policy check should run asynchronously, fail quickly with a recoverable result, or otherwise avoid blocking the entire startup critical path. Repeated clicks should not make the application appear permanently headless by resetting a five-minute startup wait.

Additional information

Conclusion

This independent investigation supports the diagnosis in #41339:

• AppX installation and registration complete successfully.
• The desktop shell begins startup.
• The in-app update-policy state remains pending.
• Startup does not produce a usable renderer/window or completed app-server connection during that wait.
• Repeated diagnostic relaunches can make the condition appear permanent because they restart the timeout.

The strongest common signal is the pending in-app update-policy wait after the AppX transition, rather than renderer corruption, GPU state, mixed versions, invalid signatures, security enforcement, or user-data corruption.

No personal paths, credentials, session contents, or full unredacted logs are included in this report.

Start with the startup log at in_app_updates_policy_wait_started and compare the behavior with related issue #41339. Reproduce the launch without terminating it before the 300-second policy timeout, then verify whether the window, renderer, and bundled app-server initialize without the update-policy wait blocking startup.