›_ Codex Issues
Codex Issues / #35681

[Windows app] Opening any chat triggers Code Integrity 3033 for vk_swiftshader.dll, corrupts MSIX package, and prevents relaunch (0x3CFC)

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

What version of the Codex App are you using (From “About Codex” dialog)?

Microsoft Store package: 26.721.4979.0

What subscription do you have?

Business

What platform is your computer?

Microsoft Windows NT 10.0.26200.0 x64

What issue are you seeing?

Opening any conversation in the Windows Codex/ChatGPT app causes its rendering/GPU process to fail. This is not conversation-specific.

At the exact time of failure, Windows Code Integrity records Event ID 3033:

Code Integrity determined that a process
(\Device\HarddiskVolume2\Program Files\WindowsApps\
OpenAI.Codex_26.721.4979.0_x64__2p2nqsd0c76g0\
app\ChatGPT.exe)

attempted to load

\Device\HarddiskVolume2\Program Files\WindowsApps\
OpenAI.Codex_26.721.4979.0_x64__2p2nqsd0c76g0\
app\vk_swiftshader.dll

that did not meet the Microsoft signing level requirements.

The GPU child exits, with an observed exit code of 101457950; the attempted GPU-process relaunch then fails with exit code 18.

Immediately afterward:

(Get-AppxPackage OpenAI.Codex).Status

returns:

Modified, NeedsRemediation

The application closes and subsequent launches fail. AppModel Runtime records Event ID 6 with error 0x3CFC, indicating that the process cannot be created because of the machine-level package status and that reinstalling the application is recommended.

A forced Microsoft Store reinstall restores the package status to Ok, but opening any chat normally reproduces the failure and returns the package to Modified, NeedsRemediation.

This does not appear to be genuine on-disk tampering or antivirus modification. SHA-256 verification of ChatGPT.exe, chrome.dll, vk_swiftshader.dll, and the other inspected application payloads matched their entries in the signed AppxBlockMap.xml.

System-wide Exploit Protection does not have MicrosoftSignedOnly enabled, there is no process-specific ChatGPT mitigation override, and Device Guard reports user-mode Code Integrity policy enforcement as disabled. The rejection appears to be associated with the sandboxed Chromium GPU-process path.

What steps can reproduce the bug?

  1. Install or force-reinstall the official Microsoft Store package:
winget install --id 9PLM9XGG6VKS --source msstore --force --silent `
  --accept-package-agreements --accept-source-agreements `
  --disable-interactivity
  1. Confirm that the package is initially healthy:
(Get-AppxPackage OpenAI.Codex).Status

Expected initial result:

Ok
  1. Launch the application normally.
  1. Click any existing conversation in the sidebar.
  1. The application exits or becomes unusable.
  1. Inspect the Code Integrity Operational log. Event ID 3033 reports that ChatGPT.exe attempted to load the packaged vk_swiftshader.dll, which did not meet Microsoft signing-level requirements.
  1. Inspect the package again:
(Get-AppxPackage OpenAI.Codex).Status

Actual result:

Modified, NeedsRemediation
  1. Try launching the application again. It fails with AppModel Runtime error 0x3CFC.
  1. Reinstalling restores the package, but repeating steps 3–4 reproduces the problem.

What is the expected behavior?

Opening any conversation should start the required renderer without attempting to load a DLL that is incompatible with the package’s Code Integrity requirements.

A rendering-process failure must not transition the installed MSIX package to Modified, NeedsRemediation or make all subsequent launches fail.

If Vulkan or SwiftShader is unavailable because of Windows Code Integrity, the application should fall back safely to the installed D3D11-capable GPU.

Additional information

Verified diagnostic workaround

The following launch configuration allowed the same previously failing conversation to open successfully:

$pkg = Get-AppxPackage OpenAI.Codex
$exe = Join-Path $pkg.InstallLocation 'app\ChatGPT.exe'

