[Windows][Codex 26.715.4045.0] Page.captureScreenshot crashes GPU process after Code Integrity Event 3033 rejects bundled vk_swiftshader.dll

Closed accidentally. Reopening because the issue is still active and unresolved.

I can confirm that the same Code Integrity / SwiftShader failure still occurs on a newer Codex Windows package. In my case, it also left the MSIX package unlaunchable.

Environment

• Windows 11 Pro 24H2, build 26100, x64
• Codex MSIX: OpenAI.Codex_26.715.10079.0_x64__2p2nqsd0c76g0
• Chromium: 150.0.7871.124
• GPU: NVIDIA GeForce RTX 5090 D
• NVIDIA driver: 32.0.16.1062

The in-app Browser was active shortly before the failure. I cannot confirm that Page.captureScreenshot was the immediate trigger, but the subsequent failure chain matches this issue exactly.

Failure chain

At 2026-07-23 02:01:30 local time:

• Code Integrity Event 3033 blocked ChatGPT.exe from loading app\vk_swiftshader.dll
• Status: 0xC0000428
• Requested signing level: 8
• Correlated Event 3089:
• ValidatedSigningLevel=6
• VerificationError=16
• Chromium GPU child exited with 101457950
• GPU relaunch failed with exit code 18
• Crashpad recorded: GPU process isn't usable. Goodbye.

The browser main process then terminated intentionally. Windows subsequently marked the package:

Modified, NeedsRemediation

Later launches failed during GetPackageToken with 0x80073CFC.

Package integrity

I verified the complete AppxBlockMap.xml:

• 9,541 files checked
• 0 missing files
• 0 size mismatches
• 0 hash mismatches
• AppxSignature.p7x: Valid
• AppxMetadata\CodeIntegrity.cat: Valid

The SHA-256 of vk_swiftshader.dll is:

C5D063024A670677ED580B80EFA90ABBBF36A8F6FFF15F7C6B4A26C475F276BB

This is exactly the same hash reported in the original issue.

After recovery, the running GPU process still reports:

• MicrosoftSignedOnly=ON
• AllowStoreSignedBinaries=OFF

No machine-wide or persistent per-application signing-policy override was found.

Recovery

Windows Settings → Apps → ChatGPT → Advanced options → Repair successfully restaged and registered the same package version:

• Stage/Add: 0x0
• Register: 0x0
• Package status returned to Ok
• The StateChange\PackageList failure entry disappeared
• The app launched normally with existing projects and conversations preserved

I did not repeat the potentially triggering Browser action after recovery, so this confirms startup recovery rather than a permanent fix.

Raw logs and the 45 MB process dump are not attached publicly because they may contain private paths or in-memory data. Sanitized Event XML can be provided if maintainers need it.

Follow-up after checking the public source and the Chromium version bundled by this package:

The public openai/codex repository does not contain the Electron/Chromium/MSIX desktop host code, so there is no honest upstream patch location available to an external contributor here. The repository also currently accepts external code contributions by invitation only.

One useful correction to the original suggested fix: Chromium 150.0.7871.124 already contains the guarded SwiftShader preload introduced by Chromium commit 963206a961a7992b048d07f756f87f11fa2e5420. The M150 branch was cut from main at position #1639810, after that change at #1599159, and the M150 tag source includes the predicate around loading vk_swiftshader.dll.

That makes the current working hypothesis narrower:

1. The initial preload predicate does not require SwiftShader, so the DLL is not loaded before Code Integrity Guard is active.
2. A later Browser/Graphite/Dawn/WebGPU fallback path decides SwiftShader is needed.
3. The late load then runs with MicrosoftSignedOnly=ON and AllowStoreSignedBinaries=OFF, so the catalog-verified MSIX DLL is rejected.
4. The GPU restart fails and Chromium intentionally terminates the browser process.

Potential product-side directions to validate without weakening Code Integrity for users:

• log which SwiftShader preload predicate and later fallback path are selected;
• make the pre-sandbox decision cover every path that can select SwiftShader later;
• use a narrowly compatible sandbox/signing treatment for the packaged DLL (or a Store-compatible binary-signature policy);
• fall back cleanly to WARP or another supported adapter instead of making the desktop app unlaunchable;
• add a packaged-Windows regression test that exercises the in-app Browser screenshot/fallback path and asserts that no Event 3033 or GPU fatal occurs.

I am happy to prepare a focused test or fix if a Codex maintainer invites an external PR and points to the relevant desktop-host source location.

Reproducible recurrence after same-version Repair

I reproduced the failure again on the unchanged OpenAI.Codex_26.715.10079.0_x64__2p2nqsd0c76g0 package. Windows Repair returned the package to Ok at 2026-07-23 02:45:26 +08:00, and the app launched normally at 02:45:47. No reinstall or version update occurred.

During the next in-app Browser Use session:

• 03:10:10: one Browser Use call made the browser visible, created a new tab/webview, navigated, and waited for domcontentloaded;
• 03:10:31: the Browser Use backend/native pipe became ready and permissionProfile/list completed successfully;
• 03:10:33: the Browser webview reached dom-ready;
• 03:10:39: Code Integrity Event 3033 again blocked ChatGPT.exe from loading the same packaged app\\vk_swiftshader.dll (Status=0xC0000428, RequestedPolicy=8, ValidatedSigningLevel=6, VerificationError=16);
• 03:10:39.832: the GPU child crashed with exit code 101457950;
• 03:10:39.837: GPU relaunch failed with exit code 18;
• 03:10:41: the app container was destroyed, and the package returned to Modified, NeedsRemediation.

A new 40,734,912-byte Crashpad dump was created during this sequence. This is the second confirmed recurrence after repairing the same package, so Repair is only a temporary startup recovery, not a fix.

Causal caveat: the timing now strongly associates the failure with Browser Use webview startup/navigation/rendering, but the logs do not show a browser-control permission prompt, grant, or denial causing the crash. permissionProfile/list completed normally, and the resume record shows no explicit permissions. I also found no Page.captureScreenshot, executeCdp, or .screenshot() call in this recurrence, so explicit screenshot capture is not required to reproduce the failure. Because visibility, tab creation, navigation, and initial rendering occurred within one tool call, the exact triggering substep still needs product-side instrumentation.

Confirming the same root cause with a more severe trigger: on machines without usable hardware GPU acceleration, this is fatal at startup on every launch, not just during screenshot capture.

Environment: Windows 11 Pro 21H2 (22000.2538), NVIDIA Quadro K2100M (driver 426.25, EOL) + Intel HD 4600, old enough that Chromium 150 falls back to SwiftShader immediately at startup.

Observed on 26.715.4045.0, 26.715.10079.0, and 26.721.3996.0: the app launches, then the whole process tree dies ~60s in. Each death is preceded 1-2s by CodeIntegrity Event 3033 for the bundled app\vk_swiftshader.dll ("did not meet the Microsoft signing level requirements"). The blocked in-package load also trips MSIX package integrity: AppModel-Runtime logs Event 6 / 0x3CFC ("error checking the machine-level package status") and the package is left in Status "Modified, NeedsRemediation", so all subsequent activations fail until a full reinstall, which then survives exactly one more ~60s run.

Notes: the package payload is not actually modified (all 9,544 files hash-verify against AppxBlockMap.xml; signature chain valid), and an admin IFEO override (Set-ProcessMitigation -Name ChatGPT.exe -Disable MicrosoftSignedOnly) does not help; a fresh 3033 still occurs, so the policy is re-applied at child-process creation and users cannot work around it. Worked until ~April 2026; regressed with the Chromium 150-era update.

Independent reproduction on Windows. This appears to connect the Code Integrity/GPU failure here with the Cloudflare case in #27828, while adding a persisted-task auto-resume variant.

Environment

• Affected Codex package: 26.721.3404.0 (x64)
• Reinstalled/current package: 26.721.3996.0
• Windows 11 build 10.0.26200, x64
• NVIDIA GeForce RTX 5070 Ti plus AMD integrated graphics

Observed sequence

