Codex Desktop exits when the embedded browser GPU process crashes and unsigned SwiftShader fallback is blocked

Resolved 💬 18 comments Opened Jul 25, 2026 by Sunchensw Closed Aug 6, 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 (From “About Codex” dialog)?

latest

What subscription do you have?

pro

What platform is your computer?

windows

What issue are you seeing?

Codex Desktop exits while using the embedded browser on Windows. The page loads successfully, but the Chromium GPU subprocess crashes shortly afterward. Chromium then attempts to use vk_swiftshader.dll as a software-rendering fallback, but Windows Code Integrity blocks the DLL because it does not meet the required Microsoft signing level.
The GPU subprocess fails to restart, and the entire Codex Desktop application exits instead of recovering or reporting a browser tool error.
Environment
Codex Desktop package: 26.721.4979.0
Codex CLI: 0.146.0-alpha.3.1
Browser plugin: 26.721.41059
OS: Windows 11, build 26200.8875
GPU: Intel(R) Arc(TM) Graphics
GPU driver: 32.0.101.8243
Driver date: 2025-10-13
vk_swiftshader.dll version: 5.0.0
vk_swiftshader.dll Authenticode status: NotSigned

What steps can reproduce the bug?

Open a new Codex Desktop thread.
Enable and use the embedded browser.
Run a browser operation similar to:
var tab = await browser.tabs.new();

await tab.goto(
"https://www.bing.com/search?q=site%3Adocs.ozon.ru+image+requirements"
);

var snapshot = await tab.playwright.domSnapshot();

nodeRepl.write(snapshot.slice(0, 22000));
Wait for the page to finish rendering.

What is the expected behavior?

Expected Behavior
The page loads and the DOM snapshot is returned.
If the GPU subprocess crashes, Codex restarts it or switches to software rendering.
If recovery is impossible, the browser tool returns an error without terminating Codex Desktop.

Additional information

_No response_

View original on GitHub ↗

18 Comments

github-actions[bot] contributor · 1 month ago

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

  • #34133
  • #35311

Powered by Codex Action

bdc8rkn66k-art · 1 month ago

Confirmed on a separate Windows x64 system with a different GPU.

  • Codex desktop: 26.721.4979.0 (Microsoft Store, x64)
  • Windows 11 25H2, build 26200
  • GPU: NVIDIA GeForce RTX 4060 Ti, driver 32.0.15.9649
  • Reproduces in multiple separate chats when the built-in browser is used.

Windows Code Integrity Event ID 3033 is logged immediately before the exit:

…\app\vk_swiftshader.dll … did not meet the Microsoft signing level requirements.

EventData: RequestedPolicy=8, ValidatedPolicy=1, Status=0xC0000428.

There are no Microsoft Defender threat detections. After the block, Microsoft Store/AppX remediation starts re-registration with ForceTargetApplicationShutdownOption, which forcibly closes the app; no native crash dump or WER Application Error is produced.

This shows the issue is not specific to Intel graphics and can also cause a Store remediation loop after the browser-triggered exit.

jundev0001 · 1 month ago

Additional reproduction and recovery evidence from a separate Windows x64 installation of the current Microsoft Store build:

  • The apparent trigger was opening an older conversation, while newly created/current conversations remained usable.
  • Further inspection showed that conversation age/content was not the differentiator. The affected thread had a persisted in-app-browser record under electron-persisted-atom-state with a thread-browser-tabs-v1:<redacted> key.
  • Opening that thread restored and attached the browser sidebar webview. The same failure sequence followed: Code Integrity Event 3033 rejected app\vk_swiftshader.dll, the GPU child exited with 101457950, and its replacement failed with exit code 18. A later launch could show the Microsoft Store guidance message.
  • Clearing GPU/Dawn caches and launching with GPU/WebGL/WebGPU-disabling variants did not prevent recurrence when the persisted webview was restored.

A targeted recovery succeeded:

  1. Fully exit the desktop app.
  2. Back up .codex-global-state.json and its .bak file.
  3. Remove only the matching thread-browser-tabs-v1:<redacted> property from both files, preserving all conversation, authentication, project, and configuration data.
  4. Relaunch normally with hardware acceleration unchanged.

After this targeted removal, the previously affected conversation opened without terminating the app. This supports persisted browser-tab restoration as a trigger/re-arm mechanism for this Code Integrity/SwiftShader failure, rather than corruption in old conversation content.