Start-Process -FilePath $exe -ArgumentList @(
    '--use-angle=d3d11',
    '--disable-software-rasterizer',
    '--disable-gpu-sandbox',
    '--disable-features=Vulkan,DefaultANGLEVulkan,VulkanFromANGLE,RendererCodeIntegrity'
)

The resulting GPU subprocess inherited:

--type=gpu-process
--disable-gpu-sandbox
--use-angle=d3d11
--disable-features=DefaultANGLEVulkan,RendererCodeIntegrity,Vulkan,VulkanFromANGLE

During a monitored reproduction test after adding --disable-gpu-sandbox:

  • The affected conversation opened successfully.
  • The application remained running with ten subprocesses.
  • Package status remained Ok.
  • No new Code Integrity event was generated.

Launching with D3D11, Vulkan disabled, software rasterization disabled, and RendererCodeIntegrity disabled—but without --disable-gpu-sandbox—still reproduced the vk_swiftshader.dll rejection. This narrows the failure to the sandboxed GPU-process/code-integrity interaction.

--disable-gpu-sandbox reduces process isolation and is therefore only a diagnostic/user workaround, not an acceptable permanent product fix.

Suggested permanent fix

  1. Ensure the packaged vk_swiftshader.dll satisfies the Microsoft signing level enforced on the GPU child, or prevent that DLL from being selected under this sandbox policy.
  2. Prefer D3D11 when the installed hardware GPU is available and healthy.
  3. Handle Code Integrity loader rejection without corrupting the package’s operational status.
  4. Add a Windows regression test that launches the Store/MSIX build, opens a conversation, and verifies that no Code Integrity 3033 event or package remediation state occurs.

View original on GitHub ↗

5 Comments

github-actions[bot] contributor · 1 month ago

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

  • #35625
  • #35566
  • #35505
  • #35464
  • #35132

Powered by Codex Action

yooooo00 · 1 month ago

Additional reproduction on Windows x64 (local time, 2026-07-28):

  • Codex MSIX: OpenAI.Codex_26.721.4979.0_x64__2p2nqsd0c76g0
  • Codex version: 26.721.4979.0
  • Windows build: 26200
  • GPU: NVIDIA GeForce RTX 3050 Laptop GPU, driver 32.0.15.9636 (Intel UHD Graphics also present)

At 09:55:47, Windows recorded Code Integrity Event 3033: ChatGPT.exe attempted to load the packaged vk_swiftshader.dll, which did not meet Microsoft signing-level requirements. At the same timestamp, AppModel Runtime recorded repeated 0x3CFC launch failures and destroyed the Codex AppX container (Event 217).

After Microsoft Store repair, AppModel Event 68 reported the package state changing from 0x2 to 0x0 at 10:01:26; the package currently reports Status: Ok.

The package files were not manually modified. A local SQLite INSERT-blocking trigger was present on logs_2.sqlite to suppress telemetry writes; PRAGMA quick_check returned ok, and the AppX failure still occurred.

joshwils-cell · 1 month ago

I can independently corroborate this issue on the same Windows and app build.

Environment:

  • ChatGPT/Codex Microsoft Store package: OpenAI.Codex_26.721.4979.0_x64__2p2nqsd0c76g0
  • Bundled Chromium executable version: 150.0.7871.128
  • Windows 11 Enterprise 25H2, build 26200.8875, x64
  • Hybrid graphics: Intel UHD Graphics 31.0.101.2137 + NVIDIA GeForce MX250 32.0.15.7344

On 2026-07-28, four separate app sessions ended immediately after the embedded browser/rendering path started. Each session recorded the same sequence:

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

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

The Code Integrity events and GPU-child failures align to within a few seconds. Chromium profile state also records profile.exit_type: Crashed. Windows shows no unexpected system shutdown, no configured WinHTTP/user proxy, and no Defender detection involving the app. AppX deployment records show that package staging/registration completed successfully; the failure happens afterward in the GPU/rendering path.

The behavior is especially reproducible when the built-in browser accesses or renders web content. It is not tied to a specific website or conversation. Historical logs also show repeated 0xc06d007f crashes in package 26.707.9981.0 on the same machine, suggesting this may have affected more than the current package revision.

