›_ Codex Issues
Codex Issues / #38766

[Windows] Desktop app can remain headless for a prolonged period during startup before recovering

Open 💬 6 comments Opened Aug 15, 2026 by yyysheng

What version of the Codex App are you using?

Microsoft Store / Windows package observed in logs:

OpenAI.Codex_26.810.7004.0_x64__2p2nqsd0c76g0

Bundled app-server version later reported:

0.148.0-alpha.9

What subscription do you have?

ChatGPT Plus

What platform is your computer?

Windows 11 x64

What issue are you seeing?

On launch, the desktop app created multiple ChatGPT.exe processes and consumed high CPU for several seconds, then settled to a lower sustained level, but no visible window appeared.

PowerShell showed every ChatGPT process with MainWindowHandle = 0 while the app remained alive and responsive at the process level.

The desktop log shows that startup began, immediately hit bundled executable relocation failures for both rg.exe and codex.exe, and then remained stuck for a prolonged period before finally spawning the bundled Codex process.

When startup resumed, the log recorded a shell-environment loading timeout whose measured duration was far longer than the configured timeout:

warning Failed to load shell env caller=startup
  detail="Timed out"
  status=timed_out

Immediately after that delayed point, startup proceeded normally:

stdio_transport_spawned ... codex.exe
Codex CLI initialized
window main frame finished load
window ready-to-show
React root render requested ... rendererWindowVisible=true

The app eventually recovered without reinstalling or resetting it.

Relevant startup sequence

Launching app
bundled_executable_relocation_failed ... rg.exe
bundled_executable_relocation_failed ... codex.exe

[prolonged stall lasting several minutes]

stdio_transport_spawned ... codex.exe
Failed to load shell env
Codex CLI initialized
window ready-to-show

Control case: immediate relaunch

A subsequent launch shortly afterward behaved normally even though the same executable relocation warnings still occurred:

Launching app
bundled_executable_relocation_failed ... rg.exe
bundled_executable_relocation_failed ... codex.exe
stdio_transport_spawned ... codex.exe
Codex CLI initialized
window ready-to-show

This suggests bundled_executable_relocation_failed alone is recoverable and is not sufficient to cause the prolonged headless startup. The unusual behavior appears to be the startup recovery / shell-environment path blocking for far longer than expected.

Steps to reproduce

I do not yet have deterministic reproduction steps. The observed sequence was:

  1. Launch the Windows desktop app from its shortcut.
  2. ChatGPT.exe processes appear immediately.
  3. CPU usage rises sharply for several seconds, then settles to a lower sustained level.
  4. No window appears.
  5. Get-Process ChatGPT | Select Id, CPU, Responding, MainWindowHandle, MainWindowTitle, Path reports MainWindowHandle = 0 for all processes.
  6. After a prolonged period, the startup chain resumes and the UI becomes available.
  7. A later relaunch completes normally within a short time.

Expected behavior

The desktop window should appear promptly. If shell-environment discovery or bundled executable relocation fails, that recovery path should respect its timeout and should not block first-window creation for several minutes.

Ideally the app should also surface a visible recovery/error state instead of remaining as background processes with no window.

Additional information

The same launch also contained file-copy warnings while relocating bundled executables from the WindowsApps package into the per-user Codex directory. Since those warnings also appear during the later healthy launch, they may be related context rather than the direct cause.

I am intentionally not attaching the complete raw desktop logs because they contain local paths and other metadata. I can provide sanitized excerpts or additional diagnostics if requested.

Possibly related reports include Windows startup/no-window and startup-hang issues such as #28046 and #23207, but this case differs in that the process remains alive, later recovers, and records a shell-environment timeout whose observed duration is far beyond the configured timeout.

View original on GitHub ↗

6 Comments

zemeng5208 · 11 days ago

I maintain WinBridge Recovery, an independent Windows recovery tool for Codex/Desktop local plugin/runtime state: https://github.com/zemeng5208/winbridge-recovery

This report looks relevant specifically to the local bundled-executable relocation/staging layer. WinBridge can help diagnose whether the installed package and the per-user recovery/staging state have drifted after an update, including the package version/hash inputs, CUA/runtime paths derived from the installed package, and stale or incomplete user-side copies that can make helper relocation repeatedly fail. It can also rebuild the recoverable user-side state from the official package already installed on the machine, with backup/rollback checks.