1. Resuming an existing task restored its persisted Codex in-app Browser tab.
2. The restored page entered a Cloudflare-protected flow.
3. Windows displayed a firewall/network consent dialog. The captured timeline shows that the GPU/Code Integrity failure had already begun before Allow was clicked, so the click itself does not appear to be the initiating cause.
4. Codex logged a Chromium GPU crash followed by GPU relaunch failure: reason=crashed, then reason=launch-failed.
5. Windows Code Integrity logged Event 3033 for vk_swiftshader.dll.
6. The AppX container was destroyed. Package state then became appxState=2, Modified/NeedsRemediation, with activation errors 0x3CFC / 0x80073CFC.
7. Codex became unlaunchable. Reinstalling it from the official Store restored launchability.
8. Resuming the affected task reproduced the failure. After backing up local state and removing only thread-browser-tabs-v1:<redacted-task-id>, task history remained intact and automatic re-triggering stopped.

The project and captured task tool history contained no operation that modified WindowsApps, AppX/MSIX state, firewall rules, or package registry state.

I published a redacted, project-independent containment skill for this exact signature:

https://github.com/onovich/codex-iab-guard.skill

CodexIABGuard performs read-only diagnosis, preserves task history, backs up state before any change, quarantines only the selected task's persisted browser state, and recommends resume, clean handoff, or package repair.

This is a mitigation—not a Codex patch or guaranteed permanent fix.

Expected behavior: an embedded-browser GPU/WebGL failure should remain isolated to the tab. It should not terminate the app, poison later launches through restored task state, or leave the MSIX package in Modified/NeedsRemediation.

Additional reproduction on a different Windows/GPU configuration; the issue persists in a newer Codex build.

Environment

• Codex Windows Store app: 26.721.4979.0 (also observed on 26.721.3996.0)
• Windows 10 Education
• GPU: Intel Iris Plus Graphics 655
• Driver: 31.0.101.2140 (reported healthy by Windows)
• Packaged Chromium annotation: 150.0.7871.128

Trigger and result

Opening an existing Codex project that activates its rendered/graphics content causes the app to become blocked or terminate. The failure was reproduced again immediately after opening that project.

Windows Code Integrity records Event ID 3033:

ChatGPT.exe attempted to load ...\vk_swiftshader.dll that did not meet the Microsoft signing level requirements.
Status: 0xC0000428
RequestedPolicy: 8 (Microsoft)

The associated signature event (3089) reports:

ValidatedSigningLevel: 6
Issuer: Microsoft Marketplace CA G 027
OPUS: Microsoft

Additional diagnostics

• The GPU/renderer child process has MicrosoftSignedOnly=ON and AllowStoreSignedBinaries=OFF at runtime; the main process does not have MicrosoftSignedOnly enabled.
• No Microsoft Defender detection was recorded.
• No WDAC, Device Guard, or custom Code Integrity policy is enabled.
• The Store package reports healthy after installation/update.
• Launch flags intended to avoid Vulkan/SwiftShader (--use-angle=d3d11, --disable-vulkan, --disable-software-rasterizer) were not retained by Store activation.
• Per-image Windows mitigation overrides were ineffective because the GPU child establishes its own runtime policy.
• Windows Store update/restaging can look like an automatic uninstall/reinstall to the user, but the Code Integrity failure recurs in the new package.

This confirms that the failure is not limited to NVIDIA hardware, older blocked GPU drivers, or Page.captureScreenshot; it also occurs on Intel Iris Plus 655 when opening project content in the desktop app.

No project content, personal paths, account identifiers, or user SID are included. Full redacted Event XML can be supplied if needed.

Contact for follow-up and privately sharing redacted diagnostic logs/Event XML if needed: bouncken@uni-bayreuth.de

Confirming this remains reproducible on the latest Store build available to this machine, with a different Intel generation and a newer vk_swiftshader.dll payload.

Environment

• Windows 10 Pro 22H2, build 19045.7548, x64
• ChatGPT/Codex Store package: OpenAI.Codex_26.721.4979.0_x64__2p2nqsd0c76g0
• Also observed on 26.721.3996.0 and 26.715.10079.0
• Packaged Chromium: 150.0.7871.128
• GPU: Intel HD Graphics 520
• Driver: 31.0.101.2111 (device status healthy)

Correlated failure

All three observed exits occurred while the in-app Browser/PiP path was active. For 26.721.4979.0, Windows Code Integrity Event 3033 recorded:

Process: ChatGPT.exe
Image: app\vk_swiftshader.dll
Status: 0xC0000428
RequestedPolicy: 8
ValidatedPolicy: 1

The correlated signature event recognizes the Microsoft Marketplace catalog at signing level 6, but the GPU child requests Microsoft signing level 8. The app then records:

GPU reason=crashed exitCode=101457950
GPU reason=launch-failed exitCode=18

Crashpad terminates with:

GPU process isn't usable. Goodbye.
GPU process crashed too many times with software GL

The AppX container is destroyed immediately afterward. The package remains Modified, NeedsRemediation; normal activation repeatedly runs RepairAppRegistrationOption, reports registration success, but creates no ChatGPT.exe process.

Payload and policy verification

• All 9,544 package files independently verified against AppxBlockMap.xml
• 0 missing, size, block-hash, or full-file-hash mismatches
• AppxSignature.p7x and AppxMetadata\CodeIntegrity.cat validate successfully
• SHA-256 of this build's vk_swiftshader.dll: 2C8F89FA26945207260B9B019F7E1A2F4F6820741B783561F729DC13C7E82C7E
• No machine-wide WDAC/UMCI policy or persistent per-image signing mitigation is responsible
• Defender recorded no corresponding detection

The official Store installer currently resolves to the same 26.721.4979.0 package, so same-build recovery can only restore startup temporarily. This newer payload hash still fails the same signing-level boundary, strengthening the conclusion that this is the packaged GPU fallback/sandbox policy path rather than file corruption or one defective DLL build.

No project content, visited URLs, usernames, local paths, account identifiers, user SID, or conversation/task IDs are included. Sanitized Event XML can be supplied privately if maintainers need it.

Independent confirmation from a second Windows machine. This is not limited to NVIDIA/discrete-GPU systems or to one Codex build.

Environment

• Windows 11 Home, build 26200, x64
• CPU: Intel Core i5-1335U
• GPU: Intel Iris Xe integrated graphics (no discrete GPU)
• Intel driver: 32.0.101.7084
• Current packaged Chromium annotation: 150.0.7871.128

Three occurrences on 2026-07-25 (JST, UTC+9)

| Local time | Codex MSIX version | Code Integrity result |
|---|---:|---|
| 02:49:17 | 26.715.4045.0 | Event 3033, vk_swiftshader.dll, 0xC0000428 |
| 06:41:32 | 26.721.3996.0 | Same |
| 10:34:51 | 26.721.4979.0 | Same |

All three Event 3033 XML records contain:

• Process: packaged ChatGPT.exe
• Image: packaged vk_swiftshader.dll
• RequestedPolicy=8
• ValidatedPolicy=1
• Status=3221226536 (0xC0000428)

Same app-side sequence in all three runs

Immediately before each Code Integrity event, the Codex desktop log shows a new in-app Browser/Browser Use tab followed by Browser Use PiP metadata handling. It then records exactly one GPU failure pair:

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

Representative timings:

• 02:49:04 Browser Use tab opened; 02:49:15 PiP metadata; 02:49:17 CI 3033; 02:49:21 GPU crash/relaunch failure
• 06:41:25 Browser Use tab opened; 06:41:31 PiP metadata; 06:41:32 CI 3033; 06:41:33 GPU crash/relaunch failure
• 10:34:16 Browser Use tab opened; 10:34:21/10:34:38 PiP metadata; 10:34:51 CI 3033; 10:34:53 GPU crash/relaunch failure

The target pages differed, so this does not appear site-specific. The second occurrence happened roughly 10 minutes after launch with only four Browser Use tabs, so long uptime/high tab count is not required.

After the GPU relaunch failure, Windows records AppModel-Runtime Event 6 (machine-level package status prevents process creation and recommends reinstall) and Event 217 (Desktop AppX container destroyed). The Store then presents Codex as requiring install/repair, which makes the app appear to have been uninstalled.

Integrity/policy checks

• The repaired current package reports Status: Ok and SignatureKind: Store.
• vk_swiftshader.dll has no embedded Authenticode signature, but signtool verify /pa /c AppxMetadata\CodeIntegrity.cat vk_swiftshader.dll succeeds.
• The live GPU child has MicrosoftSignedOnly=ON, StoreSignedOnly=OFF, while the main Codex process has the signing mitigation off.
• vk_swiftshader.dll is not preloaded in the live GPU process.
• System-wide user-mode CI enforcement is off; Smart App Control is not enforcing; no per-image IFEO mitigation override exists.
• The only Code Integrity Event 3033 records on the machine that day are these three Codex events.
• No GPU driver reset, display reconfiguration, sleep/resume, or device error was recorded near any occurrence.

