Codex MSIX package self-corrupts to Modified, NeedsRemediation within minutes of launch, making the app unlaunchable ("This app can't open")

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

Version 26.721.41059

What subscription do you have?

PLUS

What platform is your computer?

Microsoft Windows NT 10.0.26200.0 ARM64 (Windows 11 Home, build 26200, Snapdragon / Surface Laptop 7th Ed)

What issue are you seeing?

On Windows 11 ARM64, the Codex Store (MSIX) package puts itself into the Modified, NeedsRemediation state during normal use. Once flagged, Windows refuses to activate the package and the app fails with:

This app can't open. Check the Store for more info about ChatGPT.

The underlying Windows error, from Microsoft-Windows-AppModel-Runtime/Admin (five occurrences within one second):

Id=6  Error
0x3CFC: Cannot create the process for package <NULL> because an error was encountered
while checking the machine-level package status. The application cannot be started.
Try reinstalling the application to fix the problem.

Because this is an activation failure, the app process never starts. Nothing appears in Reliability Monitor, no Application Error (1000) event is generated, and no WER report is created. This makes the problem effectively undiagnosable for a normal user — I spent several hours looking for crash logs that cannot exist.

OpenAI.Codex is the only package on this machine in a non-Ok state. OpenAI.ChatGPT-Desktop, from the same publisher on the same machine, stays Ok throughout.

It reproduces in both sandbox modes. elevated and unelevated differ in the sandbox-user, firewall-rule and network-isolation machinery, but share the ACL-based filesystem boundary pass — which makes that shared ACL pass the most likely culprit.

Environment:

| | |
|---|---|
| OS | Windows 11 Home, 10.0.26200 (build 26200), ARM64 |
| Codex package | OpenAI.Codex_26.721.4979.0_arm64 (Store signature) |
| ChatGPT Desktop | OpenAI.ChatGPT-Desktop_1.2026.190.0_arm64 (Store signature, stays Ok) |
| command-runner | codex-command-runner-0.146.0-alpha.3.1.exe |
| Defender | Real-time protection on, no ASR rules, no exclusions, zero detections |

What steps can reproduce the bug?

1. Uninstall Codex (Settings → Apps → Installed apps → Codex → Uninstall)
2. Reinstall Codex from the Microsoft Store
3. Verify the package is healthy before launching:

``powershell
(Get-AppxPackage OpenAI.Codex).Status
# -> Ok
``

1. Launch Codex and use it normally for a few minutes
2. Re-check:

``powershell
(Get-AppxPackage OpenAI.Codex).Status
# -> Modified, NeedsRemediation
``

1. Close Codex, try to launch it again → "This app can't open"

Repeating steps 1–2 restores it; step 4 breaks it again. I have been through this cycle three times with identical results.

Variant — same outcome with unelevated:

1. Uninstall and reinstall Codex
2. Before first launch, set in %USERPROFILE%\.codex\config.toml:

``toml
[windows]
sandbox = "unelevated"
``

1. (Get-AppxPackage OpenAI.Codex).Status → Ok
2. Launch Codex. It exited on its own after a few seconds, no error dialog, no user action. (Faster than under elevated, where the app stays usable for minutes first.)
3. (Get-AppxPackage OpenAI.Codex).Status → Modified, NeedsRemediation
4. Relaunching gives "This app can't open"

So unelevated is not a usable workaround, and the corruption is not specific to the elevated-only sandbox users / firewall rules.

Windows event log captures the flag being cleared and re-set across a single launch:

09:15:15  AppModel-Runtime  Id=68   AppModel Runtime status for package
                                    OpenAI.Codex_26.721.4979.0_arm64 successfully
                                    updated to 0x0 (previous status = 0x2)

09:16:03  AppXDeployment    Id=400  Deployment Register operation with target volume C:
                                    on Package OpenAI.Codex_26.721.4979.0_arm64 from:
                                    (AppxManifest.xml) finished successfully.

          [Codex launched and used, roughly 09:16 to 09:19]

09:19:11  AppModel-Runtime  Id=217  Destroyed Desktop AppX container for package
                                    OpenAI.Codex_26.721.4979.0_arm64

09:19:38  (Get-AppxPackage OpenAI.Codex).Status -> Modified, NeedsRemediation

Status went 0x2 → 0x0 → 0x2 with no Store update in between — only Codex being launched.

What is the expected behavior?

Launching and using Codex should not alter its own signed Store package.

The package should remain Status: Ok indefinitely, and the app should stay launchable across sessions without needing a reinstall.

Specifically, the sandbox setup should not write to, or change the security descriptor of, anything under C:\Program Files\WindowsApps\OpenAI.Codex_*. MSIX packages are validated against their signed state, so any modification there invalidates the package and blocks activation.

Additionally, the ACL pass should be scoped to the configured sandbox roots rather than applied broadly across unrelated applications' package folders (see Additional information).

Additional information

Windows detects and tries to repair the package ACLs on its own

From Microsoft-Windows-AppXDeploymentServer/Operational:

Id=649  Deployment Register operation on Package OpenAI.Codex_26.721.4979.0_arm64:
        Trying to repair ACLs for
        \\?\C:\Program Files\WindowsApps\OpenAI.Codex_26.721.4979.0_arm64
