Repository navigation
[Windows][26.820.9563.0] ChatGPT Desktop launches headless after upgrade from Classic; no renderer/window created #41179
Description
What version of the Codex / ChatGPT Desktop app are you using?
26.820.9563.0
Package:
OpenAI.Codex_26.820.9563.0_x64__2p2nqsd0c76g0
App ID:
OpenAI.Codex_2p2nqsd0c76g0!App
Executable:
app\ChatGPT.exe
Platform
Windows x64.
What issue are you seeing?
After upgrading from ChatGPT Classic to the new unified ChatGPT Desktop application, the application launches processes in the background but never creates a visible window.
ChatGPT Classic works correctly on the same machine. After upgrading to OpenAI.Codex 26.820.9563.0, multiple ChatGPT.exe processes start and remain responsive, but every process has:
MainWindowHandle = 0
MainWindowTitle = <empty>
The main process consumes substantial RAM/CPU and child processes are created, but the UI never appears.
This is related to #41059, but differs in one important way: no “Unable to locate the Codex CLI binary” dialog was observed in this reproduction. The app becomes headless directly after upgrading from ChatGPT Classic.
Process behavior observed
The main process starts normally:
ChatGPT.exe
It successfully creates:
- Crashpad handler
- GPU process
- Network utility process
Examples:
ChatGPT.exe --type=crashpad-handler
ChatGPT.exe --type=gpu-process
ChatGPT.exe --type=utility --utility-sub-type=network.mojom.NetworkService
However, no process with:
ChatGPT.exe --type=renderer
is ever created.
The primary ChatGPT.exe process was observed using roughly 480–540 MB RAM with ~52 threads and active CPU usage, while still having MainWindowHandle = 0.
This suggests initialization progresses significantly but stops before Chromium renderer/window creation.
Windows activation diagnostics
Windows reports successful package registration and activation.
Microsoft-Windows-AppModel-Runtime/Admin shows:
- Event ID 201: process created successfully for
OpenAI.Codex_2p2nqsd0c76g0!App - Event ID 210: Desktop AppX container created successfully
- Event ID 211: process added to Desktop AppX container successfully
Microsoft-Windows-TWinUI/Operational shows:
- Event ID 1621
- activation result:
0 - message indicates the operation completed successfully
Microsoft-Windows-AppXDeploymentServer/Operational confirms staging and registration of:
OpenAI.Codex_26.820.9563.0_x64__2p2nqsd0c76g0
completed successfully.
The package manifest reports:
Executable : app/ChatGPT.exe
EntryPoint : Windows.FullTrustApplication
Capabilities include:
appLicensing
runFullTrust
unvirtualizedResources
internetClient
Therefore, the failure appears to occur after Windows successfully transfers control to ChatGPT.exe.
User-data behavior
The Chromium crashpad process is launched with:
--user-data-dir=C:\Users\<USER>\AppData\Roaming\Codex\web\Codex
That directory was not created automatically.
To test whether this was a filesystem/permission issue, the directory was created manually. The user has full control permissions on %APPDATA%\Codex, but ChatGPT still did not populate the directory or create a UI.
The packaged app container under:
%LOCALAPPDATA%\Packages\OpenAI.Codex_2p2nqsd0c76g0
is created successfully with standard directories (LocalCache, LocalState, RoamingState, Settings, TempState, etc.), but no meaningful application state/log/database files appeared there during the failed launch.
Troubleshooting already performed
The following did not resolve the problem:
- Repair the application from Windows Settings.
- Reset the application.
- Completely uninstall
OpenAI.Codex. - Verify
Get-AppxPackage OpenAI.Codexreturns nothing after removal. - Reinstall ChatGPT Classic from Microsoft Store.
- Confirm ChatGPT Classic opens correctly.
- Upgrade again to the new unified ChatGPT Desktop app.
- Launch using:
shell:AppsFolder\OpenAI.Codex_2p2nqsd0c76g0!App - Launch
ChatGPT.exedirectly. - Launch with
--disable-gpu. - Launch with
--disable-gpu --disable-features=Vulkan. - Verify AppX registration / activation logs.
- Verify filesystem permissions for
%APPDATA%\Codex. - Manually create the expected Chromium user-data directory.
None of these changed the behavior.
Steps to reproduce
- Install ChatGPT Classic on Windows.
- Confirm ChatGPT Classic opens normally.
- Upgrade to the new unified ChatGPT Desktop app (
OpenAI.Codex 26.820.9563.0). - Launch ChatGPT.
- Observe multiple
ChatGPT.exeprocesses running in Task Manager / PowerShell. - No visible UI appears.
- Check processes:
Get-Process ChatGPT | Select Id,MainWindowTitle,MainWindowHandle,Responding,Path
- All processes show
MainWindowHandle = 0. - Inspect process command lines and observe crashpad/GPU/network utility children but no
--type=rendererprocess.
Expected behavior
The ChatGPT Desktop window should be created and displayed after launch.
A Chromium renderer process should start as part of normal UI initialization.
Actual behavior
The application remains running headlessly with no visible UI.
The main process remains responsive and uses CPU/RAM, but no renderer/window is created.
Impact
This is a blocking issue for the new unified ChatGPT Desktop application.
ChatGPT Classic remains usable, but it does not provide the newer unified ChatGPT / Work / Codex desktop experience.
Additional observations
The evidence suggests the failure is inside the application runtime between Chromium initialization and renderer/window creation, rather than AppX registration, package activation, GPU initialization, or basic filesystem permissions.
Related issue: #41059
Activity
github-actions commentedon Aug 27, 2026
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action
Arwen0707 commentedon Aug 28, 2026
Additional reproduction from another Windows user: the issue persists after updating/reinstalling to
OpenAI.Codex_26.820.10647.0_x64__2p2nqsd0c76g0.Observed sequence:
26.820.9563.0produced a Windows Application Hang /MoAppHang(Event ID 1002) forChatGPT.exe.26.820.10647.0underC:\Program Files\WindowsApps\....ChatGPT.exeprocesses remain responsive, but all showMainWindowHandle = 0and an emptyMainWindowTitle.--type=rendererprocess was observed.Troubleshooting performed on
26.820.10647.0with no fix:26.820.9563.0package remains registered.ChatGPT.exedirectly from the current package install location.--disable-gpu.--user-data-dir=....--no-sandbox(this produced no visible UI either).LocalCache; the app recreated a freshLocalCache, but still no window.CODEX_CLI_PATHexists and points to a validcodex.exe.Direct access (no proxy server).One visible symptom during normal/fresh-profile launches: the Windows taskbar briefly rearranges as if a window is being created, but no ChatGPT window ever appears and Alt+Tab shows no ChatGPT window.
This looks very similar to the original report, but importantly it is reproducible on the newer
26.820.10647.0build as well. The Codex CLI itself still launches successfully; the failure appears limited to the desktop GUI initialization / renderer-window creation path.purplelnb commentedon Aug 28, 2026
The issue still reproduces after updating from
26.820.9563.0to26.825.3734.0through the Microsoft Store.Current desktop package:
Observed behavior remains unchanged:
ChatGPT.exeprocesses start and remain responsive.MainWindowHandle = 0.MainWindowTitleis empty.codex-cli 0.150.0-alpha.8.I have already tried repairing/reinstalling the app, resetting the local configuration, rebooting Windows, and removing the suspected third-party input method. The CLI sandbox setup also completes successfully, but the desktop GUI still does not appear.
It appears that version
26.825.3734.0still fails before creating the renderer/window on this machine. Please let me know if additional logs or diagnostics from this version would be helpful.Ailbot123 commentedon Aug 28, 2026
The program successfully starts Chromium’s underlying process, but it gets stuck before the renderer or GUI window is created. I’m experiencing the same issue.
Ailbot123 commentedon Aug 28, 2026
now, you know how to solve this question?
Ailbot123 commentedon Aug 28, 2026
ChatGPT for Windows 26.820.9563.0 runs in background with no window, eventually recovers after waiting
Environment
ChatGPT desktop app for Windows
Version: 26.820.9563.0
The app had previously been working normally
I wanted to avoid Resetting the app or deleting AppData because I wanted to preserve local data
Symptoms
After launching ChatGPT:
ChatGPT.exe was visible in Task Manager
No application window appeared
Alt+Tab and window-moving shortcuts did not help
Rebooting Windows did not resolve the issue
I checked the process using PowerShell:
Get-Process ChatGPT |
Select Id, CPU, StartTime, Responding, MainWindowHandle, MainWindowTitle, Path
The result showed:
Responding : True
MainWindowHandle : 0
MainWindowTitle :
So the main process was alive and responding, but no actual window had been created.
Troubleshooting steps I tried
I first tried the usual steps, none of which fixed the issue immediately:
Killed all ChatGPT processes in Task Manager and relaunched the app.
Tried Alt+Tab, Win+Shift+Left/Right, etc. to make sure the window was not off-screen.
Fully rebooted Windows.
Went to Windows Settings → Apps → ChatGPT → Advanced options → Repair.
I did not use Reset, uninstall the app, or delete any local app data.
I then tried disabling Sparkle for that launch:
$env:CODEX_SPARKLE_ENABLED = "false"
and launched the packaged app using:
Get-Process ChatGPT -ErrorAction SilentlyContinue | Stop-Process -Force
$env:CODEX_SPARKLE_ENABLED = "false"
$pkg = Get-AppxPackage -Name OpenAI.Codex
$exe = Join-Path $pkg.InstallLocation "app\ChatGPT.exe"
Invoke-CommandInDesktopPackage
-PackageFamilyName $pkg.PackageFamilyName-AppId "App" `
-Command $exe
This also did not make the window appear immediately.
The log showed:
Launching app ... enableSparkle=false enableUpdater=true ...
Appshot hotkey inactive ...
So CODEX_SPARKLE_ENABLED=false did affect the launch, but enableUpdater was still true. Because of that, I cannot confirm that this environment variable contributed to the eventual recovery.
Additional diagnostics
The runtime directory contained:
cua_node
and there was no visible cua_node.staging-* directory, so at that point it did not appear to still be extracting the runtime.
The process tree contained:
ChatGPT.exe
--type=crashpad-handler
--type=gpu-process
--type=utility --utility-sub-type=network...
--type=utility --utility-sub-type=storage...
However, there was no process with:
--type=renderer
At the same time:
MainWindowHandle = 0
I also did not see a corresponding new Crashpad dump.
So the state appeared to be:
The main Electron/Chromium process and several helper processes had started successfully, but the renderer / GUI window had not yet been created.
Outcome
After completing the steps above, I did not Reset the app, uninstall it, or delete any local data.
After waiting for some time, the ChatGPT window suddenly appeared normally and the app started working again.
Therefore, I cannot identify one specific step as the definitive fix.
Based on the sequence of events, the most likely explanation is that:
Killing the previously stuck processes allowed a clean launch;
Windows Repair may have repaired some application files;
ChatGPT continued some initialization work in the background;
The renderer eventually started successfully and the GUI window was finally created.
One important detail is that even after launching with:
CODEX_SPARKLE_ENABLED=false
the application still remained for some time with:
MainWindowHandle = 0
and no renderer process. Therefore, I do not currently have evidence that disabling Sparkle itself was the actual fix.
Possible workaround / recommendation
For anyone seeing the same behavior, I would suggest trying the following before resetting or deleting application data:
Do not immediately Reset the app or delete AppData.
Kill all existing ChatGPT processes.
Run Windows Repair for the app.
Relaunch ChatGPT.
If the background process exists but MainWindowHandle = 0, wait for a while and check whether a renderer process eventually appears.
If it remains stuck, inspect the process tree and startup logs before attempting destructive troubleshooting.
In my case, the app eventually recovered without deleting local data and without performing a Reset.
LuoPoJunZi commentedon Aug 28, 2026
Additional reproduction from another Windows user: the issue persists after updating/reinstalling to OpenAI.Codex_26.820.10647.0_x64__2p2nqsd0c76g0
Ailbot123 commentedon Aug 28, 2026
sunzhelaw commentedon Aug 28, 2026
I can reproduce a closely related startup failure on Windows with the same package version,
OpenAI.Codex 26.820.9563.0.Observed behavior:
codex --versionworked normally from PowerShell and reportedcodex-cli 0.145.0, so the CLI itself was usable while the desktop GUI was unavailable.This pattern has also been noticeable after prior desktop updates: the first launch after an update can remain apparently headless for a long time before the window finally appears.
Even if part of this delay is caused by post-update runtime migration/extraction/initialization, the current UX makes the application look completely broken. It would help if the app created a minimal window immediately and surfaced a status such as “Finishing update / initializing runtime”, rather than leaving only background CPU activity with no visible feedback.
No local project folders,
.codexstate, or AppData were deleted in this reproduction.study-233 commentedon Aug 28, 2026
I can reproduce the same issue on a newer Codex Windows build.
Environment
OpenAI.Codex_26.825.3734.0_x64__2p2nqsd0c76g026.825.3734.0OkSymptoms
After the recent update, clicking Codex does not open any visible window.
The application itself does start successfully and creates multiple
ChatGPT.exeprocesses.Observed processes:
However, there is no
--type=rendererprocess.All processes have:
The main process remains responsive and uses substantial resources:
App log
The latest
codex-desktop-*.logstops immediately after:No renderer initialization messages appear afterwards.
Additional diagnostics
Get-AppxPackage -Name OpenAI.Codexreports:The
cua_noderuntime has already completed extraction:There is no
cua_node.staging-*directory.I also tested launching the executable with:
but the behavior remains unchanged: MAIN/GPU/utility processes start, but no renderer is ever created.
I also checked
~/.codex/config.toml; there is nountrusted,approval_policy, orallowed_approval_policiesconfiguration.This appears to confirm that the headless startup issue is still present in Windows build
26.825.3734.0.jingchunq306-dotcom commentedon Aug 28, 2026
Additional Windows reproduction from 2026-08-28.
Observed behavior:
Application Hangevents, Event ID1002, forChatGPT.exe.ChatGPT.exeversion151.0.7922.174stopped interacting with Windows and was closed.%USERPROFILE%\.codex\config.tomlto isolate the Codex configuration did not change the behavior, so the existing Codex config does not appear to be the trigger.Event Viewer also showed
AppModel-Statewarnings (IDs 20/21/23/24), but those entries explicitly referenceMicrosoft.MicrosoftPCManager_8wekyb3d8bbwe, so they appear unrelated to ChatGPT/Codex.This seems consistent with the headless/no-renderer symptom described in this issue, with the additional evidence of repeated
Application Hang 1002forChatGPT.exe 151.0.7922.174.Expected behavior: the unified ChatGPT desktop app should create a visible window within a few seconds after launch, or surface an actionable startup error instead of remaining headless in the background.
Israelgad commentedon Aug 28, 2026
I am experiencing the same issue on Windows with Codex Desktop
26.820.9563.0.Additional context that may be useful:
codex-cli 0.150.0CODEX_CLI_PATHto the nativecodex.exe. After doing this, Codex Desktop worked normally for the entire morning.Current behavior:
ChatGPT.exeprocesses start.MainWindowHandle = 0.Example PowerShell output:
Get-Process ChatGPT | Select-Object Id, MainWindowHandle, MainWindowTitle, Responding, CPUreturned multiple processes with:
MainWindowHandle : 0MainWindowTitle :Responding : TrueI also tested launching with
--disable-direct-composition, but this did not solve the problem.The externally configured Codex CLI itself still works correctly, and
CODEX_CLI_PATHstill points to a valid nativecodex.exe.This makes me wonder whether Desktop updates are changing the startup/runtime integration in a way that conflicts with, or bypasses, the
CODEX_CLI_PATHworkaround.It would be useful if the Desktop updater preserved a working CLI configuration across upgrades, or if Codex could fall back gracefully to a valid external CLI when the bundled CLI/runtime fails.
aamirsdev commentedon Sep 24, 2026
Windows: 26.917.6896.0 starts headless with "The process has no package identity" — caused by existing ~/.codex data
Versions
What happens
After the Store update, launching the app shows "ChatGPT failed to start. The process has no package identity."
ChatGPT.exe processes keep running in the background but no window is ever created
(5 processes, all with MainWindowHandle = 0). Possibly related to #41179.
Diagnostics
Get-AppxPackage OpenAI.Codex→ Status: Ok(events 201/210/211) and the container is destroyed ~6 seconds later (event 217),
so the main process does get package identity at launch.
shell:AppsFolder\OpenAI.Codex_2p2nqsd0c76g0!Appdid not help.Workaround that fixed the launch
Renaming
%USERPROFILE%\.codex(so the app starts with a fresh one) → app opens normally.So something in the existing ~/.codex data breaks startup of 26.917.
Data loss issue
The old folder has 630 sessions + 15 archived sessions and a valid
session_index.jsonl,but copying
sessions/,archived_sessions/andsession_index.jsonl[andthread_history_1.sqlite*/state_5.sqlite]into the new ~/.codex does not make the history appear in the sidebar.
Old chats are currently only usable by pointing a new chat at the rollout .jsonl files.
Expected
I can share file listings or run further diagnostics if helpful (without auth/secrets).
tolga-guldutuna commentedon Sep 25, 2026
A related operational workaround has been useful on systems where a Codex/ChatGPT Desktop upgrade is what triggers the headless state: stop doing unattended updates and make them explicit maintenance events.
I keep the Codex in-app updater disabled with
CODEX_SPARKLE_ENABLED=falseand Microsoft Store automatic app updates disabled viaAutoDownload=2. Before updating, I save the current package version/status plus the existing policy values, temporarily remove the blocks, update manually, then verify the registered package:Only after the intended build is actually registered with
Status: Okdo I re-enable the blocks.Full workflow:
#25770 (comment)
This is preventive, not a diagnosis of this issue's exact no-renderer/no-window root cause. It is useful mainly when the failure repeatedly follows automatic desktop package transitions.