[Windows] Desktop app exits after AppX package enters NeedsRemediation while rendering a Codex thread #35625

Summary

On Windows, the Microsoft Store Codex desktop package repeatedly exited without an error dialog when navigating to a Codex thread through a codex://threads/<REDACTED> deep link. Relaunching could then report that the app needed repair/reinstallation.

The affected thread's contents and identifier are intentionally not included.

Environment

• Windows 11, build 26100
• Stable Microsoft Store package: OpenAI.Codex 26.721.4979.0 (x64)
• Beta package on the same machine: OpenAI.CodexBeta 26.715.3651.0 (did not show the same package-health state)
• Local time zone: UTC+08:00

Observed failure sequence

This sequence occurred four times:

1. Code Integrity Operational event 3033 reported that ChatGPT.exe attempted to load the bundled vk_swiftshader.dll.
   • Status: 0xC0000428 (STATUS_INVALID_IMAGE_HASH)
   • Requested policy: 8; validated policy: 1
2. Within about 0.8–1.4 seconds, AppModel-Runtime/Admin event 6 reported:
   • 0x3CFC / ERROR_NEEDS_REMEDIATION
   • failure while checking the machine-level package state before creating a process
3. The desktop AppX container for OpenAI.Codex was then destroyed.
4. There was no matching Application Error 1000/1002, .NET 1026, or Windows Error Reporting app-crash event.

At the time of failure, Get-AppxPackage -Name OpenAI.Codex reported:

Status: Modified, NeedsRemediation (0x802)

Chrome also emitted comparable Code Integrity events for SwiftShader and continued running, so the Code Integrity event alone does not appear sufficient to explain the whole-app exit.

Sanitized target-thread structure

A non-rendering inspection found no image, video, audio, attachment, or invalid-control-character payloads. It contained two turns and 41 UI items (ordinary text/reasoning/tool/file-change records); the largest text field was about 3.2k characters and the largest tool-argument field about 396 characters.

This does not suggest a malformed or unusually large conversation payload. The deep link appears to trigger a renderer/child-process path that exposes the unhealthy package state.

Recovery observed

Windows/Store remediation later performed RepairAppRegistrationOption, successfully repaired the package ACLs, completed registration, and installed the remediation/update. The package status subsequently returned to:

Status: Ok (0)

I have not reopened the affected thread after remediation, to avoid deliberately triggering another crash.

Questions

1. Can a SwiftShader/renderer Code Integrity load failure cause the Store-packaged desktop app to enter NeedsRemediation and have its entire AppX container terminated?
2. Is there a known graceful fallback path when SwiftShader cannot be loaded?
3. Is there anything the app can log or surface so users do not end up in an apparent reinstall loop after a thread navigation?

I can provide additional sanitized event metadata if useful.