Potential resilience improvements:

  • Quarantine or skip persisted browser-tab restoration after a prior GPU launch failure.
  • Allow the conversation to open without automatically recreating the failed webview.
  • Isolate GPU-child failure from the desktop container and surface a recoverable browser error.
  • Fix the packaged SwiftShader/signing-policy mismatch so the fallback can load under the app's effective mitigation policy.

No conversation IDs, URLs, account data, local paths, or message content are included here.

mmmd3d-source · 1 month ago

Independent reproduction on a Windows x64 installation of Codex Desktop 26.721.4979.0:

  • The app exited three times shortly after in-app Browser Use was invoked.
  • Each incident produced Windows Code Integrity Operational Event ID 3033: ChatGPT.exe attempted to load the packaged app\vk_swiftshader.dll, which did not meet the required Microsoft signing level.
  • In the observed sequence, the first Code Integrity event was followed approximately one second later by an AppModel/package block with 0x3CFC; the package then reported Modified, NeedsRemediation / PackageStatus=2.
  • A full validation against AppxBlockMap.xml checked 9,544 packaged files and all 38,017 non-empty content blocks. Every content-block hash matched. Eight initially reported entries were zero-byte files and were validator artifacts, not payload mismatches.
  • This indicates that the installed package payload remained byte-consistent with its block map even though Windows moved the package into remediation state immediately after the browser/GPU integrity failure.
  • Avoiding Browser Use has prevented further reproduction so far. No Code Integrity policy or packaged DLL was modified.

This independently supports the reported failure chain: Browser Use starts the GPU path, Code Integrity rejects the packaged SwiftShader fallback, and the desktop app/package enters an unrecoverable or remediation state instead of isolating the browser/GPU failure. A compatible signed fallback, or graceful containment of the GPU subprocess failure, appears necessary.

RobiLiam · 1 month ago

Independent reproduction in the Codex Windows desktop app (Microsoft Store package)not ChatGPT/Codex running in a web browser.

The same defect occurred twice, at approximately 22:54 and 23:22, while Codex's embedded browser was working on the same task and loading a Kent Archives page.

Observed sequence on both occasions:

  • Windows Code Integrity rejected the packaged app\vk_swiftshader.dll because it did not meet Microsoft signing requirements.
  • Chromium's GPU process exited.
  • The replacement GPU process could not start.
  • Windows returned 0x80073CFC and moved the app package to NeedsRemediation.
  • Launching Codex then produced the Windows “This app can’t open — check the Windows Store” message and redirected to Store repair/update.

Environment/evidence:

  • Codex desktop app: 26.721.4979.0
  • vk_swiftshader.dll: version 5.0.0
  • Authenticode status: NotSigned
  • The DLL hash matches the signed MSIX block map, indicating that it was shipped in this state rather than corrupted locally.
  • No Microsoft Defender detection, custom Code Integrity policy, disk error, or display-driver reset was recorded.
  • Windows logged automatic package-registration repair attempts around 23:06 and 23:10, followed by complete approximately 742.7 MB package restages around 23:16 and 23:30.

Repair/update temporarily restored the desktop app, but did not change the unsigned DLL. Returning to the same embedded-browser task reproduced the failure. The package currently reports Status: Ok, but the DLL remains unsigned, so the defect remains reproducible.

The Kent Archives site is not indicated to be malicious; it appears only to have triggered the affected embedded Chromium rendering/fallback path. Avoiding the in-app Browser and using an external browser is the current workaround.

ywkuno · 1 month ago

Confirmed independently on a second Windows/NVIDIA environment with the same package set.

Environment:

  • Codex Desktop 26.721.4979.0
  • Codex CLI/app-server 0.146.0-alpha.3.1
  • Browser plugin 26.721.41059
  • Windows 11 Pro x64, build 26200
  • NVIDIA GeForce RTX 5070 Ti, driver 32.0.16.1062

Reproduction timeline:

  • An in-app browser page reached DOM ready.
  • Five seconds later, the GPU child exited with 101457950 (0x060C201E), reason crashed.
  • The replacement GPU process immediately exited with code 18, reason launch-failed.
  • Windows Code Integrity event 3033 occurred at that exact timestamp and reported that ChatGPT.exe attempted to load the packaged vk_swiftshader.dll, but the DLL did not meet Microsoft signing-level requirements.

Package inspection:

  • vk_swiftshader.dll file version: 5.0.0
  • Authenticode status: NotSigned

