[Windows][Regression] ChatGPT Desktop 26.820.9563.0 / 26.825.3734.0 hangs before renderer startup when bundled runtime relocation fails
Summary
After updating ChatGPT Desktop on Windows 11, the application no longer opens a window.
The application launches several background processes, but no UI window or renderer process is created. The main process remains busy-looping at approximately 100% CPU on one core indefinitely.
This appears to be a regression introduced after version 26.820.7780.0, which worked correctly on the same machine.
Environment
-
OS: Windows 11
-
Application: ChatGPT Desktop / OpenAI Codex
-
Package:
OpenAI.Codex -
Distribution: Microsoft Store / MSIX
-
Previously working version:
26.820.7780.0 -
Affected versions:
-
26.820.9563.0 -
26.825.3734.0
-
Symptoms
On every launch:
-
ChatGPT starts several background processes.
-
No application window appears.
-
No renderer process is spawned.
-
The main process remains running and busy-loops at approximately 100% of one CPU core.
-
The startup log stops at:
Appshot hotkey inactive
The application remains stuck indefinitely.
This happens consistently on every launch on this machine.
Reproduction
The issue can be reproduced after a clean installation.
For example:
winget install 9PLM9XGG6VKS
A clean reinstall does not resolve the problem.
I also removed third-party security software and rebooted Windows, but the issue remained unchanged.
Key Finding: bundled runtime relocation fails
Further investigation suggests that the affected versions attempt to copy bundled runtime files from the MSIX package into the user’s local application directory, including files such as:
codex.exe
cua_node
rg.exe
and associated runtime files.
On this particular Windows installation, the files inside the installed package are EFS/Application Protected.
cipher /c reports the package files as:
Application Protected
Windows’ filecrypt.sys encryption filter is active.
The application appears to relocate/copy these bundled runtime files to locations under:
%LOCALAPPDATA%\OpenAI\Codex\bin
%LOCALAPPDATA%\OpenAI\Codex\runtimes
However, the destination cannot be re-encrypted in the same way. Attempting to enable encryption manually with:
cipher /e
returns:
The request is not supported.
Therefore, the bundled-runtime relocation operation fails in this environment.
Important version comparison
The most significant evidence is the behavior difference between versions on the same machine.
26.820.7780.0
Worked normally.
When bundled runtime relocation failed, the application tolerated the failure and continued by falling back to running the bundled runtime directly from the installed package.
The application window opened normally.
26.820.9563.0
Does not start.
The application hangs before renderer startup.
26.825.3734.0
Same behavior as 26.820.9563.0.
The regression therefore appears to have been introduced after 26.820.7780.0.
Additional observation
I manually pre-placed the expected runtime files into the relevant %LOCALAPPDATA%\OpenAI\Codex directories.
This did not resolve the issue.
That suggests the startup hang is not simply caused by a missing runtime file. The failure appears to occur earlier in the main-process startup path, potentially while validating or attempting to perform the runtime relocation.
Working hypothesis
The likely sequence is:
MSIX package
↓
Bundled runtime files are Application Protected / EFS-encrypted
↓
New version attempts bundled-runtime relocation
↓
Destination cannot support the required encryption state
↓
Relocation/copy fails
↓
New startup path does not correctly handle the failure
↓
Main process enters a busy loop
↓
Renderer process is never spawned
↓
No ChatGPT window appears
This is currently a working hypothesis rather than a confirmed root cause.
The strongest evidence is that the same machine successfully ran 26.820.7780.0, while 26.820.9563.0 and 26.825.3734.0 consistently hang under the same filesystem/encryption conditions.
Requested fix
Please restore the previous fallback behavior when bundled-runtime relocation fails.
Specifically, if runtime files cannot be copied from the MSIX package to %LOCALAPPDATA%\OpenAI\Codex, the application should gracefully fall back to executing the bundled runtime directly from the installed package, rather than entering an indefinite startup loop.
At minimum, the relocation failure should be handled as a recoverable startup condition instead of preventing the renderer/UI from starting.
Why this may be related to other recent Windows startup reports
There are also recent reports of Windows builds in the 26.820.x series taking an unusually long time to start while extracting/initializing bundled runtime components.
My case appears to be a more specific failure mode where the relocation operation cannot complete because of the encryption state of the installed package/destination.
Expected behavior
If runtime relocation fails:
-
Log the relocation error.
-
Fall back to the bundled runtime in the MSIX package.
-
Continue normal application startup.
-
Spawn the renderer process.
-
Display the ChatGPT window.
Actual behavior
-
Background processes start.
-
Runtime relocation appears to fail.
-
Main process remains busy-looping.
-
Renderer process is never created.
-
No application window appears.
-
The application never recovers without terminating the process.
Thank you for investigating this regression.
reaction on the GitHub issue itself—not only on this forum topic. Reactions on GitHub can help the developers gauge the number of affected users.