This appears to be the same Windows GPU Code Integrity failure tracked as BRWPL-293 in #32094, with the additional evidence that it persists across three Store builds and also reproduces on Intel integrated graphics.

Full Windows event XML and sanitized Codex log excerpts can be supplied privately if needed. Local paths, conversation identifiers, and visited URLs are intentionally omitted.

Update from the same Windows 11 / Intel Iris Xe machine: two additional complete occurrences happened on Codex 26.721.4979.0 at 16:01:51 and 16:26:08 JST on 2026-07-25, bringing the total to five occurrences that day.

Both new occurrences repeated the same sequence:

1. An in-app Browser Use webview opened.
2. Code Integrity 3033 blocked the packaged vk_swiftshader.dll (RequestedPolicy=8, ValidatedPolicy=1, Status=0xC0000428).
3. Codex logged GPU exitCode=101457950 (reason=crashed) followed by exitCode=18 (reason=launch-failed).
4. AppModel-Runtime Event 6 blocked packaged process creation and Event 217 destroyed the Desktop AppX container.

Additional environment isolation:

• Windows 11 Home 25H2 build 26200.8875 is the current General Availability build; this PC is not enrolled in Windows Insider.
• Microsoft Defender is active. No active third-party endpoint security, EDR, application-control product, AppLocker policy, or Smart App Control enforcement was found.
• Device Guard reports user-mode CI enforcement off.
• Live process mitigations are role-specific: the main Codex ChatGPT.exe and Chromium network utility have MicrosoftSignedOnly=OFF, while the Chromium GPU child alone has MicrosoftSignedOnly=ON.

That last observation points to a Chromium GPU-child mitigation versus bundled SwiftShader compatibility problem, not a machine-wide third-party signing policy.

Independent confirmation with a repeatable WorldCat trigger on the current Store build.

Environment

• Windows 11 Pro, build 10.0.26200, x64
• Codex Store package: OpenAI.Codex_26.721.4979.0_x64__2p2nqsd0c76g0
• Packaged Chromium: 150.0.7871.128
• GPU: AMD Radeon 780M Graphics
• AMD driver: 32.0.31021.5001 (2026-06-27)
• Package currently reports Status: Ok

Trigger

Using the Codex in-app Browser to open https://library.sebts.edu/ and submit a catalog search redirects the webview to a results page under:

https://sebts.on.worldcat.org/search

The failure occurred four times:

• 2026-07-24 23:28:25 EDT on package 26.721.3996.0
• 2026-07-25 05:05:54 EDT on package 26.721.4979.0
• 2026-07-25 05:09:33 EDT on package 26.721.4979.0
• 2026-07-25 06:09:04 EDT on package 26.721.4979.0

In the first and latest reproductions, the WorldCat results page reached dom-ready about 2–5 seconds before the failure. An explicit screenshot call was not required.

Correlated failure chain

At every occurrence, Microsoft-Windows-CodeIntegrity/Operational Event 3033 reported:

• Process: packaged app\ChatGPT.exe
• File: packaged app\vk_swiftshader.dll
• Status: 0xC0000428
• RequestedPolicy: 8
• ValidatedPolicy: 1
• Message: the DLL did not meet Microsoft signing-level requirements

Correlated Event 3089 reported:

• ValidatedSigningLevel=6
• VerificationError=16

The Codex desktop log then recorded:

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

AppModel-Runtime Event 217 destroyed the Codex Desktop AppX container in the same second. No corresponding memory-exhaustion event, Defender detection, or system-wide display-driver reset was found.

Packaged DLL

For the current 26.721.4979.0 package:

• Get-AuthenticodeSignature: NotSigned
• SHA-256: 2C8F89FA26945207260B9B019F7E1A2F4F6820741B783561F729DC13C7E82C7E

This matches the newer-build hash reported in the related evidence on #32094.

Expected behavior

A SwiftShader/signing-policy failure should be isolated to the GPU child or in-app Browser tab. Opening a WorldCat catalog results page should not terminate the entire Codex desktop application.

Raw logs contain conversation identifiers, so only the correlated and sanitized fields are included here.

Confirmed independently on a newer Codex build and Windows 11. The failure reproduced three times in the same evening.

Environment

• Windows 11 Home 25H2, build 26200.8875, x64
• Memory Integrity / HVCI enabled
• Codex Desktop / MSIX: 26.721.4979.0
• Package state after the incidents: Ok

Repeated sequence

In all three incidents, an existing in-app Browser sidebar/session opened a normal public webpage. No file upload or media action was required. Within seconds:

1. Windows Code Integrity recorded Event ID 3033 for ChatGPT.exe attempting to load packaged app\vk_swiftshader.dll.
2. The event reported RequestedPolicy=8, ValidatedPolicy=1, and status 0xC0000428.
3. Codex logged:

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

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

1. The main Codex desktop process then disappeared and its log ended.

The sequence occurred three times within roughly 50 minutes. The last two incidents happened approximately seven minutes apart after the app was reopened.

Binary verification for 26.721.4979.0

• File: packaged app\vk_swiftshader.dll
• File/product version: 5.0.0
• Size: 5,424,640 bytes
• Embedded Authenticode signature: NotSigned
• SHA-256: 2C8F89FA26945207260B9B019F7E1A2F4F6820741B783561F729DC13C7E82C7E

The differing hash from the earlier package reported above shows that the problem remains in the newer payload rather than being limited to one old DLL build.

Checks that did not support competing causes

• No AppX Remove or DeStage operation occurred at the shutdown timestamps.
• No Microsoft Defender detection or quarantine involved Codex/OpenAI.
• No Windows Application Error or WER event accompanied these incidents.
• No display-driver reset was recorded.
• The Codex package remained installed and reported Status: Ok.

Microsoft Store repair/re-registration restored launchability but also restored the same package and DLL; the failure subsequently recurred. Persisted in-app Browser state appears able to retrigger the crash when restored after relaunch.

Please do not recommend disabling Code Integrity or Memory Integrity as a workaround. The GPU child should either accept the Store-packaged binary under a compatible policy, use a safe fallback when SwiftShader is rejected, or fail without terminating the desktop application.

The original webpage URL, local username, conversation identifiers, and workspace paths are intentionally omitted. Full Codex log excerpts and Code Integrity event XML can be supplied privately if requested.

Replicated with latest codex and nvidia drivers
26.721.4979.0 on NVIDIA driver 610.62.

Additional live verification from Windows 11 build 26200 on the current Store package. This reproduces the same failure described here and in #35411, with a correlated post-crash sandbox failure relevant to #32094.

Environment

• Windows 11 Home x64, build 10.0.26200 / system servicing build 26100.8875
• Codex Store package: OpenAI.Codex_26.721.4979.0_x64__2p2nqsd0c76g0
• Codex Beta also installed: OpenAI.CodexBeta_26.715.3651.0_x64__2p2nqsd0c76g0
• Formal and Beta packages both returned to Status: Ok after remediation, but the trigger remained present

Repeated occurrences

On 2026-07-26 (China Standard Time, UTC+8), Code Integrity Event 3033 recorded the same failure at:

• 11:50:25
• 12:58:11
• 13:14:49
• 15:04:24
• 15:58:03
• 16:07:56

The last occurrence at 16:07:56 produced a complete timestamp-correlated chain:

1. Code Integrity Event 3033: packaged ChatGPT.exe attempted to load packaged app\vk_swiftshader.dll, which did not meet Microsoft signing-level requirements.
2. The Codex desktop log recorded:

``text
Recoverable Chromium child process gone exitCode=101457950 processType=GPU reason=crashed
Recoverable Chromium child process gone exitCode=18 processType=GPU reason=launch-failed
``

1. The same log recorded executeCdp:Page.captureScreenshot failing with Unable to capture screenshot.
2. AppModel-Runtime emitted 0x3CFC process-creation failures and destroyed the AppX container.
3. At 16:28:08, AppModel-Runtime changed the package status from 0x2 back to 0x0, allowing launch again. This restored startup but did not change the triggering binary or remove recurrence risk.

The Beta package independently produced the same Event 3033 against its packaged vk_swiftshader.dll on 2026-07-25 at 16:21:32 and then entered Modified, NeedsRemediation.