Id=649  ACLs repaired successfully ... Register next time

Re-registering via Add-AppxPackage -Register <InstallLocation>\AppxManifest.xml -DisableDevelopmentMode repairs permissions but does not clear Modified. Only a full uninstall/reinstall does. That suggests file contents, not only the security descriptor, differ from the signed state.

Orphaned helper process after the app dies

When codex.exe exits, codex-command-runner survives and spins on a dead pipe:

21:52:55  codex.exe             SUCCESS: <powershell command>
21:53:56  (last write to state/logs sqlite files — codex.exe is gone)
21:54:17  codex-command-runner  runner output write failed: The pipe is being closed. (os error 232)
21:54:28  codex-command-runner  runner output write failed: The pipe is being closed. (os error 232)
21:54:40  codex-command-runner  runner output write failed: The pipe is being closed. (os error 232)

Repeated every 10–14 seconds for over three minutes until killed manually. 85 occurrences in a single day's sandbox log.

Sandbox ACEs applied to 203 unrelated package folders

CodexSandboxUsers has an Allow ... ReadAndExecute, Synchronize entry on 203 folders under %LOCALAPPDATA%\Packages, including Microsoft first-party packages and the Windows AI workload packages (WindowsWorkload.*). Only two of those folders belong to OpenAI applications.

Sandbox setup fails partway on every launch

571 occurrences in one day's log:

codex-command-runner-0.146.0-alpha.3.1.exe] hide users: failed to hide current user
profile dir (C:\Users\Default): SetFileAttributesW failed for C:\Users\Default:
5 (Access is denied.)

C:\Users\Default is owned by NT AUTHORITY\SYSTEM with ReadOnly, Hidden attributes, so this looks like an unconditional failure rather than an environment-specific one.

Firewall rules accumulate one set per installed version

30 firewall rules referencing Codex/ChatGPT across 12 distinct versioned install paths:

[2 rule(s)] ...\WindowsApps\openai.codex_26.707.3748.0_arm64...\app\chatgpt.exe
[2 rule(s)] ...\WindowsApps\openai.codex_26.715.2236.0_arm64...\app\chatgpt.exe
[2 rule(s)] ...\WindowsApps\openai.codex_26.715.9868.0_arm64...\app\chatgpt.exe
[2 rule(s)] ...\WindowsApps\openai.codex_26.715.10079.0_arm64...\app\chatgpt.exe
[2 rule(s)] ...\WindowsApps\openai.codex_26.721.3996.0_arm64...\app\chatgpt.exe
[2 rule(s)] ...\WindowsApps\openai.codex_26.721.4979.0_arm64...\app\chatgpt.exe

Because MSIX installs each version to a new versioned path, the previous rule never matches again. Every update therefore triggers a fresh elevated "Allow app to communicate through Windows Defender Firewall" prompt and leaves the old rule behind. This is a visible, recurring annoyance independent of the crash.

Sandbox accounts and group persist and remain enabled

CodexSandboxOffline and CodexSandboxOnline both exist and are enabled, as is the CodexSandboxUsers group ("Codex sandbox internal group (managed)"). These, the ACEs, and the firewall rules survived a Codex uninstall — consistent with #29114.

Sandbox state files look degraded

// .sandbox/setup_marker.json
{ "version": 5, "offline_username": "CodexSandboxOffline",
  "online_username": "CodexSandboxOnline",
  "read_roots": [], "write_roots": [] }

// .sandbox/deny_read_acl_state.json
{ "principals": {} }

Both root lists are empty while the log reports setup refresh: processed 3 write roots (read roots delegated); errors=[].

What I ruled out

• Defender / antivirus — zero detections and zero ASR blocks across the whole period. No ASR rules configured, no exclusions, Controlled Folder Access and Network Protection off.
• Missing dependencies — Microsoft.WindowsAppRuntime.1.6 present and Ok.
• Broken install location — InstallLocation and AppxManifest.xml both present and readable.
• Deny ACEs on package state folders — none anywhere; permissions on %LOCALAPPDATA%\Packages\OpenAI.* match a healthy Microsoft package.
• Sandbox mode — unelevated tested properly on a freshly reinstalled package verified Ok before launch. Corrupts the same way, so there is no config workaround.
• A partially applied Store update — ruled out by the reinstall cycles: the flag returns within minutes of a verified-clean install, with no deployment operation in between other than Codex's own launch.

Questions

1. Does the sandbox setup write to, or change the security descriptor of, anything under its own C:\Program Files\WindowsApps\OpenAI.Codex_* install directory? The log shows codex-windows-sandbox-setup.exe being spawned with its working directory set inside that path. Since the corruption occurs in both elevated and unelevated, the shared ACL pass is the obvious suspect.
2. Is the ACL pass intended to touch all 203 package folders, or should it be scoped to the configured roots (which are empty here)?
3. Should the firewall rule target a stable identity (package family name / AppContainer) rather than a versioned executable path, to stop the per-update prompt and rule pile-up?

Machine name, user name, account SIDs and project paths redacted throughout.