Codex app crashes when embedded browser opens WebCodecs/canvas-capable pages

This may be related.

I am seeing the Codex Windows app crash instantly whenever @Browser opens any URL, including https://example.com, not only local URLs or media/canvas-heavy pages.

Environment:

• Codex version: 26.707.31428
• Installed from Microsoft Store
• Windows 10 Pro 22H2, build 19045.6466
• WebView2 Runtime 150.0.4078.48

The crash started immediately after updating Codex. The app closes with no visible error dialog. It also happens with localhost, a Vite app, and a minimal Node HTTP server.

Thanks for the report! In Chrome can you go to chrome://gpu, save that page, and attach it here? I'm hoping it will have some clue about your graphics setup.

Additional Windows reproduction on a newer Codex Desktop build, with Code Integrity and AppX remediation evidence identifying the packaged SwiftShader DLL.

Environment:

• Codex Desktop/MSIX: OpenAI.Codex_26.715.2305.0_x64__2p2nqsd0c76g0
• Windows 11 Pro 25H2, build 26200.8037, x64
• Triggering surface: Codex in-app browser on a Perplexity page

Observed sequence (local time, not intentionally reproduced again because it made the app unlaunchable):

• 23:52:04.481 — in-app browser sidebar reached DOM ready.
• 23:52:06.399 — Code Integrity Event 3033: ChatGPT.exe attempted to load the packaged app\vk_swiftshader.dll, which “did not meet the Microsoft signing level requirements.”
• 23:52:06.523 — Chromium GPU child crashed with exitCode=101457950.
• 23:52:06.531 — GPU relaunch failed with exitCode=18.
• 23:52:06.527–23:52:06.548 — AppModel-Runtime Event 6 repeatedly refused package launches with 0x3CFC / ERROR_NEEDS_REMEDIATION.
• Microsoft Store remediation opened with appxState=2.
• 00:00:03 — after Store staging/repair, AppModel Event 68 changed package status from 0x2 to 0x0.
• 00:00:49 — the package launched successfully again.

Package evidence:

• app\vk_swiftshader.dll is present in the restored Store package.
• Get-AuthenticodeSignature reports NotSigned.
• SHA-256:

C5D063024A670677ED580B80EFA90ABBBF36A8F6FFF15F7C6B4A26C475F276BB

• After restoration, the DLL matched AppxBlockMap across all 83 blocks. This supports that it is part of the official Store payload rather than evidence of a user modification.
• The package folder itself was not removed; Store repair/restaging restored the existing package.

Expected:
A Chromium GPU fallback failure should remain isolated to the GPU child or browser surface. It must not move the whole MSIX package into Modified/ERROR_NEEDS_REMEDIATION or require Store reinstallation.

Actual:
Loading the packaged SwiftShader fallback was blocked by Code Integrity, followed immediately by the same GPU crash/relaunch codes reported here. The whole Codex package then became unlaunchable until Store repair/restaging.

Impact:
Complete Codex Desktop outage and interruption of active work. The UI message suggested checking the Store, and recovery required a full Store reinstall/restage.

Workaround:
Repair/reinstall through Microsoft Store restores the package temporarily. Avoiding in-app browser pages likely to trigger GPU/WebGL fallback may reduce risk, but no permanent safe workaround is confirmed.

This also matches #27828, including GPU exit codes 101457950/18 and AppX status recovery from 0x2 to 0x0.

Independent reproduction from Codex running inside the Microsoft Store ChatGPT/Codex Windows desktop app, not the Codex CLI.

Environment

• Windows 11 Pro, build 10.0.26200, x64
• Current Store package: OpenAI.Codex_26.721.4979.0_x64__2p2nqsd0c76g0
• ChatGPT Desktop package version also installed: 1.2026.190.0
• The packaged executable is app\ChatGPT.exe

User-visible behavior

Opening/using the built-in browser, including browser work around local development/localhost, can terminate the desktop app. Subsequent launches show the Windows message:

Check the Store for more info about ChatGPT.

Repair/reinstall through Microsoft Store restores the app temporarily.

Correlated evidence from three occurrences

The same sequence occurred at approximately:

• 2026-07-22 18:59:09 BST
• 2026-07-22 19:17:44 BST
• 2026-07-25 00:06:31 BST

For each occurrence:

1. Microsoft-Windows-CodeIntegrity/Operational Event 3033 reported that ChatGPT.exe attempted to load the packaged app\vk_swiftshader.dll, which did not meet the Microsoft signing level requirements.
2. The Codex application log recorded the Chromium GPU child exiting with exitCode=101457950, processType=GPU, reason=crashed.
3. Its replacement immediately failed with exitCode=18, reason=launch-failed.
4. AppModel-Runtime Event 217 destroyed the Desktop AppX container.
5. The package entered remediation state. Store repair/update later changed its status from 0x2 to 0x0, after which it launched again.