The failure repeated at three separate timestamps, including twice after Microsoft Store Restore. Restore rehydrated the retained browser tab, so the same GPU crash and Code Integrity rejection recurred and created a launch/restore loop.

This broadens the report beyond Intel Arc: the same blocked SwiftShader fallback occurs with NVIDIA hardware. Suggested durable fix boundaries:

  1. Ship a fallback DLL that satisfies the Store app's Microsoft signing-level policy, or use another permitted software renderer.
  2. Convert GPU child launch-failed into a recoverable Browser Use error instead of terminating the desktop shell.
  3. Quarantine or discard restored browser state after repeated GPU startup failure to prevent task-resume crash loops.
  4. Add a packaged-Windows validation that checks the fallback DLL signature and exercises GPU-process recovery.
ja7226 · 1 month ago

Independent reproduction with one additional diagnostic clue that may help separate an OpenAI-only packaging defect from a broader Windows 25H2/Chromium signing-policy interaction.

Environment:

  • Windows 11 Pro 25H2, build 26200.8894, x64
  • ChatGPT/Codex Microsoft Store package 26.721.4979.0
  • Package family OpenAI.Codex_2p2nqsd0c76g0
  • Microsoft Store, Store Purchase App, and Desktop App Installer packages all reported Status: Ok
  • No Code Integrity or Windows security policy was weakened

Observed ChatGPT/Codex sequence:

  • In-app Browser use was followed by repeated Windows Code Integrity Operational Event ID 3033 entries.
  • ChatGPT.exe attempted to load packaged app\vk_swiftshader.dll, and Windows reported that it did not meet the required Microsoft signing level.
  • The package later reported Modified, NeedsRemediation and became unlaunchable until Store repair/re-registration.
  • Repair/re-registration and a full Store reinstall could complete successfully, but the package later returned to the same remediation state.
  • Store/update history also contained repeated 0x80073D02 failures, consistent with update attempts while package files were in use.

Packaged binary evidence:

  • vk_swiftshader.dll Authenticode status: NotSigned
  • SHA-256: 2C8F89FA26945207260B9B019F7E1A2F4F6820741B783561F729DC13C7E82C7E
  • vulkan-1.dll Authenticode status: NotSigned
  • SHA-256: 30A4CE82D62409DE94D49AC57CA5AAD8CE38DA8898EFC49591CFDDEF567CFA95

Additional clue:

During the same period, Windows logged many separate Code Integrity Event 3033 entries for ordinary system Chrome 150.0.7871.187. chrome.exe was also blocked from loading its own vk_swiftshader.dll and vulkan-1.dll because they did not meet the Microsoft signing-level requirement.

Chrome itself remained usable, whereas the packaged ChatGPT/Codex app entered remediation. This suggests the underlying signing-policy conflict may affect Chromium software-Vulkan fallback more broadly on this Windows build, while the Codex desktop app has the more severe failure-containment/package-state problem.

I am not claiming the Chrome events prove a single root cause. They may be useful when testing whether the durable fix belongs in the packaged SwiftShader payload, Chromium launch/mitigation configuration, GPU-process recovery, or the MSIX remediation/update path.

No account identifiers, conversation data, repository names, local user paths, SIDs, or raw application state are included.

lyrabird · 1 month ago

Independent confirmation from another Windows x64 / NVIDIA system, with a reproducible two-incident timeline and an additional process-mitigation clue.

Environment:

  • Windows 11 Pro 25H2, build 26200.8894, x64
  • Codex Desktop Microsoft Store package 26.721.4979.0
  • Package family OpenAI.Codex_2p2nqsd0c76g0
  • NVIDIA GeForce RTX 5090 D, driver 32.0.15.9186
  • vk_swiftshader.dll version 5.0.0

Two incidents occurred while the in-app Browser restored/navigated the same publisher webpage:

  1. 17:23:06 local time
  2. 17:56:23 local time, after the package had been reinstalled

At both timestamps, Windows Code Integrity Operational Event ID 3033 reported that ChatGPT.exe attempted to load the packaged app\vk_swiftshader.dll, but it did not meet the Microsoft signing-level requirement.

Event data on both occurrences:

  • RequestedPolicy=8
  • ValidatedPolicy=1
  • Status=0xC0000428

The Codex desktop log then recorded, at the matching timestamp:

  • GPU child exit 101457950 (0x060C201E), reason crashed
  • replacement GPU child exit 18, reason launch-failed