Current binary verification

For OpenAI.Codex_26.721.4979.0_x64:

• File: app\vk_swiftshader.dll
• SHA-256: 2C8F89FA26945207260B9B019F7E1A2F4F6820741B783561F729DC13C7E82C7E
• Embedded Authenticode status: NotSigned

This matches the current-package fingerprint reported by other affected users.

Correlated post-crash sandbox impact

After the repeated desktop exits, 13 codex-command-runner-0.146.0-alpha.3.1 processes were still present with dead parent PIDs. A new sandbox command consistently failed with:

windows sandbox: CreateProcessWithLogonW failed: 5

Only the runner processes whose parents were verified dead were terminated. No project, conversation, attachment, AppX data, or .codex state was deleted. Immediately afterward, the same sandbox command executed successfully. This is consistent with the detached-runner cleanup problem discussed in #32094 and suggests that the browser/AppX exit can leave a second, independently user-visible failure behind.

No WindowsApps binaries were modified, Code Integrity remained enabled, and no GPU/browser stress reproduction was performed after startup recovery. Sanitized event details and local log line references can be supplied if maintainers need them.

Second data point: AMD/Win11, plus the two flags that suppress it, plus the package state when it won't reopen

Reproduced independently on different hardware and a different OS, which I think rules out one of your confounders.

Environment

• Windows 11 Pro 26200
• OpenAI.Codex_26.721.4979.0_x64__2p2nqsd0c76g0 (also seen on 26.721.3996.0)
• Packaged Chromium 150.0.7871.128
• GPU: AMD Radeon RX 580, driver unchanged for 60+ days

Same chain as your report: in-app Browser page -> Code Integrity 3033 on vk_swiftshader.dll -> GPU child reason=crashed -> reason=launch-failed, exitCode=18 -> app dies. 3033 and the fatal log line match to the second, 4 for 4.

1. Not NVIDIA-specific. No NVIDIA hardware here and no nvspcap64.dll, so that overlay is not required for the repro -- consistent with your read that the packaged-app signing level is the actual cause.

2. --disable-gpu alone does NOT mitigate it. It only moves compositing onto ANGLE/D3D11-WARP; Chromium still initializes SwiftShader, so the blocked DLL stays reachable. A crash recurred with --disable-gpu in place. The pair that does suppress it:

--disable-gpu --disable-software-rasterizer

Caveat: zero 3033 events since launching with both, but I have not yet forced a Page.captureScreenshot to re-test against the trigger directly. Reporting it as promising, not proven.

3. The "cannot be opened normally" state has specific codes. You noted a restage is sometimes needed; here is what that state actually is. After several Store builds landed in ~48h, a deployment failed with 0x80073CF2 on StageUserData, leaving the package Status : Modified, NeedsRemediation. Every subsequent activation then failed with:

AppModel-Runtime Event 202
0x80073CFC: Cannot create the process for package ... [GetPackageToken]

0x80073CFC is ERROR_NEEDS_REMEDIATION -- activation is blocked because the package is Modified.

4. No local repair clears it -- this may point at the update pipeline. All of these returned success and left the app unlaunchable: Windows' own auto-remediation + ACL repair, Add-AppxPackage -Register <manifest>, Add-AppxPackage -RegisterByFamilyName -ForceApplicationShutdown, and Reset-AppxPackage. None re-validate the payload. Also worth flagging: winget install refuses a same-version reinstall ("No available upgrade found"), so there is no repair path while installed. Only Remove-AppxPackage + reinstall restored Status : Ok -- on the same version number, which says the payload was damaged rather than the build.

Adding to your suggested fixes: whatever produces Modified after a rapid update sequence looks worth investigating on its own -- it turns a recoverable renderer crash into an app that won't start at all.

I reproduced the same failure family on Windows 11 with both a rolled-back build and the current Store build.

Reproduction environment

• Windows 11, build 26200.8875
• Codex Store package 26.721.4979.0 (Status: Ok)
• Browser plugin 26.721.41059
• The same Code Integrity failure was also observed after rolling back to 26.715.10079.0

Local evidence

Opening the in-app browser produced this sequence:

1. The Chromium GPU child crashed with exitCode=101457950.
2. Its relaunch failed with exitCode=18.
3. Code Integrity Event 3033 recorded ChatGPT.exe attempting to load the packaged vk_swiftshader.dll.
4. The event contained Status=0xC0000428, RequestedPolicy=8, and ValidatedPolicy=1.

For the current Store build, vk_swiftshader.dll has no embedded Authenticode signature. The installed AppX package itself remains healthy. The effective mitigation observed on the running GPU child was:

MicrosoftSignedOnly      : ON
AllowStoreSignedBinaries : OFF

This continues to look like a mismatch between the GPU-child binary-signature mitigation and the packaged SwiftShader fallback, rather than ordinary package corruption or a display-driver installation problem.

Targeted state recovery

A narrowly scoped recovery also completed successfully:

1. Fully exit the desktop app.
2. Back up .codex-global-state.json and .codex-global-state.json.bak.
3. Remove only electron-persisted-atom-state["thread-browser-tabs-v1:<redacted>"] from both files.
4. Relaunch normally, leaving hardware acceleration and Windows Code Integrity unchanged.

Both JSON files validated after the edit, the package relaunched with Status: Ok, and conversation/auth/project data remained intact. This suggests that persisted in-app-browser tab restoration can re-arm the failure on subsequent startup, even though it is not the underlying GPU/signing defect.

Suggested product changes

• Quarantine or skip persisted in-app-browser tab restoration after a GPU launch failure.
• Let the conversation open without automatically recreating the failed webview.
• Contain a GPU-child launch failure as a recoverable browser error instead of terminating the desktop container.
• Align the packaged SwiftShader signing/load path with the GPU child's effective mitigation policy.
• Add a packaged-Windows regression test covering Browser navigation/screenshot plus restart recovery with Code Integrity enabled.

I have kept the in-app browser disabled and use external Chrome while the affected binary remains unchanged. No conversation IDs, URLs, account data, local paths, or message content are included here.

The repository contribution guide says external code contributions are by invitation. If a maintainer would like a focused external PR for the recovery guard or a regression test, could you please confirm the intended public component and invite the contribution? I would be happy to implement it against the approach the team prefers.

Additional current-package reproduction: persisted Browser state creates a repeatable crash loop

I reproduced this on the current Store package with a persisted in-app Browser tab. This adds a repeatable task-resume variant and confirms the effective child-process policy.

Environment

• Windows 11 Pro 25H2, build 26200.8875, x64
• Codex Store package OpenAI.Codex_26.721.4979.0_x64__2p2nqsd0c76g0
• AMD Radeon Graphics, driver 32.0.21043.5001
• Package currently reports Status: Ok

Observed sequence

1. Resuming one affected task restored its persisted in-app Browser sidebar/webview and a Cloudflare-protected page.
2. Codex logged maybe_resume_started, attached the Browser webview, reached DOM ready, and then logged:

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

1. Opening/resuming the same task repeated this failure five times on 2026-07-26, at approximately 14:34:49, 15:14:37, 15:35:35, 15:38:16, and 15:38:55 local time.
2. At 15:38:55.170, Code Integrity Event 3033 recorded packaged ChatGPT.exe attempting to load packaged app\vk_swiftshader.dll:

• Status=0xC0000428 (STATUS_INVALID_IMAGE_HASH)
• RequestedPolicy=8
• ValidatedPolicy=1
• Activity ID {6aa39e97-1cfe-0000-5cf5-b96afe1cdd01}

1. Correlated Events 3089 reported:

• ValidatedSigningLevel=6 (Store)
• SignatureType=4
• TotalSignatureCount=2
• VerificationError=16
• catalog issuer Microsoft Marketplace CA G 027

1. Effective mitigation inspection showed:

• main ChatGPT.exe: MicrosoftSignedOnly=OFF
• GPU child: MicrosoftSignedOnly=ON, AllowStoreSignedBinaries=OFF
• renderer/storage children showed the same Microsoft-only policy
• no machine-wide or persistent per-app MicrosoftSignedOnly policy was configured

This indicates Windows is enforcing the binary-signature policy requested for the Chromium child: the DLL validates at Store signing level 6, while the child requests Microsoft-only level 8 and does not allow Store-signed binaries.

User impact and containment

