[Windows Desktop 26.721.4979.0] Opening existing conversations crashes Chromium GPU process

Resolved 💬 2 comments Opened Jul 26, 2026 by jundev0001 Closed Jul 26, 2026
💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

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

  1. Start Codex Desktop.
  2. Confirm that a newly created conversation is usable.
  3. From the sidebar, open a known older conversation that has previously triggered the problem.
  4. 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-gpu is 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.

View original on GitHub ↗

2 Comments

github-actions[bot] contributor · 1 month ago

Potential duplicates detected. Please review them and close your issue if it is a duplicate.

  • #35440
  • #35352

Powered by Codex Action

jundev0001 · 1 month ago

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.