There were no corresponding Microsoft Defender detections or quarantine records.

Package and process-policy evidence

The current Store payload still contains:

app\vk_swiftshader.dll

• Get-AuthenticodeSignature: NotSigned
• SHA-256: 2C8F89FA26945207260B9B019F7E1A2F4F6820741B783561F729DC13C7E82C7E
• The DLL is listed in the package's AppxBlockMap.xml, supporting that it is part of the official Store payload rather than a local modification.

A live GetProcessMitigationPolicy(ProcessSignaturePolicy) probe shows:

• Main ChatGPT.exe: flags 0x0
• Chromium GPU child: flags 0x5 (MicrosoftSignedOnly=true, MitigationOptIn=true)
• Renderer children: flags 0x5

Windows reports UsermodeCodeIntegrityPolicyEnforcementStatus = 0, so this is not a separately enforced machine-wide UMCI/App Control policy. The Chromium child process is opting into the signing restriction, which then conflicts with the unsigned packaged SwiftShader DLL.

The Windows firewall permission prompt is sometimes visible around browser/local-server use, but the timestamp-correlated failure chain is Code Integrity -> SwiftShader load rejection -> GPU crash -> GPU relaunch failure -> AppX remediation.

Impact / requested fix

This makes the browser functionality capable of taking down the whole ChatGPT/Codex desktop package and leaving it unlaunchable until Store remediation. The package remains vulnerable after reinstall because the same unsigned DLL is restored.

Please either ship a signing-compatible SwiftShader component, configure Chromium so its packaged fallback can load under the selected process-signature policy, prevent this fallback path, or ensure the failure remains isolated to the GPU/browser surface without putting the entire MSIX package into remediation.

Reproduced on Codex Desktop 26.721.4979.0, Windows 11 23H2 build 22631, with RTX 3060 Laptop + AMD integrated graphics. Two findings add to the existing reports:

1. --disable-gpu is not a workaround. I launched the packaged AUMID with that switch through IApplicationActivationManager; the GPU child used d3d11-warp-webgl. When Codex restored a persisted https://dash.cloudflare.com/login tab, it reached dom-ready and four seconds later failed with the same sequence:

``text
processType=GPU reason=crashed exitCode=101457950
processType=GPU reason=launch-failed exitCode=18
``

A new Crashpad dump was created and the package returned to Modified, NeedsRemediation. WARP changes the initial backend but does not avoid the fatal GPU/fallback path.

1. Persisted tab state re-arms the crash. With Codex stopped, I removed the one thread-browser-tabs-v1:* record whose restoreUrl was dash.cloudflare.com, repaired the package, and reopened the same conversation on the normal hardware path. It remained open without restoring a browser webview or crashing. This contains the restore loop; opening Cloudflare in the in-app browser remains unsafe until the product bug is fixed.

Additional reproduction and post-crash impact from the current Windows Store build.

Environment

• Codex Desktop: OpenAI.Codex_26.721.4979.0_x64__2p2nqsd0c76g0
• Codex CLI/runtime: 0.146.0-alpha.3.1
• Platform: Windows x64
• Trigger: the embedded browser navigating to the Cloudflare dashboard/login flow

GPU crash

Immediately after the embedded browser opened the Cloudflare page, the Codex application log recorded:

Recoverable Chromium child process gone
exitCode=101457950 processType=GPU reason=crashed

Recoverable Chromium child process gone
exitCode=18 processType=GPU reason=launch-failed

This matches the GPU crash signature already reported here and in #27828.

Additional post-crash failure

The browser crash also left detached codex-command-runner process trees running. These processes retained a lock on the sandbox helper:

%USERPROFILE%\.codex\.sandbox-bin\codex-command-runner-0.146.0-alpha.3.1.exe

After restarting Codex, subsequent sandbox commands failed with:

CreateProcessWithLogonW failed: 5

Terminating only the verified orphaned codex-command-runner process trees released the executable lock and restored normal sandbox command execution. No application reinstall was required.

This may provide a concrete causal link to the Windows sandbox failure tracked in #9062: an embedded-browser GPU crash can prevent normal command-runner cleanup, leaving stale processes that break subsequent sandbox launches.

Workaround confirmed on this system

1. Fully exit Codex.
2. Terminate any verified orphaned codex-command-runner process trees.
3. Set in_app_browser = false in the Codex configuration.
4. Restart Codex and use the external Chrome integration instead.

After applying those steps:

• Sandbox command execution worked normally.
• The external Chrome integration connected successfully.
• No additional Chromium GPU crash was observed.

Requested resilience improvements

• Ensure browser/GPU failure triggers cleanup of command-runner child processes.
• Detect and recover from stale runner processes or locked sandbox helpers at startup.
• Keep an embedded-browser failure isolated from the command sandbox.
• Preserve the user’s disabled in-app-browser setting across restarts.