• Codex became unlaunchable twice; recovery ultimately required downloading the 742,738,329-byte Store package again.
• Defender did not detect or quarantine Codex, and no Application Error/WER crash entry was generated for these exits.
• Archiving only the affected task stopped the automatic webview restoration and the current Codex instance has remained stable. No project files or unrelated local state were changed.
• I did not deliberately reopen the affected Browser state after containment.

Requested product fixes

• Do not automatically restore a persisted Browser tab after a GPU launch failure; allow the task itself to open safely.
• Align the packaged SwiftShader load path with the child process policy, for example by using a compatible Store-aware signing policy or a binary/signing arrangement that satisfies the requested level.
• Contain GPU/webview failure to the Browser surface instead of terminating or invalidating the desktop app package.
• Add a packaged-Windows regression test for persisted Browser restoration, Cloudflare/WebGL fallback, Event 3033, and restart recovery.

Private task IDs, URLs, account data, and local paths are intentionally omitted. Sanitized event XML and timestamped app-log excerpts can be supplied to maintainers if needed.

Additional current-build recurrence: ten Browser-prefaced catastrophic clusters

Independent Windows x64 recurrence on the current Microsoft Store package:

• Codex Desktop/MSIX: 26.721.4979.0
• Browser runtime/plugin: 26.721.41059

In the latest occurrence, a hidden/restored in-app Browser webview reached dom-ready; Windows Code Integrity Event 3033 then rejected packaged app\vk_swiftshader.dll with Status=0xC0000428, RequestedPolicy=8, and ValidatedPolicy=1. The Chromium GPU child exited with 101457950 (0x060C201E), its replacement failed with exit code 18, five AppModel-Runtime Event 6 activation refusals followed, and Event 217 destroyed the AppX container. The package entered status 0x2 / Modified, NeedsRemediation and would not launch until Microsoft Store Repair returned it to 0x0 / Ok on the same version.

Package integrity does not support payload corruption: all 83 AppxBlockMap.xml content blocks for vk_swiftshader.dll matched the installed bytes, and the checked executable/GPU payload files also matched their package blocks. Repair restored registration/launchability; it did not change the failed build or establish a fix.

Across ten locally reconstructed catastrophic AppModel clusters from July 22-26, all ten had affirmative in-app Browser/WebView precursors. The sites and conversations varied, so this should not be treated as one page or one conversation being uniquely causal. Hardware acceleration disabled with WARP, explicit GPU preference, and PiP suppression were not sufficient mitigations on the affected path.

The current local containment is to keep only the bundled in-app Browser disabled and prevent retained Browser tabs from auto-restoring after a normal close; external Chrome and Computer Use remain enabled. That is a workaround, not a product fix. A GPU/webview failure still needs to be isolated from the desktop process and MSIX package state, and the packaged SwiftShader load/signing path needs to be compatible with the child process policy.

Related current-build report: #35352. Broader tracked Browser/GPU family: #32094.

Additional reproduction on a multi-GPU workstation running the newest Windows build reported in this thread so far. This corroborates the 26.721.4979.0 reports from @Bouncken and @Samfresh-ai with a byte-identical payload, and adds a further per-image mitigation attempt that also fails.

Environment

• Windows 11 Enterprise 25H2, build 26200.8875, x64
• Codex Store package: OpenAI.Codex_26.721.4979.0_x64__2p2nqsd0c76g0
• Packaged Chromium: 150.0.7871.128
• vk_swiftshader.dll FileVersion: 5.0.0
• GPUs (all three report healthy in Device Manager):
• NVIDIA GeForce RTX 4080 SUPER — driver 32.0.15.9186
• NVIDIA GeForce RTX 4060 — driver 32.0.15.9186
• Intel UHD Graphics 770 — driver 32.0.101.6129

This is a triple-adapter configuration (two discrete + one integrated), which I have not seen reported elsewhere in this thread. Hardware acceleration should be fully available, yet the SwiftShader fallback path is still selected.

Correlated failure

Windows Code Integrity Event 3033, recorded 25 times:

Process: ChatGPT.exe
Image:   app\vk_swiftshader.dll
Status:  0xC0000428   (STATUS_INVALID_IMAGE_HASH)
RequestedPolicy: 8
ValidatedPolicy: 1

Every one of the 25 events carries the identical RequestedPolicy=8 / ValidatedPolicy=1 / 0xC0000428 triple, with no variance. These values match @Samfresh-ai's report for the same package version exactly.

Correlated at the same second, Microsoft-Windows-AppModel-Runtime/Admin:

Event 6 — 0x3CFC: Cannot create the process for package <NULL> because an error
was encountered while checking the machine-level package status.

followed by Destroyed Desktop AppX container ... for package OpenAI.Codex_26.721.4979.0_x64__2p2nqsd0c76g0, after which the package is left Modified, NeedsRemediation.

Timeline and auto-retry pattern

Earliest observed occurrence: 2026-07-03 18:18:20 (on an earlier package build). All later events are on 26.721.4979.0, most recent 2026-07-26 19:24:20 — a 23-day span.

One pattern that may be worth product-side attention: on 2026-07-26 the failure repeated at near-exact ~5-minute intervals without user interaction:

09:40:03   09:44:56   09:49:49   09:54:44   09:59:36   10:04:31   10:09:25

Each timestamp produced a pair of 3033 events. This looks like an automatic relaunch/retry loop re-entering the same blocked load rather than seven manual launches, and it means an affected machine can keep re-triggering the failure unattended.

Payload verification

• SHA-256 of vk_swiftshader.dll: 2C8F89FA26945207260B9B019F7E1A2F4F6820741B783561F729DC13C7E82C7E
• This is a byte-exact match to the hash @Samfresh-ai reported for 26.721.4979.0, confirming an identical payload across independent machines and ruling out a locally corrupted or partially downloaded DLL.
• AppxMetadata\CodeIntegrity.cat present and valid; the DLL is catalog-covered. It has no embedded Authenticode signature, so this is a signing-tier mismatch (requested Microsoft level 8 vs. catalog-validated level 1), not tampering.

Attempted mitigations — all ineffective

A clean uninstall (Remove-AppxPackage, including -AllUsers), reboot, and full Store reinstall completed successfully — verified Status: Ok with the complete ~1.86 GB payload on disk. The app crashed again on the next launch. Package re-registration (Add-AppxPackage -Register ... -DisableDevelopmentMode) reported success but left Status: Modified, NeedsRemediation and an empty PackageUserInformation.

Complementing @MShahid-Khan's finding that -Disable MicrosoftSignedOnly does not help, I also tried the opposite direction — explicitly permitting the tier the DLL actually validates at:

Set-ProcessMitigation -Name ChatGPT.exe -Enable AllowStoreSignedBinaries

This is likewise ineffective, and the registry state shows why:

• The IFEO key is created, but MitigationOptions is written as all zeros
• Get-ProcessMitigation -Name ChatGPT.exe still reports MicrosoftSignedOnly : NOTSET
• The next launch produced a fresh 3033 with unchanged RequestedPolicy=8 / ValidatedPolicy=1

This is consistent with @Bouncken's observation that the GPU child establishes its own runtime policy: the mitigation is applied at process creation via PROC_THREAD_ATTRIBUTE_MITIGATION_POLICY, and Exploit Protection cannot relax a process-creation-specified binary-signature policy. There is no supported client-side setting that resolves this, short of weakening Code Integrity system-wide, which this issue rightly advises against.

Disabling hardware acceleration via the Chromium profile (hardware_acceleration_mode.enabled = false) also did not prevent the load.

Expected behavior

Consistent with what others have asked for in this thread: a GPU-child launch failure should degrade gracefully (fall back to WARP or another supported adapter, or isolate the failure to the tab) rather than terminating the browser process and leaving the MSIX package in Modified, NeedsRemediation. The current behavior presents to non-technical users as the application spontaneously uninstalling itself, and drives repeated Store reinstalls that cannot fix it.

Independent Windows x64 reproduction on both Store stable and Beta.

Stable OpenAI.Codex 26.721.4979.0 and Beta 26.715.3651.0 both crash about
4–7 seconds after the built-in Browser reaches dom-ready on a Cloudflare
Dashboard login page. Each occurrence logs GPU exitCode=101457950
reason=crashed, immediately followed by exitCode=18 reason=launch-failed.

