[Windows Desktop 26.721.4979.0] Opening existing conversations crashes Chromium GPU process
What version of the Codex App are you using?
26.721.4979.0 x64 (Microsoft Store / MSIX)
- Package:
OpenAI.Codex_26.721.4979.0_x64__2p2nqsd0c76g0 - Bundled Chromium:
150.0.7871.128
What platform is your computer?
Windows 11 x64, OS build 26200.
The system uses a current WHQL NVIDIA RTX 50-series desktop GPU driver. No per-application GPU preference is configured.
What issue are you seeing?
Opening some existing conversations from the sidebar consistently terminates the desktop app, while newly created/current-day conversations remain usable.
The conversation data request itself succeeds. Approximately two seconds later, the embedded Chromium GPU child crashes and its replacement cannot launch. After the abnormal exit, the next app launch can show a Microsoft Store guidance message instead of a usable app window.
This is not a package-registration failure:
- The AppX/MSIX package reports
Status: Ok. - No corresponding Windows Application Error / WER crash report was created.
- No display-driver reset event was observed in the Windows System log.
- The app's own Crashpad reports directory was empty at inspection time.
Steps to reproduce
- Start Codex Desktop.
- Confirm that a newly created conversation is usable.
- From the sidebar, open a known older conversation that has previously triggered the problem.
- Wait about two seconds after the thread content begins to load.
Expected behavior
Existing conversations should open normally. If a Chromium GPU child cannot start or crashes, the desktop UI should fall back safely rather than terminate the whole AppX application or make the following startup unusable.
Actual behavior
The app exits. A subsequent launch may show a Microsoft Store message asking the user to check the Store for more information.
Redacted log sequence
All conversation IDs, account information, paths, browser URLs, and message content have been omitted.
info response_routed method=thread/read ... success
info response_routed method=thread/turns/list ... success
[~1.9 seconds later]
warning Recoverable Chromium child process gone
exitCode=101457950
processType=GPU
reason=crashed
serviceName=GPU
warning Recoverable Chromium child process gone
exitCode=18
processType=GPU
reason=launch-failed
serviceName=GPU
The same GPU crash / failed-relaunch signature appeared in multiple separate app sessions, not only in one conversation.
Scope and notes
- This report does not claim that the old conversation content is corrupt. The thread read/list requests succeed; the failure happens afterward in the desktop rendering/GPU path.
- A normal current/new conversation does not trigger the crash on this installation.
- The exact individual message, attachment, or UI component that exercises the failing GPU path is not yet identified.
- A local test launcher that starts the app with Chromium
--disable-gpuis being used to distinguish a GPU-path failure from a conversation-specific renderer failure; its result is not included here yet.
Related reports
This may be the same Windows desktop GPU-child failure family as:
- #35440 — GPU crash and failed relaunch in the current app version, including recurrence when reopening an older task
- #34133 — GPU crash / failed relaunch with the same child-process exit codes
- #32094 — GPU child crash can terminate the desktop AppX container
This report differs in the trigger: opening an existing conversation rather than navigating a specific in-app browser page.
2 Comments
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action
Closing this report as a duplicate after further investigation.
The apparent "older conversation" trigger was a persisted in-app-browser tab associated with that thread, not the conversation content itself. Restoring that webview reproduced the same Code Integrity / unsigned SwiftShader GPU failure tracked in #35352. The persisted browser-tab restore/re-arm mechanism and targeted state-removal workaround are also already documented in #27828 and #32094.
The new reproduction and successful targeted recovery evidence has been added to #35352. No conversation IDs, URLs, account data, local paths, or message content were posted.