Raw logs are not attached because they contain local paths, task identifiers, and session data, but sanitized excerpts can be provided if needed.

I realized the crashes i experienced are probably not from the same source: One is from GPU which i can't reproduce on other devices. One is from File Access API which i can reproduce on every device

Additional Windows ARM64 reproduction of the same GPU crash.

Environment:

• Codex Store package: OpenAI.Codex_26.721.4979.0_arm64__2p2nqsd0c76g0
• Desktop runtime release reported in logs: 26.721.41059
• Windows 11 Home 10.0.26200
• Microsoft Surface Pro, 11th Edition (ARM64)
• Qualcomm Adreno X1-85 GPU, driver 31.0.137.0 (2026-01-08)

Reproduction:

1. Open a conversation that has a persisted in-app-browser tab in the right panel.
2. Codex restores the browser webview automatically.
3. The page reaches dom-ready.
4. About 226 ms later, the GPU process crashes; relaunch fails about 5 ms after that.
5. The whole Codex AppX container exits. On repeated occurrences, Windows changes the package status to Modified, NeedsRemediation, and subsequent launches show “Check the Store for more info about ChatGPT.”

Sanitized log sequence:

IAB_LIFECYCLE renderer created browser sidebar webview
IAB_LIFECYCLE runtime attached browser sidebar webview
browser sidebar dom-ready
Recoverable Chromium child process gone exitCode=101457950 processType=GPU reason=crashed serviceName=GPU
Recoverable Chromium child process gone exitCode=18 processType=GPU reason=launch-failed serviceName=GPU

Additional findings:

• The crash is reliably retriggered by opening a conversation whose browser tab is restored; no browser interaction is required.
• Setting only the affected persisted thread-browser-tabs-v1:* state to null allows Codex to start while preserving chats, projects, and authentication.
• Clearing the AppX Modified status through Windows.Management.Deployment.PackageManager.ClearPackageStatus returns the package to Ok without reinstalling or resetting user data.
• Microsoft Store reports no newer Codex package, and Windows Update reports no newer GPU driver.
• Launch tests with Chromium GPU disabled, ANGLE WARP (d3d11-warp-webgl), and WebGL/WebGPU disabled still reproduced the crash when the persisted in-app-browser webview was restored.

The full local logs and crash dump contain conversation identifiers/URLs and were intentionally not uploaded publicly. They can be supplied privately if requested.

Independent reproduction on a separate Windows x64 system, sanitized to omit usernames, hostnames, local paths, conversation IDs/titles, account information, private URLs, and network addresses.

Environment

• Windows 10.0.26200.0, x64
• Codex Desktop/MSIX: OpenAI.Codex_26.721.4979.0_x64
• Codex CLI: 0.146.0-alpha.3.1
• Browser plugin: 26.721.41059
• GPU: NVIDIA GeForce RTX 4070 Laptop GPU
• GPU driver: 32.0.15.6094

Reproduction evidence

This occurred three times in separate desktop sessions after the in-app browser loaded an account login page. Each occurrence followed the same sequence:

1. The browser sidebar reached dom-ready.
2. Windows Code Integrity Operational Event 3033 reported that ChatGPT.exe attempted to load the packaged app\vk_swiftshader.dll, which did not meet the Microsoft signing level requirements.
3. The Codex desktop log recorded the Chromium GPU child exiting with exitCode=101457950, processType=GPU, reason=crashed.
4. The replacement GPU child immediately failed with exitCode=18, reason=launch-failed.
5. AppModel-Runtime Event 217 destroyed the Desktop AppX container.
6. Relaunch could fail until Microsoft Store/AppX remediation completed.

The installed Store payload currently contains app\vk_swiftshader.dll with:

• File version: 5.0.0
• Authenticode status: NotSigned
• Size: 5,424,640 bytes

Get-AppxPackage OpenAI.Codex currently reports Status: Ok after remediation.

Persisted browser-tab re-trigger

The affected threads had entries under:

electron-persisted-atom-state.thread-browser-tabs-v1:<redacted>

The saved tab state contained a restoreUrl for the same login page. Restoring or continuing those threads recreated the embedded browser path and reproduced the failure. The affected threads were archived without reopening them.

A manual attempt to force BROWSER_USE_AVAILABLE_BACKENDS="chrome" was not durable: the bundled plugin configuration rewrote it to chrome,iab during the next desktop startup.

This independently matches the Code Integrity / SwiftShader failure described here and in #35352. No crash dumps are attached because they may contain private in-memory data. A product fix appears to require a signing-compatible SwiftShader fallback or containment of the GPU/browser failure so that it cannot terminate or remediate the entire MSIX package.

Independent reproduction on the Microsoft Store Windows desktop app. Please prioritize this: it repeatedly makes Codex unusable and forces the user through the same Store repair/update loop.

Package/build

• OpenAI.Codex 26.721.4979.0 (x64, Microsoft Store/MSIX)

