Codex Windows desktop app still crashes on latest Store build due to WindowsApps ACL sandbox failure (SetNamedSecurityInfoW failed: 5)
What version of the Codex App are you using (From “About Codex” dialog)?
Microsoft Store package version:
26.409.7971.0
From PowerShell:
```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?
- Install Codex from Microsoft Store.
- Launch the Windows desktop app.
- The app fails during startup / initialization.
- Inspect:
C:\Users\<USER>\.codex\.sandbox\sandbox.log
- 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.
2 Comments
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action
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 to26.715.10079.0), no manual sandbox config changes.What I observed:
Microsoft-Windows-AppModel-Runtime/Adminshowed, 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.Get-AppxPackageconfirmed the packageStatusflips toModified, NeedsRemediationrepeatedly — 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 sameModified, NeedsRemediationstatus recurred ~7.5 hours later, causing another silent closure — twice in the same day..codex\.sandbox\sandbox.<date>.log) shows the app repeatedly spawningcodex-windows-sandbox-setup.exe+ apowershell.exe -NoProfile -Command ...helper from inside its ownC:\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 #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 asModified.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.