That said, I would not treat it as a guaranteed fix for this issue. Your own control case is important: the same bundled_executable_relocation_failed warnings also appear on a later healthy launch, while the several-minute stall lines up with shell-environment/startup recovery taking far longer than its configured timeout. If the relocation warnings are only incidental and the real blocker is the upstream shell-env/startup state machine, WinBridge will not fix that logic. It also does not take ownership of or patch C:\Program Files\WindowsApps, bypass package protection, or modify the signed MSIX.

So the useful boundary here is: WinBridge may help determine whether there is a repairable local relocation/staging inconsistency behind the rg.exe / codex.exe copy warnings; if those layers are already internally consistent, this should remain an upstream Desktop startup/timeout investigation rather than a local-repair case.

mouhsine-dev · 9 days ago

I may be seeing a related startup failure on a newer Windows build.

After an unexpected computer shutdown, the Codex/ChatGPT Windows desktop app became permanently stuck in a startup/loading loop.

Installed package:
OpenAI.Codex_26.814.5167.0_x64__2p2nqsd0c76g0

ChatGPT.exe version:
151.0.7922.137

Windows Event Viewer records:
Application Hang, Event ID 1002

HangType: Top level window is idle

The app creates its visible window but never finishes loading.

The ChatGPT web app works normally on the same machine/account.

Troubleshooting attempted with no change:

  • terminate/relaunch
  • Windows Repair
  • Windows Reset
  • uninstall/reboot/reinstall
  • wsreset.exe
  • launch with --disable-gpu
  • rename/clear package LocalCache

Unlike the behavior described in this issue, mine has not recovered after waiting/relaunching.

This started immediately after an unexpected Windows shutdown.

rinal-cpu · 1 day ago

I can reproduce this on a newer Microsoft Store build, with a deterministic delay after every Windows reboot.

Environment

  • Desktop package: OpenAI.Codex_26.820.7780.0_x64
  • Bundled app-server: 0.150.0-alpha.8
  • Windows x64, version 25H2, build 26200.9168
  • Enterprise endpoint security and Microsoft Defender are active

Observed behavior

  1. Launch ChatGPT from the Start menu after reboot.
  2. Task Manager immediately shows the ChatGPT process group (eight processes), but no window.
  3. The window appears about 4.5 minutes later and then becomes unresponsive.
  4. The problem returns after the next reboot.

Sanitized startup timeline

01:04:27.678Z info Launching app platform=win32
01:04:56.090Z warning bundled_executable_relocation_failed errorCode=EPERM operation=rename_staging executableName=node.exe
01:05:56.618Z warning bundled_executable_relocation_failed errorCode=EPERM operation=rename_staging executableName=node.exe
01:06:45.121Z warning bundled_executable_relocation_failed errorCode=EPERM operation=rename_staging executableName=node_repl.exe
01:07:52.032Z warning bundled_executable_relocation_failed errorCode=EPERM operation=rename_staging executableName=node.exe
01:07:53.217Z warning Failed to load shell env caller=startup status=timed_out durationMs=205534 detail="Timed out after 5000ms."
01:08:51.593Z warning bundled_executable_relocation_failed errorCode=EPERM operation=rename_staging executableName=node_repl.exe
01:08:53.645Z info initialize_handshake_result outcome=success
01:08:55.572Z info window main frame finished load
01:08:55.833Z info startup critical-path phases completed startupElapsedMs=269438

The same session later reports:

warning plugin_install_failed errorCategory=cache_overwrite_failure errorMessage="Access is denied. (os error 5)"
warning bundled_plugins_marketplace_install_failed errorCategory=plugin_cache_windows_file_lock

The failing runtime destination is:

%LOCALAPPDATA%\OpenAI\Codex\runtimes\cua_node\<runtime-hash>

The parent directory is owned by the current user and grants Full Control, so this does not appear to be a simple directory ACL problem. The final runtime directory is never created. Repeated launches have accumulated 143 .staging-* directories alongside only three completed runtime directories.

This evidence points to a transient Windows file lock or security-scanning interaction during the atomic staging rename. Regardless of the lock source, the app retries on the startup critical path for several minutes, delays window creation, and then continues into a degraded/unresponsive state.