Package/binary checks:

  • vk_swiftshader.dll Authenticode status: NotSigned
  • SHA-256: 2C8F89FA26945207260B9B019F7E1A2F4F6820741B783561F729DC13C7E82C7E
  • The running ChatGPT.exe process mitigation reports MicrosoftSignedOnly: ON and AllowStoreSignedBinaries: OFF
  • Windows Smart App Control is Off
  • No Microsoft Defender detection or system display-driver reset was recorded

After each incident, the app became unlaunchable and Windows displayed the “This app can’t open / check Microsoft Store” guidance. Re-register/repair operations and a full MSIX restage temporarily restored startup, but the second incident reproduced when the same in-app Browser task was resumed. The package currently reports Status: Ok after reinstall, while the bundled DLL remains unsigned.

Fresh/current tasks that do not restore or use the affected in-app Browser state remain stable. This further supports both:

  1. a packaged SwiftShader/signing-policy incompatibility, and
  2. persisted browser-tab restoration as a mechanism that can re-arm the crash loop.

A durable fix likely needs a fallback binary compatible with the effective signature policy, graceful containment of GPU-child launch failure, and suppression/quarantine of persisted Browser state after repeated GPU startup failure.

No account identifiers, conversation/task IDs, local paths, webpage URLs, or workspace content are included.

EidzokuxS · 1 month ago

Independent local reproduction with corrected root-cause evidence.

I reproduced the same failure on unrelated webpages in Codex Desktop 26.721.4979.0 on Windows. Two earlier incidents involved Cloudflare challenge URLs containing __cf_chl_rt_tk, almost exactly 1 hour apart. A later incident reproduced the exact same failure on perplexity.ai with no Cloudflare challenge involved.

On the Perplexity reproduction, the page reached DOM-ready. About 1.5 seconds later, the desktop log recorded:

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

The immediate GPU restart then failed:

processType=GPU reason=launch-failed exitCode=18

Local Windows Code Integrity Event ID 3033 separately confirms that ChatGPT.exe attempted to load the bundled app\vk_swiftshader.dll, but Windows blocked it because the DLL did not meet Microsoft signing-level requirements.

The confirmed local failure chain is therefore:

webpage loadsChromium GPU process crashesbundled SwiftShader fallback is rejected by Windows Code IntegrityGPU relaunch failscomplete Codex exit

Cloudflare and __cf_chl_rt_tk were observed triggers in the first two incidents, not the root cause.

After the crash, Codex became unlaunchable and Windows redirected me to the Microsoft Store. I later initiated a roughly 700 MB Repair manually, so the Repair was a consequence of the crash, not its trigger.

The Perplexity trigger is also independently mentioned in #34311. Possibly related: #34311 and #35290.

LianKaFoHaLi · 1 month ago

I can confirm the same failure on another Windows/NVIDIA system.

Environment

  • Codex App: 26.721.4979.0
  • Package: OpenAI.Codex_26.721.4979.0_x64__2p2nqsd0c76g0
  • Platform: Microsoft Windows NT 10.0.26200.0 x64
  • GPU: NVIDIA GeForce RTX 4070 Ti
  • GPU driver: 32.0.15.9186

Reproduction

Two existing conversations reproducibly crash Codex when opened. Both conversations restore an in-app Browser/WebView state.

Representative sanitized Codex log:

maybe_resume_success conversationId=<session-id>
browser sidebar dom-ready url=https://<redacted-site>/login
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

At the exact crash timestamps, Windows Code Integrity recorded Event ID 3033:

ChatGPT.exe attempted to load vk_swiftshader.dll that did not meet the Microsoft signing level requirements.

This occurred repeatedly at the same timestamps as the GPU crash and GPU restart failure.

Additional observations

  • One affected rollout is 1,270,902,716 bytes and contains 3,528 input_image objects and 3,848 inline data:image payloads.
  • The second affected rollout is only 10,263,494 bytes. Oversized conversation history therefore appears to be an aggravating factor, but it is not required to trigger the GPU/SwiftShader failure.
  • No matching Windows Display driver reset, WHEA, or resource-exhaustion event was recorded.
  • Reinstalling the Microsoft Store package does not resolve the issue because reopening the same conversation restores the faulting Browser/WebView state.
  • The affected session IDs and additional sanitized excerpts can be provided privately if needed.