Windows Code Integrity Event 3033 occurs at the same time and rejects the
package's vk_swiftshader.dll. AppModel Runtime then destroys the AppX
container. The stable package becomes "Modified, NeedsRemediation" and
requires Microsoft Store repair/reinstall. Beta restarted and returned to
Ok, but reproduced the same GPU failure.

Environment: Windows 11 Pro 10.0.26200 x64; Intel UHD driver
32.0.101.7088; NVIDIA RTX A5500 Laptop driver 32.0.15.9672. The crash still
occurs after forcing Codex to the NVIDIA high-performance GPU.

Full redacted logs, Event Viewer XML, and a 40.9 MB Crashpad dump are
available privately. Please link this reproduction to the existing
Browser-team investigation and advise the supported method to disable only
the in-app Browser until fixed.

Independent reproduction on Windows 10 x64 (19045.6466, Intel HD 630) with Codex Store package 26.721.4979.0 and Browser plugin 26.721.41059.

The failure occurred three times in two days and each incident made Codex unlaunchable until Windows Apps/Store Repair. The repeated chain was: in-app Browser activity → Code Integrity Event 3033 for packaged app\vk_swiftshader.dll → AppModel 0x3CFC → AppX container termination. Incident start times (UTC+03:00):

• 2026-07-26 16:20:45
• 2026-07-27 01:53:51
• 2026-07-27 12:21:09

For the latest incident, an IAB DOM operation completed at 12:21:07, Events 3033/3089 occurred at 12:21:09, the first 0x3CFC occurred at 12:21:12, and the container ended at 12:21:21. Event 3089 reported requested signing level 8, validated signing level 6 (Microsoft Store), and VerificationError=16.

After same-version Repair, package status returned to Ok and all 83/83 content blocks for vk_swiftshader.dll matched AppxBlockMap.xml. Repair downloaded exactly 742,745,713 bytes and restored the same package version.

No disk/NTFS/WHEA error, custom Code Integrity/WDAC policy, or antivirus quarantine coincided with the crash. Avoiding only the in-app Browser has prevented recurrence so far; external Chrome remains usable. Repair is recovery, not a fix. Sanitized Event XML and timestamped logs are available privately if useful.

Additional independent reproduction on 26.721.4979.0: targeted Browser-state containment

I am adding another independent Windows 11 x64 reproduction, together with a conservative local containment result.

This is a workaround, not a fix for the underlying signing/GPU defect.

Observed failure chain

Environment:

• Windows 11 x64
• Microsoft Store package: OpenAI.Codex_26.721.4979.0_x64__2p2nqsd0c76g0
• Triggering surface: the built-in Browser / restored Browser tabs

A complete recurrence was observed at 2026-07-27 12:01:06 local time (UTC+8):

1. ChatGPT.exe attempted to load packaged app\vk_swiftshader.dll.
2. Code Integrity Operational Event 3033 rejected the load.
3. Windows wrote PackageStatus=2 with BinaryName=...\app\vk_swiftshader.dll.
4. The AppX package changed to Modified, NeedsRemediation.
5. Subsequent package activation failed with 0x80073CFC.

Package-integrity evidence

For vk_swiftshader.dll in this package:

• Size: 5,424,640 bytes
• File version: 5.0.0
• Embedded Authenticode status: NotSigned
• SHA-256: 2C8F89FA26945207260B9B019F7E1A2F4F6820741B783561F729DC13C7E82C7E
• AppxBlockMap.xml verification:
• Expected blocks: 83
• Actual blocks: 83
• Mismatches: 0

Therefore, the installed bytes match the official MSIX BlockMap. This does not look like user modification, partial download, or ordinary file corruption.

Additional negative results:

• DISM /RestoreHealth completed successfully.
• sfc /scannow found no integrity violations.
• Re-registering the package did not prevent recurrence.
• Clearing PackageStatus only restored Ok temporarily; the next blocked load wrote it back to 2.
• Microsoft Store restaged the same version with the same DLL hash; the failure recurred.
• Launching with the following arguments did not prevent the DLL from being loaded:

--use-angle=d3d11 --disable-features=Vulkan,VulkanFromANGLE --disable-software-rasterizer

Targeted containment performed

Before editing anything, I backed up:

• config.toml
• .codex-global-state.json
• .codex-global-state.json.bak

I then disabled the three Browser-related bundled plugins:

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

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

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

Both global-state files contained 10 persisted Browser-tab keys under:

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

I removed only those 10 matching keys from each file—20 stored entries in total, representing the duplicated recovery state in the primary and backup files.

Post-edit verification:

• Both files remained valid JSON.
• thread-browser-tabs-v1:* count became 0 in both files.
• The app relaunched normally.
• The AppX package was still Status: Ok at the final check.

I did not modify or delete:

• .codex\sessions
• .codex\archived_sessions
• state_5.sqlite
• auth.json

Therefore, conversation sessions, the thread database, project state, and primary authentication data were intentionally preserved.

Interpretation and limitation

This result supports persisted Browser-tab restoration as a trigger/re-arm mechanism: restoring an old Browser WebView can re-enter the affected GPU/SwiftShader path during startup or task resume.

It does not prove that clearing Browser state fixes the underlying defect. I have avoided the built-in Browser, Chrome, and Computer Use surfaces after containment.

Another report indicates that disabling browser@openai-bundled alone may not disable the manually opened right-panel Browser UI. I therefore do not claim that these plugin settings are a complete product-level kill switch.

The product still needs to:

1. Make the packaged SwiftShader load/signing path compatible with the GPU child’s effective Code Integrity policy.
2. Isolate Browser/GPU failure from the desktop AppX container.
3. Skip or quarantine persisted Browser tabs after a GPU launch failure.
4. Provide a documented and reliable way to disable all embedded Browser/WebView entry points.
5. Prevent this failure from marking an otherwise BlockMap-valid package as Modified, NeedsRemediation.

Sanitized event details can be provided if maintainers need additional evidence. No conversation IDs, visited URLs, usernames, credentials, or private local paths are included here.

<details>
<summary>中文说明</summary>

26.721.4979.0 的另一例独立复现及 Browser 状态定向规避结果

这里补充一例 Windows 11 x64 的独立复现，以及一套较为保守的本地规避结果。

这只是临时规避，并没有修复底层的签名/GPU 问题。

实际观察到的故障链

环境：

• Windows 11 x64
• Microsoft Store 包：OpenAI.Codex_26.721.4979.0_x64__2p2nqsd0c76g0
• 触发表面：内置 Browser／自动恢复的 Browser 标签

在本地时间 2026-07-27 12:01:06（UTC+8）观察到一次完整复发：

1. ChatGPT.exe 尝试加载包内的 app\vk_swiftshader.dll。
2. Code Integrity Operational 事件 3033 拒绝该加载。
3. Windows 写入 PackageStatus=2，并将 BinaryName 指向 vk_swiftshader.dll。
4. AppX 包变为 Modified, NeedsRemediation。
5. 后续包激活返回 0x80073CFC。

包完整性证据

该版本中的 vk_swiftshader.dll：

• 大小：5,424,640 字节
• 文件版本：5.0.0
• 内嵌 Authenticode 状态：NotSigned
• SHA-256：2C8F89FA26945207260B9B019F7E1A2F4F6820741B783561F729DC13C7E82C7E
• AppxBlockMap.xml 校验：
• 预期分块：83
• 实际分块：83
• 不匹配：0

因此，安装文件与官方 MSIX 的 BlockMap 完全匹配，不像用户修改、下载不完整或普通文件损坏。

此外：

• DISM 修复成功。
• SFC 未发现完整性违规。
• 重新注册 AppX 不能阻止复发。
• 清除 PackageStatus 只能暂时恢复 Ok，下次触发后又会写回 2。
• Microsoft Store 重新暂存的仍是同一版本和同一 DLL 哈希，之后故障再次出现。
• 以下启动参数也未能阻止 DLL 被加载：

--use-angle=d3d11 --disable-features=Vulkan,VulkanFromANGLE --disable-software-rasterizer

已执行的定向规避

修改前备份了：

• config.toml
• .codex-global-state.json
• .codex-global-state.json.bak

随后关闭三个 Browser 相关插件：

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

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

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

两个全局状态文件中各自存在 10 个：

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

只删除了每个文件中的这 10 个键。合计删除 20 条存储记录，对应主文件和备份文件中重复保存的同一批 Browser 恢复状态。

修改后验证：