Directly observed sequence

1. Before the failure, PowerShell reports:

``text
OpenAI.Codex 26.721.4979.0 Ok
``

1. Codex opens/uses its in-app web window.
2. The desktop app crashes.
3. Immediately afterward, the exact same command reports:

``text
OpenAI.Codex 26.721.4979.0 Modified, NeedsRemediation
``

1. Windows then says the app cannot be opened and Microsoft Store offers Update again.
2. Running that Store action temporarily restores the app, but the version remains 26.721.4979.0; after another in-app-browser-related crash, the package returns to Modified, NeedsRemediation and the loop repeats.

Earlier AppModel-Runtime evidence on the same machine included 0x3CFC, process termination during package failure, container destruction, and later automatic ACL/package-registration repair. There was no matching Windows resource-exhaustion event, so this is not explained by RAM pressure.

This appears to be more than an isolated GPU/browser child-process crash: the failure is contaminating the whole MSIX/AppX package state and making the installed app unlaunchable until Store remediation. Users should not need to redownload/re-register the same ~736 MB build every time the embedded browser fails.

Requested fix

• Keep browser/GPU/WebView failures isolated from the main desktop app and MSIX package state.
• Prevent a browser crash from transitioning the package from Ok to Modified, NeedsRemediation.
• Prevent startup/session restore from reopening a faulting web state and immediately repeating the loop.
• Make Store/self-update registration transactional or roll back cleanly instead of leaving the package requiring remediation.

The user can temporarily avoid Browser Use and work through CLI tools, but that is only a workaround; the desktop app needs a product-level fix.

Independent reproduction on the current Microsoft Store Windows x64 build. This appears to be the same tracked GPU-process failure, and it is not limited to media/WebCodecs pages.

Environment

• Codex Desktop runtime: 26.721.41059
• Microsoft Store/MSIX package: OpenAI.Codex_26.721.4979.0_x64
• Windows 11 Home: 10.0.26200.0, x64
• NVIDIA GeForce RTX 4080 SUPER, driver 32.0.15.9595
• Meta Virtual Monitor, driver 11.1.45.729
• GameViewer Virtual Display Adapter, driver 15.6.5.199

Reproduction

1. Start or continue a Codex task that invokes the built-in Browser / Browser Use right-panel webview.
2. Navigate the embedded browser to an ACM Digital Library page under https://dl.acm.org/.
3. The page reaches dom-ready.
4. The Chromium GPU child crashes, its replacement fails to launch, and the active task or the entire desktop app is interrupted/terminated.

Three separate ACM page loads reproduced the failure after approximately 0.761 s, 0.843 s, and 5.527 s from dom-ready. An about:blank webview could remain alive before navigation, which points to active page rendering/use rather than merely creating the sidebar.

Sanitized recurring log sequence:

browser sidebar dom-ready
Recoverable Chromium child process gone exitCode=101457950 name=null processType=GPU reason=crashed serviceName=GPU
Recoverable Chromium child process gone exitCode=18 name=null processType=GPU reason=launch-failed serviceName=GPU

On some occurrences, the Store package then changed from Ok to Modified, NeedsRemediation. Microsoft Store/winget repair restored launchability temporarily without changing the installed package version, but invoking the embedded browser could trigger the same failure again.

Troubleshooting already attempted

• Backed up and rebuilt all Codex GPU, shader, Dawn, and per-browser-partition caches.
• Performed a clean Microsoft Store reinstall and repeated package repair.
• Tested with hardware acceleration disabled / ANGLE WARP; the GPU process still crashed.
• Tested with hardware acceleration enabled and Windows high-performance GPU preference forced to the RTX 4080 SUPER; Browser Use still failed.
• Removed/restored browser-tab state to prevent immediate re-trigger on startup.

None of these produced a durable fix. Cache rebuilding or package repair can recover the app, but does not remove the underlying trigger.

Expected behavior

A page-rendering or GPU fallback failure should be isolated to the browser surface and return a recoverable Browser Use error. It should not terminate the Codex task/app or place the MSIX package into NeedsRemediation.

Raw logs and crash dumps are not attached publicly because they may contain task identifiers, local paths, and session data. Sanitized excerpts or private diagnostics can be provided if requested.

Independent reproduction on the current Microsoft Store Windows x64 build. Sanitized to omit usernames, local user paths, conversation/task identifiers, visited URLs, and business data.

Environment

• Windows 25H2 build 26200.8875, x64
• Codex Desktop/MSIX: OpenAI.Codex_26.721.4979.0_x64
• Codex CLI/runtime: 0.146.0-alpha.3.1
• Browser plugin/runtime: 26.721.41059
• NVIDIA GeForce RTX 5090, driver 32.0.16.1062
• AMD Radeon Graphics, driver 32.0.21043.5001

Trigger and observed sequence