It would help if the relocation/cache code could:

  • distinguish a sharing violation or transient security lock from a permanent permission failure;
  • use bounded retry/backoff without blocking first-window creation;
  • clean abandoned staging directories;
  • surface an actionable recovery message; and
  • handle plugin-cache Windows file locks through the same recovery path.

I am not attaching the full raw log because it contains local paths and account/workspace metadata, but I can provide additional sanitized diagnostics if needed.

The19750907 · 1 day ago

I can reproduce the same headless startup behavior on a newer Microsoft Store build.

Environment

  • Desktop package: OpenAI.Codex_26.820.9563.0_x64
  • Windows x64
  • AppX package status: Ok
  • Standalone Codex CLI works normally (codex-cli 0.149.1)
  • CODEX_CLI_PATH points to a valid executable

Observed behavior

  1. Launch Codex after the update.
  2. Multiple ChatGPT.exe processes appear in Task Manager, but no visible window is created.
  3. During the stall, every related process reports MainWindowHandle = 0.
  4. After a long delay, the window eventually appears without reinstalling or resetting the app.
  5. Closing and immediately relaunching afterward is fast (a few seconds).

Sanitized startup timing from logs

Failing launch:

06:55:31.826  Launching app
[~159 s stall]
06:58:10.821  Failed to load shell env ... detail="Timed out after 5000ms."
06:58:12.111  stdio_transport_spawned
06:58:12.473  Codex CLI initialized
06:58:12.641  window ready-to-show

Immediate subsequent healthy launch:

07:00:37.267  Launching app
07:00:38.087  stdio_transport_spawned
07:00:38.256  Codex CLI initialized
07:00:40.198  window ready-to-show

So the failing startup spends roughly 159 seconds before the shell-environment timeout surfaces, even though the log says Timed out after 5000ms. Once that returns, CLI initialization and window creation complete within about 2 seconds.

PowerShell control measurement

To rule out a slow shell/profile as the cause:

powershell.exe -NoLogo -NoProfile -Command "exit"  -> ~212 ms
powershell.exe -NoLogo -Command "exit"             -> ~198 ms

This suggests the shell itself is healthy; the prolonged delay appears to be inside the desktop app's shell-environment discovery / timeout / recovery path.

One additional detail: in the filtered failing startup excerpt I did not observe bundled_executable_relocation_failed, so executable relocation may not be required to reproduce the prolonged headless startup.

This appears to confirm that the issue is still reproducible on 26.820.9563.0, and that the nominal 5-second shell-env timeout can block first-window creation for far longer than expected.

selfrestart · 21 hours ago

Additional reproduction/evidence from another Windows machine on the same current Store build. This looks like the same prolonged headless startup pattern, but with Windows event-log evidence that the previous launch was also reported as a MoAppHang and with an AppX update/register sequence immediately before recovery.

Environment

  • Desktop package: OpenAI.Codex_26.820.9563.0_x64__2p2nqsd0c76g0
  • ChatGPT.exe version in WER: 151.0.7922.170
  • Package status: Ok
  • Package source: Microsoft Store
  • Windows: x64, build observed in WER as 10.0.26100.9168 / OS 10.0.26200 family

User-visible behavior

After clicking the ChatGPT/Codex desktop icon, nothing visible appeared. Repeated clicks and a reboot did not immediately help. After waiting for a while, the app window suddenly appeared and became usable.

Windows/AppX timeline

Local time:

21:14:11  Windows booted
21:18:55  Windows Error Reporting: EventType=MoAppHang
          TargetAppId=U:OpenAI.Codex_26.820.9563.0_x64__2p2nqsd0c76g0!App
          AppName=Codex
          AppPath=...\OpenAI.Codex_26.820.9563.0_x64__2p2nqsd0c76g0\app\ChatGPT.exe
          FriendlyEventName=Stopped responding and was closed
          Hang Type=2097152
21:18:56  Application Hang event 1002: ChatGPT.exe stopped interacting with Windows and was closed
21:21:03  AppXDeploymentServer: Register operation for OpenAI.Codex completed successfully
21:21:04  WindowsUpdateClient: installed update `9PLM9XGG6VKS-OpenAI.Codex`
21:24:02  AppModel-Runtime created the OpenAI.Codex App process
21:28:45  Desktop log: main window frame finished load / ready-to-show shortly after