The expected behavior is for a failed GPU process or embedded Browser/WebView to be isolated and recovered, rather than terminating Codex and leaving the AppX package in a state that requires repair or reinstallation.

kinglbworld · 1 month ago

Independent recurrence with a precise package-state/repair timeline from another Windows x64 installation.

Environment

  • Codex/ChatGPT Desktop package: OpenAI.Codex_26.721.4979.0_x64__2p2nqsd0c76g0
  • Windows 11 Pro x64: 10.0.26200 (build 26200)
  • Bundled vk_swiftshader.dll: version 5.0.0, Authenticode status NotSigned
  • Smart App Control: Off; no security policy was disabled or modified

Repeated failure timeline (2026-07-27, UTC+8)

  • 22:03:58
  • 22:37:21
  • 23:08:08

At every timestamp, Microsoft-Windows-CodeIntegrity/Operational logged Event ID 3033: ChatGPT.exe attempted to load the packaged app\vk_swiftshader.dll, but it did not meet the Microsoft signing-level requirement.

Event data was identical on each recurrence:

  • RequestedPolicy=8
  • ValidatedPolicy=1
  • Status=3221226536 (0xC0000428, STATUS_INVALID_IMAGE_HASH)

Immediately after the final Code Integrity failure, Microsoft-Windows-AppModel-Runtime/Admin logged Event ID 6 with 0x3CFC; the app became unlaunchable and Windows displayed “This app can’t open / check Microsoft Store for more information about ChatGPT.” Rebooting did not restore it.

Repair evidence

  • 23:09:03: RepairPackageOperation started.
  • 23:09:33: AppModel Runtime Event ID 68 changed package runtime state from 0x2 (Modified) to 0x0.
  • AppX repaired package ACLs and re-registered the same package successfully.
  • 23:09:45: the app launched successfully.

The same crash/unlaunchable cycle had already repeated after earlier repairs/reinstallation. Repair therefore clears the package remediation state temporarily, but it does not remove the trigger: the same bundled DLL remains unsigned and is rejected again.

Earlier Store update logs also contained 0x80073D02 while an older app version was still in use, but the current repeated failures correlate exactly with Event ID 3033 for vk_swiftshader.dll.

This is strong evidence for a durable packaging/recovery fix: ship a fallback binary compatible with the effective Microsoft signing policy, prevent a GPU-child failure from terminating the desktop shell, and avoid leaving the MSIX package in Modified/NeedsRemediation state.

No account data, conversation content, personal paths, or workspace files are included.

VIEWVIEWVIEW · 1 month ago

The current Codex/ChatGPT Store release has a package-signing compatibility problem.

  • Failing package: OpenAI.Codex_26.721.4979.0
  • Windows marks it Modified, NeedsRemediation.
  • Code Integrity blocks app\vk_swiftshader.dll because it does not meet Microsoft signing-level requirements.
  • The DLL exactly matches all 83 hashes in OpenAI’s signed AppX block map, so it was not modified or corrupted locally.
  • The DLL itself has no Authenticode signature. This points to a packaging defect or incompatibility in that release.
  • Windows subsequently reports 0x3CFC: it cannot start the application because the machine-level package status failed.
  • Automatic registration repairs ran repeatedly but did not solve it.

The older OpenAI.ChatGPT-Desktop (“ChatGPT Classic”) installation reports Status: Ok; several of its background processes are still running. The broken app is the newer Codex package that Windows also displays as “ChatGPT.”

The practical fix is to reinstall/update the Codex package through Microsoft Store. If the Store reinstalls the same 26.721.4979.0 build, it may fail again until OpenAI publishes a corrected package. Your .codex workspace and configuration should be preserved, but backing it up
before uninstalling would be prudent.

Edit: I tried installing an older version OpenAI.Codex_26.721.3996.0_x64__2p2nqsd0c76g0 and it works again.

prcapital · 1 month ago

Additional independent 2/2 reproduction on the same affected Store build, with exact Code Integrity/AppModel timing and an AppX caller audit that distinguishes the initial package failure from the later recovery uninstall.

Environment

  • Codex Desktop/MSIX: 26.721.4979.0
  • Browser runtime: 26.721.41059
  • Windows 11 Pro x64: 10.0.26200
  • NVIDIA RTX 4050 Laptop GPU plus Intel Arc Graphics
  • Installed app\vk_swiftshader.dll Authenticode status: NotSigned
  • SHA-256: 2C8F89FA26945207260B9B019F7E1A2F4F6820741B783561F729DC13C7E82C7E