A scheduled workflow was using the embedded Browser extensively. It reached 34 Browser Use tabs, closed 33 of them rapidly, then opened 10 additional tabs within approximately 12 seconds.

At 2026-07-26 18:36:07 local time, Windows Code Integrity Event 3033 reported that packaged ChatGPT.exe attempted to load packaged app\vk_swiftshader.dll, which did not meet the Microsoft signing level requirements.

The Codex desktop log then recorded:

2026-07-26T16:36:08.226Z
Recoverable Chromium child process gone
exitCode=101457950 processType=GPU reason=crashed serviceName=GPU

2026-07-26T16:36:08.236Z
Recoverable Chromium child process gone
exitCode=18 processType=GPU reason=launch-failed serviceName=GPU

At 18:36:09, AppModel-Runtime Event 217 destroyed the Codex Desktop AppX container. Ten AppModel-Runtime Event 6 entries with 0x3CFC were also recorded during the failed process relaunch attempts.

Recurrence and recovery

• The same GPU crash and relaunch-failure signature occurred three times on July 23 with package 26.715.10079.0, sometimes after opening only one embedded-browser tab.
• The July 26 occurrence happened on 26.721.4979.0, so the issue persists across these builds.
• No Windows resource-exhaustion event, system display-driver reset, or WER dump was recorded for this occurrence.
• Windows later repaired the package ACLs and re-registered/restaged the same package version. Get-AppxPackage now reports Status: Ok, but no newer version was installed.

The high browser-tab churn appears to amplify the trigger, but it is not required because earlier occurrences happened with a single tab. The browser/GPU failure should remain isolated instead of terminating the active workflow and putting the MSIX package into remediation.

Raw logs are intentionally not attached because they contain local paths, task identifiers, and visited URLs. Sanitized excerpts can be provided if requested.

Independent reproduction on Windows x64 with Microsoft Store package OpenAI.Codex_26.721.4979.0_x64.

User-visible sequence:

• A task with persisted in-app-browser tabs, including https://dash.cloudflare.com/login, was reopened.
• About 8 seconds after the tabs reached dom-ready, the desktop app exited.
• Subsequent launches showed “Check the Store for more info about ChatGPT” and failed until Microsoft Store Restore/repair re-staged the same package version.
• This reproduced three times on the same day.

Correlated local evidence from the latest occurrence:

• Code Integrity Event 3033: packaged ChatGPT.exe attempted to load packaged app\vk_swiftshader.dll, which did not meet Microsoft signing-level requirements.
• 272 ms later: GPU child exitCode=101457950, reason=crashed.
• 10 ms later: replacement GPU child exitCode=18, reason=launch-failed.
• 464 ms later: AppModel-Runtime Event 217 destroyed the AppX container.
• Get-AuthenticodeSignature reports the packaged vk_swiftshader.dll as NotSigned; SHA-256 2C8F89FA26945207260B9B019F7E1A2F4F6820741B783561F729DC13C7E82C7E.
• No matching display-driver reset or Defender detection was recorded.

Microsoft Store Restore returned the package to Ok but kept version 26.721.4979.0, so the remediation appears temporary. Reopening the task with the persisted browser state re-arms the crash.

Immediate containment: set in_app_browser = false and avoid reopening the affected task with the embedded browser enabled. Raw logs omitted because they contain task IDs and local paths.

Independent reproduction of the tracked BRWPLAT-293 failure on the current Microsoft Store Windows build. This also matches #27828 (Cloudflare Turnstile).

Environment

• Codex Desktop/MSIX: OpenAI.Codex_26.721.4979.0_x64
• Browser plugin/runtime: 26.721.41059
• Windows 11 Pro: 10.0.26200, x64
• AMD Radeon Graphics: driver 32.0.21043.19003
• NVIDIA GeForce RTX 5060: driver 32.0.16.1062

Impact across two consecutive tasks

Nine Codex AppX containers were terminated between 2026-07-26 19:05:42 and 19:23:37 local time (UTC-5) while resuming or using two browser-heavy tasks. The second task's active turn was persisted as interrupted at the exact termination time, with no model/tool error explaining the interruption.

Affected task IDs for maintainer correlation:

• 019fa083-748d-7d63-9acf-d909646e235e
• 019fa0ef-1c41-7c32-8c81-a829cec59329
• Interrupted turn: 019fa0f0-40ca-7e81-8f15-1935b965673e

Fresh isolated IAB reproduction

The second task created a fresh isolated in-app-browser tab and loaded a public /login page containing Cloudflare Turnstile:

2026-07-27T00:22:52.884Z browser sidebar dom-ready url=https://<redacted>/login
2026-07-27T00:22:54.848Z Recoverable Chromium child process gone exitCode=101457950 processType=GPU reason=crashed serviceName=GPU
2026-07-27T00:22:54.854Z Recoverable Chromium child process gone exitCode=18 processType=GPU reason=launch-failed serviceName=GPU