• 两个文件仍是有效 JSON。
• 两个文件中的 thread-browser-tabs-v1:* 数量均为 0。
• 应用可以正常重新启动。
• 最后检查时 AppX 包仍为 Status: Ok。

没有修改或删除：

• .codex\sessions
• .codex\archived_sessions
• state_5.sqlite
• auth.json

因此，本地会话、线程数据库、项目状态和主要登录凭据均被保留。

判断与限制

该结果支持这样一种判断：持久化 Browser 标签的自动恢复会重新触发受影响的 GPU/SwiftShader 路径。

但这不能证明清除 Browser 状态修复了根因。完成规避后，没有再使用内置 Browser、Chrome 或 Computer Use。

另有报告称，只关闭 browser@openai-bundled 仍可能保留可手动打开的右侧 Browser。因此，我不认为上述插件配置是完整的产品级关闭开关。

产品侧仍需要：

1. 让 SwiftShader 的加载或签名方式符合 GPU 子进程实际采用的 Code Integrity 策略。
2. 将 Browser/GPU 故障隔离在 Browser 表面，避免摧毁整个 AppX 容器。
3. 在 GPU 启动失败后跳过或隔离旧 Browser 标签的自动恢复。
4. 提供有文档说明、能够可靠关闭全部内置 Browser/WebView 入口的方式。
5. 避免该故障把 BlockMap 校验正常的包标记成 Modified, NeedsRemediation。

如维护者需要，可以继续提供经过脱敏的事件信息。本文未包含会话 ID、访问网址、用户名、凭据或私有本地路径。

</details>

Independent Windows x64 reproduction and proposed product fix

I reproduced the same Code Integrity/AppX failure chain on a separate Windows system and can help implement the fix if the Codex team invites an external contribution and identifies the correct desktop-source repository/branch.

Environment

• Microsoft Store package: OpenAI.Codex 26.721.4979.0 (x64)
• Packaged Chromium: 150.0.7871.128
• Bundled Browser plugin: 26.721.41059
• Windows build: 22631
• GPU: NVIDIA RTX 4070 Ti; adapter and driver report healthy

Correlated local evidence

The failure reproduced twice, at 2026-07-28 01:48:08 and 01:53:14 local time (UTC+03:00):

1. Code Integrity Event 3033 rejected packaged app\vk_swiftshader.dll from ChatGPT.exe.
2. Event XML reported RequestedPolicy=8, ValidatedPolicy=1, and status 0xC0000428.
3. AppModel-Runtime Event 217 destroyed the OpenAI.Codex AppX container one second later.

The DLL is not embedded-Authenticode-signed. Its SHA-256 is:

2C8F89FA26945207260B9B019F7E1A2F4F6820741B783561F729DC13C7E82C7E

That is the same payload reported by other users for this package version. After Microsoft Store repair/restaging, the package returned to Status: Ok; there has been no newer Store build offered locally. This supports a signing-tier/process-mitigation mismatch rather than local corruption.

Proposed fix direction

The preferred fix should preserve Code Integrity:

1. Verify that the Chromium/Electron fork used by the Windows package contains and actually exercises Chromium commit 963206a961a7992b048d07f756f87f11fa2e5420, which guards the Windows GPU-sandbox preload of vk_swiftshader.dll and uses WARP/default fallback unless SwiftShader is explicitly requested.
2. If the commit is present, identify the app-level switch or fork divergence that still makes SwiftShader eligible and remove that default opt-in.
3. If explicit SwiftShader support must remain, ship it at a signing level accepted by the GPU child or narrowly allow the Store-signed packaged binary for that child. Do not weaken Code Integrity system-wide.
4. On GPU crashed followed by launch-failed, close/quarantine the affected embedded-browser state and reject pending Browser/CDP calls with a bounded error so the desktop process and restored session remain usable.

A packaged-Windows regression test should repeatedly open an in-app page, read DOM state, capture a screenshot, exercise canvas/WebCodecs, and verify: no Event 3033, no AppModel 217, no Modified/NeedsRemediation, no restored crash loop, and package status remains Ok.

The public openai/codex repository does not contain the Electron/MSIX browser implementation, and its contribution guide requires an explicit invitation. If the browser team would like an external patch for BRWPLAT-293, please invite me and identify the accessible target repository and base branch. I will keep the change focused, preserve the existing public app-server/CLI interfaces, add the Windows regression coverage, and open a draft PR.

I’m seeing the same issue on OpenAI.Codex/ChatGPT 26.721.4979.0, confirming it persists beyond the version originally reported.

• Windows: Windows 11 Pro, build 26200, x64
• Package: OpenAI.Codex_26.721.4979.0_x64__2p2nqsd0c76g0
• Package status: Ok
• Store reports no newer update available
• More than 10 crashes occurred today
• Windows recorded seven matching Code Integrity events today:
• Event ID: 3033
• Process: ChatGPT.exe
• Rejected file: vk_swiftshader.dll
• Reason: did not meet Microsoft signing-level requirements
• The app container was destroyed immediately after several of these events.
• Repairing, uninstalling, and reinstalling the Store package did not prevent recurrence.
• Smart App Control is already off (VerifiedAndReputablePolicyState = 0), so disabling SAC is not a workaround in this case.

Please investigate or backport the proposed packaged-GPU-process fix to the current Windows release.

Comment for openai/codex#34133 (primary)

Confirming this on 26.721.4979.0 with additional isolation data. The Code Integrity rejection is
reproducible and is independent of GPU vendor, render backend, and Windows sandbox mode.

Environment

| | |
|---|---|
| Package | OpenAI.Codex_26.721.4979.0_x64__2p2nqsd0c76g0 |
| Chromium | 150.0.7871.128 |
| Codex CLI | 0.146.0-alpha.3.1 |
| OS | Windows 11 Pro, build 26200, x64 |
| Machine | Lenovo Legion Slim 5 14APH8 (hybrid graphics) |
| GPUs | AMD Radeon 780M 32.0.11034.1002 + NVIDIA RTX 4060 32.0.15.7196 |
| HVCI / Memory Integrity | Off (SecurityServicesRunning = 0) |
| Smart App Control | Off (VerifiedAndReputablePolicyState = 0) |

Note HVCI and Smart App Control are both disabled, so the enforcement is not coming from a
Windows-side code integrity policy — it is the GPU process's own signature mitigation.

Crash signature

Browser process, from the Crashpad minidump annotations:

LOG_FATAL      = gpu_data_manager_impl_private.cc:416: GPU process isn't usable. Goodbye.
ptype          = browser
exception code = 0x80000003 (BREAKPOINT)  in chrome.dll

Code Integrity correlation

Every crash is preceded within 1–6 seconds by a Microsoft-Windows-CodeIntegrity/Operational
Event ID 3033:

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

Six occurrences in one day, each matching a crash:

| CodeIntegrity 3033 | Process exit |
|---|---|
| 14:29:48 | 14:29:5x |
| 15:12:05 | 15:12:06 |
| 19:20:52 | 19:20:53 |
| 20:45:05 | 20:45:11 |
| 21:10:00 | 21:10:02 |
| 21:51:55 | 21:51:58 |

Get-AuthenticodeSignature on the bundled DLL:

Status : NotSigned

Most package DLLs are unsigned (chrome.dll, chrome_elf.dll, libGLESv2.dll, libEGL.dll,
vulkan-1.dll, dxcompiler.dll all return NotSigned) — only d3dcompiler_47.dll carries a
Microsoft signature. So the package relies on MSIX package-level signing, which the GPU process's
Microsoft-signed-only mitigation does not accept.

Not package corruption

I verified the installed payload against the signed block map before concluding anything:

• 9,544 files in AppxBlockMap.xml — 0 missing, 0 size mismatches
• 71 binaries (.exe/.dll/.node) verified block-by-block against the SHA-256 block hashes — 0 mismatches
• Only extra files on disk are AppxBlockMap.xml, AppxSignature.p7x, AppxMetadata\CodeIntegrity.cat (expected)

The DLL is byte-correct. It is simply unsigned.

Backend independence

Reproduced on three different GPU configurations, from the minidump annotations:

| Crash | gpu-venid / gpu-devid | gpu-driver | gpu_count | Backend |
|---|---|---|---|---|
| 15:12 | 0x1002 / 0x15bf | 32.0.11034.1002 | 4 | AMD Radeon 780M |
| 19:20 | 0xffff / 0xffff | 10.0.26100.8875 | 0 | WARP software (--use-angle=d3d11-warp-webgl) |
| 20:45 | 0x10de / 0x28a0 | 32.0.15.7196 | 2 | NVIDIA RTX 4060 |

