[Windows] Desktop app exits after AppX package enters NeedsRemediation while rendering a Codex thread
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:
- Code Integrity Operational event 3033 reported that
ChatGPT.exeattempted to load the bundledvk_swiftshader.dll.
- Status:
0xC0000428(STATUS_INVALID_IMAGE_HASH) - Requested policy:
8; validated policy:1
- 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
- The desktop AppX container for
OpenAI.Codexwas then destroyed. - 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
- Can a SwiftShader/renderer Code Integrity load failure cause the Store-packaged desktop app to enter
NeedsRemediationand have its entire AppX container terminated? - Is there a known graceful fallback path when SwiftShader cannot be loaded?
- 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.
1 Comment
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action