Correlated Windows events at the same instant:

19:22:54 Code Integrity 3033:
ChatGPT.exe attempted to load packaged app\vk_swiftshader.dll, which did not meet Microsoft signing-level requirements.

19:22:54 AppModel-Runtime 6:
0x3CFC / package machine-level status check failed.

19:22:55 AppModel-Runtime 217:
Destroyed the Codex Desktop AppX container.

19:23:24 AppModel-Runtime 68:
Package status recovered from 0x2 to 0x0.

The same Code Integrity -> GPU crash/relaunch failure -> AppX destruction cycle also occurred at approximately 19:05:42, 19:10:59, 19:13:12, 19:13:55, 19:14:50, 19:15:30, 19:16:24, and again at 19:23:37.

No matching Windows Application Error or WER event and no Crashpad report were created, so to the user the app simply disappears. The package currently reports Status: Ok after automatic remediation.

Expected: a GPU/SwiftShader failure in Browser Use must remain isolated and recoverable; it must not terminate the desktop app, interrupt the active task, or temporarily move the MSIX package to remediation state.

Independent reproduction matches this issue and BRWPLAT-293. I posted fuller sanitized evidence in #35352, including an additional clue: during the same period, ordinary Chrome also logged Code Integrity Event 3033 for its own vk_swiftshader.dll and vulkan-1.dll. Chrome remained usable, while the packaged ChatGPT/Codex app entered Modified, NeedsRemediation, suggesting the broader Chromium signing-policy conflict may be compounded by Codex’s MSIX failure-containment behavior.

Full report: https://github.com/openai/codex/issues/35352#issuecomment-5087106166

Independent reproduction from a human-clicked right-panel browser session on the current Microsoft Store build. This adds an important containment/configuration detail: browser@openai-bundled was already disabled, but the desktop's manual in-app Browser UI remained active and could still trigger the failure.

Environment

• Codex Desktop/MSIX: OpenAI.Codex_26.721.4979.0_x64
• Browser runtime: 26.721.41059
• Windows 11 x64, build 26200
• NVIDIA GeForce RTX 5070 Ti Laptop GPU

Three matching occurrences

The same failure fingerprint occurred three times:

• 2026-07-25 22:46:05 EDT
• 2026-07-25 23:51:44 EDT
• 2026-07-26 18:53:17 EDT

The latest occurrence was reproduced manually while signing into job-search sites:

18:53:10.533  LinkedIn feed loaded successfully
18:53:14.641  Human opened a new right-panel browser tab for Indeed
18:53:15.990  Indeed redirected to its bot-detection/login flow
18:53:17.171  Code Integrity Event 3033 blocked packaged app\vk_swiftshader.dll
18:53:17.381  GPU child crashed: exitCode=101457950 reason=crashed
18:53:17.387  Replacement GPU child failed: exitCode=18 reason=launch-failed
18:53:17.386–.395  Five AppModel Event 6 records returned 0x3CFC
18:53:17.760  AppModel Event 217 destroyed the Desktop AppX container

The Code Integrity event reported:

RequestedPolicy=8
ValidatedPolicy=1
Status=0xC0000428
PE Authenticode hash=860B71791A410D3BC0AC1B5E8927E539BF5BD372

The CI block preceded the logged GPU crash by approximately 210 ms.

Package verification and recovery

• Packaged vk_swiftshader.dll SHA-256:

2C8F89FA26945207260B9B019F7E1A2F4F6820741B783561F729DC13C7E82C7E

• Get-AuthenticodeSignature: NotSigned
• The restored DLL matched AppxBlockMap.xml across all 83/83 blocks.
• The live GPU child used MicrosoftSignedOnly=ON and AllowStoreSignedBinaries=OFF.
• No matching WHEA, display-driver reset, disk/NVMe, resource-exhaustion, BugCheck, Application Error, or WER event occurred in the crash window.

Microsoft Store Repair changed package state from 0x2 to 0x0, re-registered the same 26.721.4979.0 package, and restored launchability. It did not change the vulnerable binary or process policy, so opening the embedded browser reproduced the same failure again.

Configuration boundary / current containment

Disabling the bundled Browser plugin is not sufficient:

[plugins."browser@openai-bundled"]
enabled = false

With that setting already present, the human-facing right-panel Browser remained usable. The effective UI kill switch is:

[features]
in_app_browser = false

The current local containment also forces links to external-browser and limits available browser backends to chrome. Codex parses this configuration successfully and the external Chrome path remains enabled.

Requested product changes

1. Make the packaged SwiftShader/Vulkan path compatible with the GPU child's selected binary-signature mitigation, or avoid that fallback path.
2. Keep a GPU/browser failure isolated and recoverable; it must not put the entire MSIX package into Modified, NeedsRemediation.
3. Ensure disabling the Browser plugin cannot leave a still-active human-facing embedded Browser without a clear warning; expose the in_app_browser kill switch in the UI.
4. Add a Windows regression test for Cloudflare/bot-detection pages under Code Integrity.