The 19:20 crash is the significant one: hardware acceleration was disabled and the GPU process was
running pure software WARP with no hardware GPU involved at all, and it still hit the identical
fatal. This rules out any graphics driver as the cause.

Also ruled out:

• Not OOM — committed memory at crash was 0.95–1.66 GB
• No GPU process minidump is produced — only the browser process. Consistent with the child being

refused at image load rather than crashing.

Post-crash: package is left unusable

After each crash the package transitions to:

Status : Modified, NeedsRemediation

and the app will not launch — Windows shows "This app can't open. Check the Store for more info about ChatGPT."
Activation is refused outright (0 processes spawned).

• Add-AppxPackage -DisableDevelopmentMode -Register ...\AppxManifest.xml reports success but **does

not clear the flag** (tried 3×)

• Only a Microsoft Store in-place Repair clears it, because it performs a full re-stage

(RepairPackageOperation → Stage → Register), taking ~2–7 minutes

• Every activation logs AppXDeploymentServer Event 649:

Trying to repair ACLs for \\?\C:\Program Files\WindowsApps\OpenAI.Codex_... → ACLs repaired
successfully. Register next time should succeed.

That ACL repair firing on every activation looks abnormal for a healthy MSIX package and may be
related.

Net effect: each occurrence costs a Store Repair before the app can be used again.

Mitigations attempted — all failed

| # | Attempted | Result |
|---|---|---|
| 1 | hardware_acceleration_mode = {"enabled": false} in Local State | Still crashed (on WARP) |
| 2 | Disabled both DisplayLink indirect display adapters | Still crashed |
| 3 | [windows] sandbox = "unelevated" | Still crashed, after 20 seconds |
| 4 | Set-ProcessMitigation -Name ChatGPT.exe -Disable MicrosoftSignedOnly | Still crashed, after 18 seconds |

On #4 — the IFEO entry applied correctly (MitigationOptions binary-signature field = 2/OFF,
MicrosoftSignedOnly : OFF), but the 3033 still fired. A per-image Exploit Protection override does
not defeat the creation-time mitigation the browser process requests for its GPU child.

On #3 — worth noting explicitly for anyone linking this to #27236: switching the Windows sandbox
mode changes nothing. The DLL rejection occurs identically under both elevated and unelevated,
so the elevated-sandbox ACL behaviour is a separate issue, not the cause of this one.

Partial workaround

Disabling the bundled browser plugin makes the app usable:

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

The app has been stable since. This is consistent with #32334 and #32683 — the in-app browser's
webview initialisation appears to be what pulls in the software-Vulkan path.

Caveat: the reporter observes the crash still occurs when using subagents, even with the
browser plugin disabled. I do not yet have a captured 3033 event or minidump for that specific case,
so I can't confirm whether it is the same signature or a distinct failure — will follow up if I
capture one.

Frequency / triggers

Uptime before crash ranged from 20 seconds to 2.5 hours. Counting distinct thread_ids in the
five minutes before each crash: one crash had 22 concurrent threads, several had 2–3, and one had
0 — it crashed while completely idle, ~2.5 hours after launch, with only 32 log rows in the
preceding five minutes. So this is not purely load-triggered.

Suggested fix

Seconding the original report:

1. Conditionally preload SwiftShader only when the sandbox policy permits it (Chromium 963206a)
2. Or ship vk_swiftshader.dll at a signing level the GPU child's mitigation accepts
3. Independently: a failed GPU-child launch should not leave the MSIX package in

Modified, NeedsRemediation requiring a Store Repair to recover

Happy to provide full minidumps or the raw event log exports.

Additional reproduction from Windows 11 x64 (sanitized):

• OS: Windows 11 25H2, build 26200.
• Package: OpenAI.CodexBeta 26.715.3651.0 x64 (Chromium 150.0.7871.124).
• The package status remained Ok; there were no Crashpad reports, no Resource-Exhaustion events, and 36–47 GB RAM free at the time.
• GPU: AMD Radeon RX 6800 XT, driver 32.0.21043.5001. I do not think this is AMD-specific, as the issue already reproduces on NVIDIA.

Three independent occurrences today had the same tight event order (local time):

1. 09:20:14 — Code Integrity Event 3033 rejected the packaged ...\\app\\vk_swiftshader.dll for ChatGPT (Beta).exe; 09:20:15 — Codex logged processType=GPU reason=crashed exitCode=101457950, then reason=launch-failed exitCode=18, followed by Unable to capture screenshot for executeCdp:Page.captureScreenshot.
2. 10:23:10 → 10:23:12 — same Event 3033 → same GPU crash/relaunch failure.
3. 10:43:19 → 10:43:20 — same Event 3033 → same GPU crash/relaunch failure.

After each failure, the AppX container was destroyed. A Microsoft Store repair/re-registration restored startup temporarily, but did not remove recurrence risk; the package was still Ok afterwards.

I am deliberately avoiding in-app Browser screenshots rather than weakening Code Integrity or modifying the package. Sanitized local logs and the Event 3033 XML can be supplied privately if maintainers need them.

Updated to Microsoft Store package 26.721.11231.0.

Static and runtime checks show that the original signing-policy mismatch
still appears to be present:

• vk_swiftshader.dll size: 5,424,640 bytes
• SHA-256:

2C8F89FA26945207260B9B019F7E1A2F4F6820741B783561F729DC13C7E82C7E

• Authenticode: NotSigned
• GPU child without --disable-gpu-sandbox:

MicrosoftSignedOnly : ON
AllowStoreSignedBinaries : OFF

I have not deliberately triggered Browser Use yet, so this does not confirm
that 26.721.11231.0 still crashes. However, neither the bundled DLL nor the
effective GPU-child binary-signature policy appears to have changed.

Independent corroboration from a Windows 11 / AMD system:

• Codex Browser Use logged Unable to capture screenshot for Page.captureScreenshot.
• Five seconds later, Windows Code Integrity Event 3033 rejected the packaged vk_swiftshader.dll.
• At the same second, Codex logged GPU reason=crashed (exit code 101457950) and then reason=launch-failed (exit code 18).
• The desktop app then required Windows Repair; reopening the same task restored the Browser state and repeated the crash loop.
• Crash package: 26.721.4979.0; package after Store repair/update: 26.721.11231.0.
• Platform: Windows 11 Pro 10.0.26200 x64, AMD Radeon RX 6750 GRE 12GB.
• Local containment: disabled the bundled Browser plugin and removed only persisted thread-browser-tabs-v1 state. The affected task then reopened successfully without a new Code Integrity 3033 event.

Full public incident report: Discussion #36090.

Sanitized evidence bundle: codex-windows-browser-gpu-crash-evidence-2026-07-30.zip

SHA-256: 7485B3231D02289EBC39C9B62EFBD2CE368B31009CC2D41997491086443D763E

The archive excludes prompts, visited URLs, account data, tokens, profile paths, conversation IDs, and browser IDs. Unredacted logs remain local.

Asunto: Windows Codex Beta crashes repeatedly (AppX/container destroy + repair required to relaunch)

Producto: OpenAI Codex Beta (Windows 11)
App version: 26.715.3651.0 x64
Fecha/hora (local): 2026-08-01 09:00 aprox. (y episodios repetidos)

Problema:

• La app se cierra/crashea de forma repetida en momentos de trabajo.
• Tras crash, no vuelve a abrirse salvo reparar/restaurar desde Microsoft Store.
• Esto está pasando desde el primer uso y el workaround de reinstalar es el único que recupera la sesión.

Evidencia reproducida:

• Secuencia de errores en logs: Code Integrity Event 3033 sobre vk_swiftshader.dll -> GPU process crash -> launch-failed.
• El paquete queda en estado aparentemente “OK” pero la AppX se destruye y hay que restaurar.
• Recursos del sistema no parecen el problema (RAM disponible normal en mi caso).

Impacto:

• Impide el trabajo continuo y hace imposible usar Codex de forma estable.

Solicito:
1) Priorizar corrección del fallo en Windows.
2) Restablecimiento o ajuste de uso/cuota por indisponibilidad funcional (si aplica en soporte).
3) Confirmación de workaround temporal oficial mientras se corrige.