Two matching incidents

Incident 1

  • In-app Browser DOM/page inspection was active.
  • Code Integrity Event 3033: 2026-07-27 16:49:10.677 PDT
  • AppModel Runtime Event 217 destroyed the Codex AppX container: 16:49:13.248

Incident 2, after reinstalling the same Store version

  • A Browser domSnapshot() operation completed at approximately 17:18:39 PDT on an unrelated authenticated site.
  • Code Integrity Event 3033: 17:18:40.275
  • AppModel Event 6 began reporting 0x3CFC: 17:18:40.622
  • AppModel Event 217 destroyed the container: 17:18:41.338

The Event 3033 payload was identical in both incidents apart from correlation IDs:

ProcessNameBuffer: ...\OpenAI.Codex_26.721.4979.0_x64__2p2nqsd0c76g0\app\ChatGPT.exe
FileNameBuffer: ...\OpenAI.Codex_26.721.4979.0_x64__2p2nqsd0c76g0\app\vk_swiftshader.dll
RequestedPolicy: 8
ValidatedPolicy: 1
Status: 3221226536 (0xC0000428)

The correlated Event 3089 records ValidatedSigningLevel=6 and VerificationError=16 in both incidents. No corresponding Application Error or WER event was recorded.

AppX/MSIX sequencing detail

At the second failure, AppModel immediately began rejecting process creation with 0x3CFC and destroyed the Desktop AppX container. Windows then initiated RegisterByPackageFullName with RepairAppRegistrationOption at 17:20:43 and 17:20:45.

There was no AppX Remove operation when Codex disappeared at 17:18. The only formal Remove transaction occurred later at 17:54:04, during user-initiated recovery. Its Event 603 XML identifies:

DeploymentOperation: 2
CallingProcess: SystemSettings.exe

The Store then installed the same package version at 17:55. This confirms the user-visible “uninstall” began as Browser/Code Integrity/AppModel package invalidation; the later formal uninstall was a recovery action, not the original trigger. The associated agent transcript contained no AppX, uninstall, recursive-delete, or other destructive command before either incident.

This supports the failure boundary already documented here:

Browser DOM inspection
→ GPU/SwiftShader path
→ Code Integrity rejects packaged unsigned vk_swiftshader.dll
→ GPU/browser recovery fails
→ AppModel package-status failure
→ AppX container destroyed
→ MSIX repair/restage required

The remaining upstream question is why this GPU/browser failure causes or coincides with package state 0x2 (Modified) despite the Store package being restageable, and whether an additional native Chromium fault occurs between Event 3033 and container destruction.

I initially opened #35701 with this evidence before finding this more complete canonical report. I am closing #35701 as a duplicate and consolidating the additional diagnostic evidence here.

Local usernames, hostnames, authenticated URLs, account identifiers, and task identifiers are omitted. Sanitized Event Viewer exports can be provided if maintainers need them.

zureealLV · 1 month ago

Independent confirmation on a Windows 11 system, with an additional user-facing trigger that does not require Browser Use, DOM inspection, Playwright, or CDP operations.

Environment:

  • Codex Desktop: 26.721.4979.0, Microsoft Store/MSIX
  • Windows 11 Home China 23H2, build 22631.5624, x64
  • NVIDIA GeForce RTX 4060 Laptop GPU, driver 32.0.16.1062
  • Intel UHD Graphics, driver 31.0.101.5333

Trigger:

  1. In Settings → General, configure web links to open inside ChatGPT/Codex.
  2. Run a cybersecurity-related workflow until the Trusted Access message appears.
  3. Click “Learn more”.
  4. The Trusted Access page opens in the embedded browser.
  5. Codex immediately exits and becomes unlaunchable.
  6. Windows Repair restores the application, but repeating the workflow triggers the same failure again.

This occurred three times on my machine.

Local evidence confirms the same failure sequence:

  • Code Integrity Event ID 3033: ChatGPT.exe attempted to load the packaged vk_swiftshader.dll, which did not meet Microsoft signing-level requirements.
  • Codex Desktop log: GPU process crashed with exit code 101457950.
  • GPU process restart failed with exit code 18.
  • AppModel-Runtime Event ID 6: process creation failed with 0x3CFC.
  • AppModel-Runtime Event ID 217: the Codex AppX container was destroyed.

This shows that the defect can also be triggered through a normal user-clicked in-app link, without an automated browser/DOM operation.