Please keep Windows Code Integrity and the GPU sandbox intact in the permanent fix. Ideally, the packaged SwiftShader component should satisfy the GPU child’s signing requirements, or Chromium should safely fall back to the available D3D11 hardware path without terminating/remediating the app. No private chat contents, local file contents, usernames, or device identifiers are included here.

unicbm · 1 month ago

Additional root-cause isolation and recovery result for the same package/build:

A single conversation was persistently recreating an embedded browser tab on every thread restore. The durable state was stored under a per-thread key shaped like:

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

The value contained one manual browser tab with a redacted restoreUrl, plus rightPanelOpen=true. The conversation data itself was healthy; thread/read and turn loading completed successfully.

I reproduced the following sequence twice:

  1. Force-repair the Microsoft Store package; package status returns Ok.
  2. Launch normally and open the affected conversation.
  3. The persisted tab is restored and a WebView is created.
  4. The GPU child exits with 101457950, its replacement fails with 18, and Code Integrity Event 3033 rejects the packaged vk_swiftshader.dll.
  5. Package status changes to Modified, NeedsRemediation; subsequent launch fails with AppModel Runtime 0x3CFC.

A controlled recovery confirmed the persisted browser tab is the deterministic trigger:

  1. Back up the app state.
  2. Remove only the affected thread's browser-tab state (or close that exact in-app tab while the app can be launched diagnostically).
  3. Force-repair the Store package once more.
  4. Launch the app normally, with no Chromium flags, and reopen the same conversation.

Validation after that recovery:

manual embedded-browser tabs: 0
restored browserTabId: null
package status: Ok
new Code Integrity 3033 events: 0
new AppModel Runtime errors: 0
GPU child crash / launch-failed entries: 0
normal app process: alive and responsive

This also explains why the bug can look “conversation-specific”: the chat content is not corrupt; the conversation owns persisted browser UI state that automatically re-enters the failing WebView/GPU path whenever it is reopened.

Suggested product-side changes:

  • Do not let a restorable in-app browser tab place the entire desktop app into a permanent crash loop.
  • If browser/GPU initialization fails, discard or quarantine that tab's restore state and keep the thread UI usable.
  • Provide a supported safe-start/recovery path that suppresses browser-tab restoration.
  • Fix the packaged SwiftShader/signing or GPU-sandbox fallback problem described in this issue.

All thread IDs, account data, local paths, page URLs, and conversation contents are redacted. No security-reducing Chromium flags were retained as a permanent workaround.

maaoding · 28 days ago

Follow-up from the same Windows machine after updating the Microsoft Store package.

Environment:

  • Windows 11 Pro 10.0.26200 (build 26200)
  • OpenAI.Codex package: 26.721.11231.0
  • Package status: Ok

During a monitored app session started on 2026-07-30 at 21:31 CST (UTC+8):

  • No new Code Integrity event 3033 was recorded.
  • No error-level AppModel event matching OpenAI.Codex or 0x3CFC was recorded.
  • The active GPU process does not use --disable-gpu-sandbox.
  • Its loaded modules include d3d11.dll and D3DCompiler_47.dll; vk_swiftshader.dll and Vulkan modules are not loaded.
  • The app has remained responsive and the AppX package status has remained Ok.

The packaged vk_swiftshader.dll still returns NotSigned from Get-AuthenticodeSignature. Its current SHA-256 is:

2C8F89FA26945207260B9B019F7E1A2F4F6820741B783561F729DC13C7E82C7E

This is a clear improvement over 26.721.4979.0, but it does not establish whether the issue was intentionally fixed or whether this run simply selected the working D3D11 hardware path. I could not find a corresponding fix in the public changelog.

Could you confirm whether 26.721.11231.0 changed the ANGLE/GPU fallback behavior for this failure? I recommend keeping the issue open until the Store/MSIX build has a regression test that opens conversations and verifies that no 3033 event or Modified, NeedsRemediation package state occurs.