Codex Windows desktop app still crashes on latest Store build due to WindowsApps ACL sandbox failure (SetNamedSecurityInfoW failed: 5)

[jaeminy]

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

Microsoft Store package version:

26.409.7971.0

From PowerShell:

Get-AppxPackage OpenAI.Codex | Select Name, Version, InstallLocation

Result:

Name         Version       InstallLocation
----         -------       ---------------
OpenAI.Codex 26.409.7971.0 C:\Program Files\WindowsApps\OpenAI.Codex_26.409.7971.0_x64__2p2nqsd0c76g0

### What subscription do you have?

ChatGPT subscription with Codex access

### What platform is your computer?

Windows x64

### What issue are you seeing?

The Windows desktop app crashes / fails to initialize, while Codex CLI in WSL works normally.

This does not look like a WSL configuration issue on my machine. My WSL setup is valid and running:

wsl -l -v

Result:

  NAME      STATE           VERSION
* Ubuntu    Running         2

The key evidence is in the sandbox log. Codex tries to grant a read ACE to its packaged resources under C:\Program Files\WindowsApps\... and fails with Windows error 5:

granting read ACE to C:\Program Files\WindowsApps\OpenAI.Codex_26.309.3504.0_x64__2p2nqsd0c76g0\app\resources for sandbox users
grant read ACE failed on C:\Program Files\WindowsApps\OpenAI.Codex_26.309.3504.0_x64__2p2nqsd0c76g0\app\resources for sandbox_group: SetNamedSecurityInfoW failed: 5
read ACL run completed with errors
setup error: read ACL run had errors

This strongly suggests the desktop app is failing in the Windows Store / WindowsApps sandbox ACL path.

### What steps can reproduce the bug?

1. Install Codex from Microsoft Store.
2. Launch the Windows desktop app.
3. The app fails during startup / initialization.
4. Inspect:

C:\Users\<USER>\.codex\.sandbox\sandbox.log

5. Observe repeated ACL failures on the WindowsApps packaged resources path with:

SetNamedSecurityInfoW failed: 5

### What is the expected behavior?

The Windows desktop app should start normally and should not try to mutate ACLs on its packaged resources path in a way that causes startup failure.

### Additional information

Additional notes:

- Codex CLI in WSL works normally on the same machine.
- WSL is installed correctly and Ubuntu is the default running WSL2 distro.
- C:\Users\<USER>\.codex\codex-global-state.json does not exist on this machine, which may indicate the app dies before normal initialization completes.
- The sandbox log exists and consistently shows the ACL failure.
- The issue appears related to the same WindowsApps ACL family of bugs reported in:
    - #15179
    - #16502
    - #17612
    - #13965

Relevant local log excerpt:

[2026-03-12T06:37:59.007393200+00:00] read-acl-only mode: applying read ACLs
[2026-03-12T06:37:59.011019200+00:00] granting read ACE to C:\Program Files\WindowsApps\OpenAI.Codex_26.309.3504.0_x64__2p2nqsd0c76g0\app\resources for sandbox users
[2026-03-12T06:37:59.011313700+00:00] grant read ACE failed on C:\Program Files\WindowsApps\OpenAI.Codex_26.309.3504.0_x64__2p2nqsd0c76g0\app\resources for sandbox_group: SetNamedSecurityInfoW failed: 5
[2026-03-12T06:37:59.041330100+00:00] read ACL run completed with errors: ["grant read ACE failed on C:\\Program Files\\WindowsApps\\OpenAI.Codex_26.309.3504.0_x64__2p2nqsd0c76g0\\app\\resources for sandbox_group: SetNamedSecurityInfoW failed: 5"]
[2026-03-12T06:37:59.041409100+00:00] setup error: read ACL run had errors

If needed, I can provide a larger sanitized sandbox.log excerpt.

[github-actions]

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

• Windows desktop app repeatedly fails with "timeout waiting for child process to exit" due to sandbox ACL failure in WindowsApps #17612
• Codex Desktop closes immediately after launch on Windows #16502

Powered by Codex Action

[happycrelab-web]

Adding corroborating diagnostics from a fresh occurrence today (2026-07-23), which may help pin down the root cause behind the ACL failures reported in this issue.

Environment: Windows 11, Codex Store app (was OpenAI.Codex_26.715.8383.0, later auto-updated to 26.715.10079.0), no manual sandbox config changes.

What I observed:

1. The app closed silently mid-session with no Windows Error Reporting (WER) crash entry at all — confirmed via Event Viewer (Application log, IDs 1000/1001/1002: none for the crash window).
2. Microsoft-Windows-AppModel-Runtime/Admin showed, at the exact moment of the closure: 0x3CFC: Cannot create the process for package because an error was encountered while checking the machine-level package status, followed immediately by the app's AppX container being destroyed. 0x3CFC = ERROR_NEEDS_REMEDIATION (15612) per Microsoft's WinError.h docs.
3. Get-AppxPackage confirmed the package Status flips to Modified, NeedsRemediation repeatedly — not just once. Windows' own "Repair" (Settings > Apps) failed once with a generic "could not repair" error. A full uninstall + reinstall via Microsoft Store fixed it temporarily, but the exact same Modified, NeedsRemediation status recurred ~7.5 hours later, causing another silent closure — twice in the same day.
4. Between closures, the sandbox log (.codex\.sandbox\sandbox.<date>.log) shows the app repeatedly spawning codex-windows-sandbox-setup.exe + a powershell.exe -NoProfile -Command ... helper from inside its own C:\Program Files\WindowsApps\OpenAI.Codex_...\app\resources\ folder — roughly every 1–2 minutes while the app is running (this looks like the "setup refresh" mechanism, possibly the same one in Sandboxed PowerShell commands intermittently fail on Windows with windows sandbox: spawn setup refresh #25497). Given this issue's finding that Codex tries to modify ACLs on files under that same protected folder, this very frequent internal churn seems like a plausible trigger for Windows' AppX integrity check to flag the package as Modified.

I can't confirm the causal link in #4 with certainty, but the timing/location strongly correlate. Happy to share full Event Viewer/sandbox log excerpts if useful.