Repository navigation
[Windows][26.721.4979.0] ChatGPT.exe exits silently about 30 seconds after launch; AppX container is destroyed without a crash event #35560
Description
What version of the Codex App are you using (From “About Codex” dialog)?
- Microsoft Store package:
OpenAI.Codex_26.721.4979.0_x64__2p2nqsd0c76g0- Executable:ChatGPT.exe- Browser component release observed in the desktop log:26.721.41059
What subscription do you have?
chatgpt pro x20
What platform is your computer?
- Windows 11 Enterprise, version
10.0.22631, x64 - NVIDIA GeForce RTX 4050 Laptop GPU, driver32.0.15.6094- Intel Arc Graphics, driver31.0.101.5333- Citrix Indirect Display Adapter, driver12.40.44.247
What issue are you seeing?
After updating the Windows desktop app to 26.721.4979.0, the app repeatedly exits without an error dialog shortly after launch. The main window finishes loading and becomes visible, but the entire AppX container is destroyed approximately 30 seconds after it is created.
The previous app version worked on the same computer and network. There was no known change to the organization's network or security policy.
This is a silent exit rather than a conventional Windows application crash:
- No matching
Application ErrororWindows Error Reportingevent was recorded. - No crash dump was created in the standard per-user crash-dump location.
- No matching Code Integrity, AppLocker, or Microsoft Defender block was recorded at the exit time.
- The Codex desktop log ends abruptly after both windows report
ready-to-show; it contains no graceful shutdown, fatal error, renderer crash, TLS, certificate, proxy, or WebSocket failure immediately before termination.
What steps can reproduce the bug?
- Launch Codex from the Windows Start menu.
- Wait for the main window to finish loading.
- Do not invoke Browser Use or open an in-app browser page.
- Wait approximately 10–30 seconds.
- The window disappears and all
ChatGPT.exeprocesses exit.
This has occurred repeatedly. One captured reproduction is documented below.
What is the expected behavior?
The desktop app should remain open after the main window finishes loading. If a startup component fails, the app should show a recoverable error and preserve the main window instead of silently terminating the entire AppX container.
Additional information
The app successfully initializes its local app server, reads the authenticated account, mounts the renderer routes, and reports the main window as ready. A few seconds later, the desktop log stops without a shutdown message and Windows destroys the complete AppX container.
Captured timeline
Local timezone: Asia/Seoul (UTC+09:00)
15:20:26 AppModel-Runtime Event 210:
Desktop AppX container created for
OpenAI.Codex_26.721.4979.0_x64__2p2nqsd0c76g0
15:20:26 AppModel-Runtime Events 201/211:
Main app process created and added to the container
15:20:47 Desktop log:
AppServerConnection state changed to connected
15:20:51 Desktop log:
Main window finished load and became ready-to-show
15:20:52 Desktop log:
ChatGPT account lookup succeeded
15:20:55 Desktop log:
avatarOverlay window became ready-to-show
15:20:56 AppModel-Runtime Event 217:
Desktop AppX container destroyed
Time from AppX container creation to destruction: approximately 30 seconds.
Relevant sanitized desktop-log excerpts
warning Failed to load shell env caller=startup
detail="Timed out after 5000ms."
info [AppServerConnection] app_server_connection.state_changed
currentState=connecting next=connected transport=stdio
info [window-manager] window ready-to-show
appearance=primary rendererWindowVisible=true
info [chatgpt-account-lookup] completed
authenticatedAccountPresent=true authMethod=chatgpt result=succeeded
info [window-manager] window ready-to-show
appearance=avatarOverlay
The only application-level error near startup was a failed fs/readFile request for a missing path:
error [electron-message-handler] Request failed
method=fs/readFile
message="The system cannot find the path specified. (os error 3)"
The same missing-path error appeared for the primary and avatar-overlay renderers. The log then ended without a shutdown or crash record.
Controlled checks already performed
- Observed all
ChatGPT.exeprocesses disappear after launch. - Monitored for an additional 20 seconds after termination; process count remained zero.
- Checked the Windows Application event log for the preceding three days; no matching application crash or WER event was present.
- Checked
Microsoft-Windows-AppModel-Runtime/Adminaround the reproduction time; Event 217 confirms container destruction. - Checked Code Integrity, AppLocker, and Microsoft Defender operational logs at the same time; no matching block event was present.
- Checked the standard user crash-dump directory; no relevant dump was found.
- No SSL/TLS inspection exception or network policy change was made during this reproduction.
Related issues
- Codex Desktop exits when the embedded browser GPU process crashes and unsigned SwiftShader fallback is blocked #35352 reports the same app package version exiting after an embedded-browser GPU crash and an unsigned SwiftShader fallback being blocked. This reproduction is different because no Browser Use action is required and there is no corresponding Code Integrity block.
- Codex Desktop Windows: repeated silent app/window closes and sidechat becomes non-interactive after running #23814 reports repeated silent Windows desktop closes on an older package, but not this deterministic startup-time AppX container destruction.
Privacy note
The full desktop log is not attached publicly because it contains local paths, conversation identifiers, task identifiers, and account/session metadata. Sanitized excerpts or additional diagnostic artifacts can be provided privately to OpenAI maintainers if requested.
Activity
github-actions commentedon Jul 27, 2026
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action
tailsetter-hash commentedon Aug 23, 2026
Same silent-exit class on Windows 11, with a full-initialization variant. Cross-referencing #22633 (identical outward symptom: no window, exit within seconds) though my failure point is much later — my logs are rich where that reporter's are empty. Unlike this issue, my window is created but never becomes visible.
Environment
OpenAI.Codexfrom MS Store (9PLM9XGG6VKS); also testedOpenAI.CodexBetaSymptom
5–6 processes spawn, run a few seconds, exit silently. No crash dialog, no Application Error event, no WER dump — a clean exit, not a fault. The main window is created at correct dimensions (verified via Win32
EnumWindows: rect 21,21,943,491) but never becomes visible (IsWindowVisible=false).Consistent stall point. Last line logged on every build, every run:
Backend spawns, app-server connects, pipe opens — then silence. With
--enable-logging --v=1it reachesAddKeepAlive(Default, kAppWindow)before exiting. No exception at any verbosity level.Survival time varies by build, suggesting a race rather than a hard incompatibility:
Relevant to #35352: the only configuration that survives indefinitely is
--disable-gpu --disable-gpu-compositing --disable-software-rasterizer, but the window stays invisible since nothing renders. With--disable-gpualone (SwiftShader active) it dies at ~8s. Howevervk_swiftshader.dllis properly signed on this build (CN="OpenAI OpCo, LLC", Authenticode Valid) and there are zero CodeIntegrity events, so the unsigned-DLL cause from #35352 does not apply here.Relevant to #33762: the stall point is the browser-use pipe. Setting
[plugins."browser@openai-bundled"] enabled = falsein~/.codex/config.tomldid not help (died at 9s).Ruled out by direct test: clean uninstall/reinstall;
Reset-AppxPackage; AppX re-register; complete purge of both packages plus all data directories (LocalAppData\Packages\OpenAI.*,~/.codex,AppData\Roaming\Codex) followed by a fresh Store install; GPU driver update 31.0.101.4255 → 32.0.101.7088 with reboot and GPU/shader caches cleared; Defender (zero detections/blocks); no third-party AV; no proxy/VPN/secure DNS; identical ACLs onChatGPT.exeandresources\codex.exe; stubbing@worklouder/device-kit-oaiviaNODE_OPTIONS --require(shim verified loaded, no change).Possibly useful: I had
OpenAI.CodexandOpenAI.CodexBetainstalled concurrently, sharing one~/.codex. Removing the Beta roughly doubled survival time on the identical stable build (5–9s → 15–18s). Concurrent installs appear to worsen the race but do not cause it, since a clean single-package install still fails.Question for maintainers: what runs immediately after
dynamic_app_tools_listening? That is where every build goes silent on this machine, and with no crash dump there is nothing further to analyze externally.chandraxdev commentedon Sep 16, 2026
I faced similar issue and could find the root cause to be the Chrome policy DynamicCodeSettings=1 in my case and after changing to zero everything worked perfectly. Seems the bundled chrome.dll in the application is crashing without much information due to some policy voilation. May be a different case for you but some policy flag related to chrom which we might have enabled for privacy/security could cause this crash.
jceralde commentedon Oct 8, 2026
I can reproduce the same silent Windows desktop exit approximately 30 seconds after launch on a newer Microsoft Store build.
Environment
OpenAI.Codex_26.1002.7124.0_x64__2p2nqsd0c76g0Get-AppxPackagestatus:OkObserved behavior
Windows event evidence (2026-10-08, local clock UTC+08:00)
TWinUI/Operational event 1621 reports activation attempted, result 0 (success). No relevant
Applicationlog IDs 1000/1001/1002 were found when filtering forChatGPT|OpenAI; broader WER coverage not established.Desktop logs (sanitized)
The app logs show:
chatgpt-account-lookup ... result=succeeded, authenticated account present.status=ready.Local Work executor connected to rendezvous.fs/readFile requires an environmentId.ignoring interface.defaultPrompt[0]: prompt must be at most 128 characters.Neither the internal request error nor the plugin warning has been established as the exit cause. A sampled latest main desktop log ends without a clear fatal error or shutdown reason, before the observed roughly 30-second termination.
Troubleshooting attempted without resolution
I had cleared ordinary
%temp%files previously, but this has not been established as related. The issue persists across a fresh installation and different Windows user accounts.Could maintainers investigate whether this is the same startup/shutdown lifecycle failure in build
26.1002.7124.0, or advise on a safe way to capture the actual termination reason? Raw logs are intentionally not attached because they contain account/session identifiers and local file paths.