You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Codex Desktop exits when the embedded browser GPU process crashes and unsigned SwiftShader fallback is blocked #35352
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();
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.
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.
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:
Fully exit the desktop app.
Back up .codex-global-state.json and its .bak file.
Remove only the matching thread-browser-tabs-v1:<redacted> property from both files, preserving all conversation, authentication, project, and configuration data.
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.
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.
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.
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:
Ship a fallback DLL that satisfies the Store app's Microsoft signing-level policy, or use another permitted software renderer.
Convert GPU child launch-failed into a recoverable Browser Use error instead of terminating the desktop shell.
Quarantine or discard restored browser state after repeated GPU startup failure to prevent task-resume crash loops.
Add a packaged-Windows validation that checks the fallback DLL signature and exercises GPU-process recovery.
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.
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.
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:
17:23:06 local time
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:
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:
a packaged SwiftShader/signing-policy incompatibility, and
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.
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 loads → Chromium GPU process crashes → bundled SwiftShader fallback is rejected by Windows Code Integrity → GPU relaunch fails → complete 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.
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,528input_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.
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.
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.
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
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:
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:
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.
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
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.
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.
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:
Activity
github-actions commentedon Jul 25, 2026
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action
bdc8rkn66k-art commentedon Jul 26, 2026
Confirmed on a separate Windows x64 system with a different GPU.
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 commentedon Jul 26, 2026
Additional reproduction and recovery evidence from a separate Windows x64 installation of the current Microsoft Store build:
electron-persisted-atom-statewith athread-browser-tabs-v1:<redacted>key.app\vk_swiftshader.dll, the GPU child exited with101457950, and its replacement failed with exit code18. A later launch could show the Microsoft Store guidance message.A targeted recovery succeeded:
.codex-global-state.jsonand its.bakfile.thread-browser-tabs-v1:<redacted>property from both files, preserving all conversation, authentication, project, and configuration data.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:
No conversation IDs, URLs, account data, local paths, or message content are included here.
mmmd3d-source commentedon Jul 26, 2026
Independent reproduction on a Windows x64 installation of Codex Desktop
26.721.4979.0:3033:ChatGPT.exeattempted to load the packagedapp\vk_swiftshader.dll, which did not meet the required Microsoft signing level.0x3CFC; the package then reportedModified, NeedsRemediation/PackageStatus=2.AppxBlockMap.xmlchecked 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 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 commentedon Jul 26, 2026
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:
app\vk_swiftshader.dllbecause it did not meet Microsoft signing requirements.0x80073CFCand moved the app package toNeedsRemediation.Environment/evidence:
26.721.4979.0vk_swiftshader.dll: version5.0.0NotSignedRepair/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 commentedon Jul 27, 2026
Confirmed independently on a second Windows/NVIDIA environment with the same package set.
Environment:
26.721.4979.00.146.0-alpha.3.126.721.410592620032.0.16.1062Reproduction timeline:
101457950(0x060C201E), reasoncrashed.18, reasonlaunch-failed.ChatGPT.exeattempted to load the packagedvk_swiftshader.dll, but the DLL did not meet Microsoft signing-level requirements.Package inspection:
vk_swiftshader.dllfile version:5.0.0NotSignedThe 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:
launch-failedinto a recoverable Browser Use error instead of terminating the desktop shell.ja7226 commentedon Jul 27, 2026
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:
26200.8894, x6426.721.4979.0OpenAI.Codex_2p2nqsd0c76g0Status: OkObserved ChatGPT/Codex sequence:
3033entries.ChatGPT.exeattempted to load packagedapp\vk_swiftshader.dll, and Windows reported that it did not meet the required Microsoft signing level.Modified, NeedsRemediationand became unlaunchable until Store repair/re-registration.0x80073D02failures, consistent with update attempts while package files were in use.Packaged binary evidence:
vk_swiftshader.dllAuthenticode status:NotSigned2C8F89FA26945207260B9B019F7E1A2F4F6820741B783561F729DC13C7E82C7Evulkan-1.dllAuthenticode status:NotSigned30A4CE82D62409DE94D49AC57CA5AAD8CE38DA8898EFC49591CFDDEF567CFA95Additional clue:
During the same period, Windows logged many separate Code Integrity Event
3033entries for ordinary system Chrome150.0.7871.187.chrome.exewas also blocked from loading its ownvk_swiftshader.dllandvulkan-1.dllbecause 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 commentedon Jul 27, 2026
Independent confirmation from another Windows x64 / NVIDIA system, with a reproducible two-incident timeline and an additional process-mitigation clue.
Environment:
26200.8894, x6426.721.4979.0OpenAI.Codex_2p2nqsd0c76g032.0.15.9186vk_swiftshader.dllversion5.0.0Two incidents occurred while the in-app Browser restored/navigated the same publisher webpage:
17:23:06local time17:56:23local time, after the package had been reinstalledAt both timestamps, Windows Code Integrity Operational Event ID
3033reported thatChatGPT.exeattempted to load the packagedapp\vk_swiftshader.dll, but it did not meet the Microsoft signing-level requirement.Event data on both occurrences:
RequestedPolicy=8ValidatedPolicy=1Status=0xC0000428The Codex desktop log then recorded, at the matching timestamp:
101457950(0x060C201E), reasoncrashed18, reasonlaunch-failedPackage/binary checks:
vk_swiftshader.dllAuthenticode status:NotSigned2C8F89FA26945207260B9B019F7E1A2F4F6820741B783561F729DC13C7E82C7EChatGPT.exeprocess mitigation reportsMicrosoftSignedOnly: ONandAllowStoreSignedBinaries: OFFOffAfter 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: Okafter 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:
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 commentedon Jul 27, 2026
Independent local reproduction with corrected root-cause evidence.
I reproduced the same failure on unrelated webpages in Codex Desktop
26.721.4979.0on 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 onperplexity.aiwith no Cloudflare challenge involved.On the Perplexity reproduction, the page reached DOM-ready. About 1.5 seconds later, the desktop log recorded:
The immediate GPU restart then failed:
Local Windows Code Integrity Event ID
3033separately confirms thatChatGPT.exeattempted to load the bundledapp\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 loads→Chromium GPU process crashes→bundled SwiftShader fallback is rejected by Windows Code Integrity→GPU relaunch fails→complete Codex exitCloudflare and
__cf_chl_rt_tkwere 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 commentedon Jul 27, 2026
I can confirm the same failure on another Windows/NVIDIA system.
Environment
26.721.4979.0OpenAI.Codex_26.721.4979.0_x64__2p2nqsd0c76g0Microsoft Windows NT 10.0.26200.0 x6432.0.15.9186Reproduction
Two existing conversations reproducibly crash Codex when opened. Both conversations restore an in-app Browser/WebView state.
Representative sanitized Codex log:
At the exact crash timestamps, Windows Code Integrity recorded Event ID
3033:This occurred repeatedly at the same timestamps as the GPU crash and GPU restart failure.
Additional observations
1,270,902,716bytes and contains3,528input_imageobjects and3,848inlinedata:imagepayloads.10,263,494bytes. Oversized conversation history therefore appears to be an aggravating factor, but it is not required to trigger the GPU/SwiftShader failure.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 commentedon Jul 27, 2026
Independent recurrence with a precise package-state/repair timeline from another Windows x64 installation.
Environment
OpenAI.Codex_26.721.4979.0_x64__2p2nqsd0c76g010.0.26200(build26200)vk_swiftshader.dll: version5.0.0, Authenticode statusNotSignedRepeated failure timeline (2026-07-27, UTC+8)
22:03:5822:37:2123:08:08At every timestamp,
Microsoft-Windows-CodeIntegrity/Operationallogged Event ID3033:ChatGPT.exeattempted to load the packagedapp\vk_swiftshader.dll, but it did not meet the Microsoft signing-level requirement.Event data was identical on each recurrence:
RequestedPolicy=8ValidatedPolicy=1Status=3221226536(0xC0000428,STATUS_INVALID_IMAGE_HASH)Immediately after the final Code Integrity failure,
Microsoft-Windows-AppModel-Runtime/Adminlogged Event ID6with0x3CFC; 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:RepairPackageOperationstarted.23:09:33: AppModel Runtime Event ID68changed package runtime state from0x2(Modified) to0x0.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
0x80073D02while an older app version was still in use, but the current repeated failures correlate exactly with Event ID3033forvk_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/NeedsRemediationstate.No account data, conversation content, personal paths, or workspace files are included.
1 remaining item
prcapital commentedon Jul 28, 2026
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
26.721.4979.026.721.4105910.0.26200app\vk_swiftshader.dllAuthenticode status:NotSigned2C8F89FA26945207260B9B019F7E1A2F4F6820741B783561F729DC13C7E82C7ETwo matching incidents
Incident 1
2026-07-27 16:49:10.677PDT16:49:13.248Incident 2, after reinstalling the same Store version
domSnapshot()operation completed at approximately17:18:39PDT on an unrelated authenticated site.17:18:40.2750x3CFC:17:18:40.62217:18:41.338The Event 3033 payload was identical in both incidents apart from correlation IDs:
The correlated Event 3089 records
ValidatedSigningLevel=6andVerificationError=16in 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
0x3CFCand destroyed the Desktop AppX container. Windows then initiatedRegisterByPackageFullNamewithRepairAppRegistrationOptionat17:20:43and17: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: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:
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 commentedon Jul 28, 2026
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:
26.721.4979.0, Microsoft Store/MSIX22631.5624, x6432.0.16.106231.0.101.5333Trigger:
This occurred three times on my machine.
Local evidence confirms the same failure sequence:
3033:ChatGPT.exeattempted to load the packagedvk_swiftshader.dll, which did not meet Microsoft signing-level requirements.101457950.18.6: process creation failed with0x3CFC.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 commentedon Jul 29, 2026
Independent confirmation from another Windows x64 installation of the Microsoft Store build.
Environment
OpenAI.Codex_26.721.4979.0_x64__2p2nqsd0c76g026.721.4979.0x64OkReproduced twice on 2026-07-29
Windows Code Integrity logged Event ID
3033at both10:56:09and11:07:19local time:The corresponding AppModel events show the same failure chain reported here:
The sequence repeated again:
At that point Windows displayed the localized equivalent of:
Microsoft Store restore/repair made the app launchable again. The logs confirm that repair reset the package runtime state from
0x2to0x0:This is therefore another deterministic reproduction of:
vk_swiftshader.dllCode Integrity rejection → package status0x2/ remediation state → AppX container destruction → activation failure0x3CFC→ 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 commentedon Jul 29, 2026
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:In both cases,
ChatGPT.exeattempted to load the packagedapp\vk_swiftshader.dll, which did not meet Microsoft signing-level requirements. Approximately one second later, the Codex desktop log recorded GPU exit code101457950, followed by GPU relaunch failure exit code18. 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 commentedon Aug 6, 2026
thank you for calling attention to this issue. This bug was fixed in the 26.727 release
huzz5991 commentedon Aug 7, 2026
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
26.730.8199.0(x64)codex@26.730.61639Ok2262131.0.21923.4006Observed 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, and16:33:06Each incident generated a Crashpad sidecar with:
{ "capture_kind": "crash", "ptype": "browser", "osarch": "x86_64" }