htazq · 1 month ago

Independent confirmation from another Windows x64 installation of the Microsoft Store build.

Environment

  • Codex package: OpenAI.Codex_26.721.4979.0_x64__2p2nqsd0c76g0
  • Package version: 26.721.4979.0
  • Architecture: x64
  • Current package status after Store restore/repair: Ok

Reproduced twice on 2026-07-29

Windows Code Integrity logged Event ID 3033 at both 10:56:09 and 11:07:19 local time:

Code Integrity determined that a process
...\WindowsApps\OpenAI.Codex_26.721.4979.0_x64__2p2nqsd0c76g0\app\ChatGPT.exe
attempted to load
...\WindowsApps\OpenAI.Codex_26.721.4979.0_x64__2p2nqsd0c76g0\app\vk_swiftshader.dll
that did not meet the Microsoft signing level requirements.

The corresponding AppModel events show the same failure chain reported here:

10:56:09  AppModel-Runtime Event ID 6
0x3CFC: Cannot create the process because an error was encountered while checking the machine-level package status. The application cannot be started.

10:56:10  Event ID 217
Desktop AppX container destroyed.

The sequence repeated again:

11:07:19  Code Integrity Event ID 3033 for vk_swiftshader.dll
11:07:21  AppModel-Runtime Event ID 6, error 0x3CFC (five occurrences)
11:07:21  Event ID 217, Desktop AppX container destroyed

At that point Windows displayed the localized equivalent of:

This app can't open. Check the Microsoft Store for more information about ChatGPT.

Microsoft Store restore/repair made the app launchable again. The logs confirm that repair reset the package runtime state from 0x2 to 0x0:

11:06:01  Event ID 68: AppModel runtime state updated to 0x0 (previous state = 0x2)
11:08:49  Event ID 68: AppModel runtime state updated to 0x0 (previous state = 0x2)

This is therefore another deterministic reproduction of:

vk_swiftshader.dll Code Integrity rejection → package status 0x2 / remediation state → AppX container destruction → activation failure 0x3CFC → Store repair temporarily restores launchability.

The user did not intentionally modify the package or run an uninstall/update command before either incident. The exact initiating in-app action is currently unknown, which suggests this path may also be reachable through background or restored embedded-browser activity, not only an explicit Browser Use command.

fineshe · 1 month ago

Independent confirmation from #35897.

Environment: Codex Microsoft Store package 26.721.4979.0, Windows build 26200, AMD Radeon 780M + NVIDIA RTX 4050 Laptop GPU.

After receiving the duplicate notice, I checked Microsoft-Windows-CodeIntegrity/Operational. Both incidents logged Event ID 3033 at the exact failure times:

  • 2026-07-29 10:52:33 China Standard Time
  • 2026-07-29 11:09:29 China Standard Time

In both cases, ChatGPT.exe attempted to load the packaged app\vk_swiftshader.dll, which did not meet Microsoft signing-level requirements. Approximately one second later, the Codex desktop log recorded GPU exit code 101457950, followed by GPU relaunch failure exit code 18. The Microsoft Store app then required Repair before it could launch again.

The trigger was Browser Use loading a JAMA Network page. No corresponding display-driver reset or standard WER application crash was recorded. A sanitized evidence ZIP and the Store repair timeline are attached to #35897.

asully-oai · 22 days ago

thank you for calling attention to this issue. This bug was fixed in the 26.727 release

huzz5991 · 21 days ago
thank you for calling attention to this issue. This bug was fixed in the 26.727 release

Thanks for the update. I may still be seeing a related regression — or a different main-process crash with the same user-visible symptom — on a build newer than 26.727.

Environment

  • Codex Microsoft Store/MSIX package: 26.730.8199.0 (x64)
  • Internal release reported in local logs: codex@26.730.61639
  • Package status: Ok
  • Windows 11 Pro x64, build 22621
  • GPU: AMD Radeon(TM) Graphics
  • GPU driver: 31.0.21923.4006

Observed behavior

On 2026-08-07, Codex exited unexpectedly 10 times:

09:41:55, 10:27:36, 11:19:17, 12:06:57, 12:37:28,
13:30:20, 14:04:05, 14:49:37, 15:20:08, and 16:33:06

Each incident generated a Crashpad sidecar with:

{
  "capture_kind": "crash",
  "ptype": "browser",
  "osarch": "x86_64"
}