Raw logs are intentionally not attached publicly because they contain local paths, task identifiers, and browser/session metadata. Sanitized event XML and targeted log excerpts can be supplied privately if requested.

Independent reproduction on the current Microsoft Store Windows build, with a persisted-tab trigger that does not involve Cloudflare.

Environment

• Windows 11 Home Single Language 10.0.26200, x64
• Codex Desktop/MSIX: OpenAI.Codex_26.721.4979.0_x64
• Hybrid graphics: Intel UHD Graphics + NVIDIA GeForce GTX 1650 Max-Q
• NVIDIA Studio driver was updated from a January 2022 build to 32.0.16.1074 (2026-07-02); the failure continued unchanged after the update and reboot.

Two consecutive reproductions

Local times (IST):

• 2026-07-27 22:16:52
• 2026-07-27 22:23:39

In both cases, Codex was restoring a browser-heavy task with persisted right-panel tabs. The restored pages included three Figma design canvases and a Vercel signup page. Immediately before the first crash, the Figma tabs reached dom-ready; the second crash occurred while the same browser webviews were being restored/backgrounded during thread/resume.

Both occurrences had the same correlated sequence:

Code Integrity Event 3033:
ChatGPT.exe attempted to load packaged app\vk_swiftshader.dll,
which did not meet Microsoft signing-level requirements.

Codex log:
processType=GPU reason=crashed exitCode=101457950
processType=GPU reason=launch-failed exitCode=18

AppModel-Runtime Event 6:
0x3CFC / ERROR_NEEDS_REMEDIATION

AppModel-Runtime Event 217:
Destroyed the Codex Desktop AppX container

Windows then changed package status from 0x2 back to 0x0 through Store staging/repair and re-registered the same package version. This made the automatic remediation look like another Codex update.

Package/policy evidence

• Packaged app\vk_swiftshader.dll SHA-256: 2C8F89FA26945207260B9B019F7E1A2F4F6820741B783561F729DC13C7E82C7E
• Get-AuthenticodeSignature: NotSigned
• Smart App Control (VerifiedAndReputablePolicyState) is off.
• UsermodeCodeIntegrityPolicyEnforcementStatus = 0.
• No corresponding display-driver reset, WHEA, Application Error, or WER event occurred.

The unchanged result after the NVIDIA driver update, plus the exact Event 3033 timing, supports the packaged SwiftShader/process-signature conflict rather than a display-driver fault.

Local containment applied

Added the supported feature override:

[features]
in_app_browser = false

The bundled CLI parses it as in_app_browser stable false; external browser support remains enabled. Persisted browser records were left intact rather than editing conversation/session history. This containment will be verified after the next desktop restart.

Additional reproduction: two crashes plus an AppX integrity finding

I reproduced this twice on the current Microsoft Store build.

Environment

• Codex/MSIX: OpenAI.Codex_26.721.4979.0_x64
• Browser runtime: 26.721.41059
• Windows 10 Home China 22H2, build 19045.6466
• NVIDIA GeForce GTX 1660 Ti
• Driver: 27.21.14.5749, dated 2020-11-20

The driver is old, but the exact Code Integrity and GPU exit fingerprint has also been reported here on newer drivers and different GPU vendors.

Two matching occurrences

Local time (UTC+08:00):

• 2026-07-28 08:42:10
• 2026-07-28 09:12:52

Both occurrences produced the same sequence:

1. Code Integrity Event 3033: ChatGPT.exe attempted to load packaged app\vk_swiftshader.dll, which did not meet Microsoft signing-level requirements.
2. The Codex log recorded the GPU child crashing with exitCode=101457950, followed by relaunch failure with exitCode=18.
3. AppModel-Runtime Event 6 returned 0x3CFC / ERROR_NEEDS_REMEDIATION.
4. Event 217 destroyed the Codex Desktop AppX container.

Additional AppX finding

After the first crash, repeated package-registration attempts failed. At 08:57:10, AppXDeploymentServer Event 8102 explicitly reported this packaged file as modified:

app\150.0.7871.128.manifest

The restored file is a Win32 assembly manifest for Chromium 150.0.7871.128 referencing chrome_elf.dll.

Related events reported:

• Event 8104: trust-label failure, 0x80073CFC
• Event 751: Windows could not undo the package changes and required reinstallation
• Registration failure: 0x80073CF6
• Underlying error: 0x800703EE

Microsoft Store restaged the same 26.721.4979.0 package. AppModel Event 68 changed its state from 0x2 to 0x0 at 09:00:29, and the app launched again at 09:00:35. The same failure then recurred about twelve minutes later. A second Store restage returned the package to 0x0, and it launched again at 09:16:20.