Desktop logs

Several launches after the update only reached the first two startup lines and then stopped:

13:21:08 Launching app ... packaged=true platform=win32
13:21:08 Appshot hotkey inactive configured=true enabled=false platform=win32

13:21:36 Launching app ... packaged=true platform=win32
13:21:36 Appshot hotkey inactive configured=true enabled=false platform=win32

13:22:47 Launching app ... packaged=true platform=win32
13:22:47 Appshot hotkey inactive configured=true enabled=false platform=win32

The launch that eventually recovered started at 13:24:03 UTC and only completed the visible-window path around 13:28:45 UTC:

13:24:03.380 Launching app ... packaged=true platform=win32
13:28:44.044 warning Failed to load shell env caller=startup
             detail="Timed out after 5000ms."
             durationMs=280663
             status=timed_out
             timeoutMs=5000
13:28:45.611 window main frame finished load ... startupElapsedMs=2037
13:28:45.644 Host startup critical-path phases completed startupElapsedMs=282549
13:28:45.880 window ready-to-show ... startupElapsedMs=2306

So the app was effectively headless for about 4m40s. Once the shell-env step returned, the remaining window/app-server initialization completed quickly.

Process state after recovery

After the app recovered, the process tree was healthy and responsive. The main process was:

ChatGPT.exe PID 15856
Path: C:\Program Files\WindowsApps\OpenAI.Codex_26.820.9563.0_x64__2p2nqsd0c76g0\app\ChatGPT.exe
Responding: True

A bundled CLI child process was also running from the per-user materialized path:

%LOCALAPPDATA%\OpenAI\Codex\bin\d5f4c71927a04589\codex.exe

Additional observations

  • I did not observe bundled_executable_relocation_failed in the relevant filtered startup excerpt for this recovered launch.
  • I did observe repeated bundled plugin marketplace copy failures later, under %USERPROFILE%\.codex\.tmp\bundled-marketplaces\openai-bundled.staging-*, but those appear to be post-window/plugin-sync noise rather than the blocker for first-window creation.
  • The shell itself does not appear obviously broken from normal interactive use; the suspicious part is again that a timeoutMs=5000 shell-env operation reports durationMs=280663 and blocks first-window creation.

This seems to add two useful details to the existing pattern:

  1. The same issue is still reproducible on 26.820.9563.0 after a Microsoft Store update/register event.
  2. Windows may record the earlier failed launch as MoAppHang / Application Hang even though a later launch eventually recovers after the long shell-env delay.
The19750907 · 5 hours ago

Follow-up: the same prolonged headless startup is still reproducible after updating to a newer Microsoft Store build.

Environment

  • Desktop package: OpenAI.Codex_26.825.3734.0_x64
  • AppX package status: Ok
  • Same Windows machine as my earlier 26.820.9563.0 reproduction

New failing startup timeline

The app was launched and remained headless for about four minutes before the window appeared on its own.

Sanitized log timeline:

05:48:36.368Z  Launching app
[~235 s headless stall]
05:52:31.650Z  warning Failed to load shell env caller=startup detail="Timed out after 5000ms."
05:52:33.944Z  stdio_transport_spawned
05:52:34.289Z  window main frame finished load
05:52:34.383Z  initialize_handshake_result
05:52:34.383Z  Codex CLI initialized
05:52:34.505Z  window ready-to-show

The log also reports:

startupElapsedMs=238274

So total startup was about 238.3 s (3m58s), while the shell-env operation still reports a nominal timeout of 5000 ms.

Once the shell-env step returned, the rest of startup completed in roughly 3 seconds.

Healthy control launch on the same machine

A separate normal launch on the same build completed in about 6 seconds:

00:47:51.810Z  Launching app
00:47:56.750Z  stdio_transport_spawned
00:47:57.085Z  window main frame finished load
00:47:57.299Z  window ready-to-show
00:47:57.437Z  initialize_handshake_result
00:47:57.440Z  Codex CLI initialized
startupElapsedMs=6111

This gives a same-machine comparison of roughly 6.1 s normal vs 238.3 s failing.

The behavior is therefore still reproducible on 26.825.3734.0, and the failure pattern again points to the shell-environment discovery / timeout / recovery path blocking first-window creation far beyond the nominal 5-second timeout.