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

Open 💬 2 comments Opened Apr 15, 2026 by jaeminy
💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

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?

  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

  1. 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.

View original on GitHub ↗

2 Comments

github-actions[bot] contributor · 4 months ago

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

  • #17612
  • #16502

Powered by Codex Action

happycrelab-web · 1 month ago

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 #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.