The current package status is Ok, but the version and vulnerable path are unchanged.

Causal boundary

These logs prove that the Code Integrity rejection, GPU failure, AppX destruction, package-remediation state, and later manifest-integrity finding occurred in the same incident chain. They do not prove that the browser process itself modified the manifest. A Store/update race or another packaging interaction may be involved, so the manifest finding should be investigated as a possibly coupled failure rather than assumed to be caused directly by SwiftShader.

One upstream candidate worth checking is Chromium commit:

https://chromium.googlesource.com/chromium/src/gpu/+/963206a961a7992b048d07f756f87f11fa2e5420

It prevents unconditional SwiftShader preload during GPU sandbox initialization when SwiftShader is not actually allowed or selected.

Requested regression coverage

Please test the real Store-signed Windows MSIX with Code Integrity enabled:

1. Repeatedly open a normal page through the actual in-app Browser and execute DOM snapshot plus screenshot operations.
2. Assert that no vk_swiftshader.dll Event 3033 occurs and the package remains Status: Ok.
3. Inject a GPU-child crash/relaunch failure and verify that it becomes a bounded Browser-tool error or automatic restart.
4. Verify that the main app, active task, and package remain usable.
5. Restart Codex and verify that persisted browser state cannot create a crash/recovery loop.

Sanitized Event XML and targeted log excerpts can be provided privately if useful.

Following up on @brettw-openai's request for a saved chrome://gpu report.

This report was captured in ordinary external Google Chrome on the same Windows machine that reproduced the Codex Desktop / Browser Use failure reported in #35352. No custom GPU flags were enabled.

Saved report

• Exported: 2026-07-29T06:18:10.851Z
• Saved HTML size: 83,622 bytes
• Saved HTML SHA-256: C6A14662619856C1C8F12D7D1B5AAB902CCE0B0731D754FF7709632CD8E9569D
• Chrome: 150.0.7871.187
• OS: Windows NT 10.0.19045.6456 (kernel32 10.0.19041.5915)
• ANGLE commit: edae461ad212
• Command line: standard Chrome executable with no GPU override flags

GPU / driver

• Active GPU: NVIDIA GeForce GTX 970
• Vendor/device: 0x10de / 0x13c2
• NVIDIA driver: 32.0.15.6094
• Secondary adapter: Microsoft Basic Render Driver, 10.0.19041.5794
• GPU sandboxed: true
• In-process GPU: false
• GL implementation: (gl=egl-angle, angle=d3d11)
• Display type: ANGLE_D3D11
• Renderer: ANGLE (NVIDIA GeForce GTX 970, Direct3D11, D3D11-32.0.15.6094)
• D3D feature level: 12.1
• Vulkan API: 1.3.0
• Direct composition: true
• GPU process crash count in ordinary Chrome: 0

Graphics feature status

Canvas: Hardware accelerated
Compositing: Hardware accelerated
Rasterization: Hardware accelerated
Video Decode: Hardware accelerated
Video Encode: Hardware accelerated
WebGL: Hardware accelerated
WebGPU: Hardware accelerated
OpenGL: Enabled
Multiple Raster Threads: Enabled
Direct Rendering Display Compositor: Disabled
Raw Draw: Disabled
Skia Graphite: Disabled
TreesInViz: Disabled
WebNN: Disabled

Driver workarounds reported by Chrome

disable_d3d11_vp9_ksvc_decoding
disable_d3d12_av1_encoding
disable_d3d12_h264_encoding
disable_d3d12_video_encoder
disable_dcomp_texture
enable_webgl_timer_query_extensions
exit_on_context_lost
unpack_overlapping_rows_separately_unpack_buffer
disabled_extension_GL_KHR_blend_equation_advanced
disabled_extension_GL_KHR_blend_equation_advanced_coherent

The particularly relevant Problems Detected entry is:

Some drivers are unable to reset the D3D device in the GPU process sandbox. Applied workaround: exit_on_context_lost.

Chrome also reports the discrete NVIDIA D3D12 and D3D11 WebGPU adapters as available. The Microsoft Basic Render Driver CPU adapter is blocklisted as expected.

Relevant Chrome GPU log tail

GpuProcessHost: The info collection GPU process exited normally. Everything is okay.
ANGLE shader compiler performance warnings.
EGL Driver message: eglCreateContext: Requested version is not supported.
GpuProcessHost: The info collection GPU process exited normally. Everything is okay.

This external-Chrome report is important because ordinary Chrome is hardware-accelerated and stable on the same machine, while the packaged Codex Browser Use path reaches Code Integrity Event 3033 for vk_swiftshader.dll, GPU exit 101457950, replacement launch failure 18, and AppX remediation. That continues to point to the Codex MSIX GPU/signing or failure-containment boundary rather than a generally nonfunctional GPU configuration.

The full saved HTML report is available if maintainers provide an attachment/private-upload path.