[Windows] ChatGPT Desktop cold start access denied (0x80070005); one-machine ACL treatment sequence

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

Two versions are relevant:

• Natural failed launch captured September 13: 26.901.6511.0
• Grant-withdrawal-reinstatement sequence on September 14: 26.908.4834.0

Versions came from the package full name and event records because the failed cold start never reached About.

What subscription do you have?

Not recorded. The failure occurs during Windows AppX activation before account state is read.

What platform is your computer?

Microsoft Windows NT 10.0.26200.0 x64 (Windows 11 Pro 25H2, build 26200.9445)

What issue are you seeing?

After a genuine process exit, ChatGPT Desktop / Codex from the Microsoft Store fails to launch with:

Windows cannot access the specified device, path, or file.
You may not have the appropriate permissions to access the item.

The dialog names a path under C:\Program Files\WindowsApps\OpenAI.Codex_…\app\.

The September 13 natural failure on 26.901.6511.0 produced Microsoft-Windows-AppModel-Runtime/Admin Event 208:

0x80070005: Cannot create the process for package
OpenAI.Codex_…_x64__2p2nqsd0c76g0 because an error was
encountered while configuring runtime. [FinishPackageActivation]

During the later controlled sequence on 26.908.4834.0, withdrawal produced the same dialog and 0x80070005, but Event 208 ended at [LaunchProcess]. The package continued to report Status: Ok and Installed for this user. Status: Ok is not a payload-integrity result.

Window-close alone is not the repro because leftover processes can make the next click a re-focus instead of a cold start. An AUMID launch using shell:AppsFolder\OpenAI.Codex_2p2nqsd0c76g0!App produced the same denial, ruling out only a shortcut aimed at a stale versioned path.

Do not triage these reports by HRESULT alone:

• #25770 concerns Store/MSIX update registration failing while the old package remains in use. Its comments report several codes, including 0x80070005.
• #35347 begins from Modified, NeedsRemediation and Store redirection. A later comment discusses 0x80073CFC; the original report does not.
• This report retained Status: Ok and concerns a cold-start activation denial.

What steps can reproduce the bug?

On this machine the outcome tracked a recursive two-SID ACL treatment on %LOCALAPPDATA%\Packages\OpenAI.Codex_2p2nqsd0c76g0: NT AUTHORITY\SYSTEM (S-1-5-18) and BUILTIN\Administrators (S-1-5-32-544), granted Full Control with object/container inheritance.

The first failed state was observational. The controlled evidence is one scored launch per B1 → A2 → B2 phase after confirming no ChatGPT.exe or Codex.exe remained:

Evidence	Treatment	Cold start
Observed failed state	absent when inspected	app already failing
B1 grant	present	one scored launch opens a window
A2 withdrawal	absent	one scored launch fails with the same dialog; Event 208 at [LaunchProcess]
B2 reinstatement	present	one scored launch opens a window

Both withdrawal and reinstatement used recursive ACL operations, yet withdrawal restored failure. Recursive traversal or ACL activity alone was therefore not sufficient under these conditions.

During A2, Windows automatically completed a RepairAppRegistration operation between two Event 208 records. The later Event 208 still occurred while the profile treatment was absent. The experiment itself did not invoke install, re-registration, reboot, or package-payload commands.

Negative control on the same machine: Store PowerShell and Xbox Accessories also lack those two ACEs and still launch via AUMID. Missing SYSTEM/Administrators is not a general Store-app killer.

n = 1. The experiment did not identify the responsible SID, object, access check, minimum rights, or propagation scope. Mechanism, prevalence, and update durability remain open.

What is the expected behavior?

A Store install reporting Status: Ok should cold-start after a real process exit.

When Event 208 reports E_ACCESSDENIED while Get-AppxPackage still reports Status: Ok, please expose the denied object, requested access mask, and principal in diagnostics. Determine whether profile creation, package update, activation, or application behavior should change. This experiment does not establish that broadly stamping Full Control for these trustees is the correct product fix.

Additional information

Read-only diagnostic first:

$p = "$env:LOCALAPPDATA\Packages\OpenAI.Codex_2p2nqsd0c76g0"
Get-AppxPackage -Name OpenAI.Codex |
  Select-Object PackageFullName, Status, PackageUserInformation
icacls $p /findsid "*S-1-5-18" /T /C
icacls $p /findsid "*S-1-5-32-544" /T /C

Experimental intervention used on this one machine:

icacls $p /grant "*S-1-5-18:(OI)(CI)(F)" "*S-1-5-32-544:(OI)(CI)(F)" /T /C

This recursively adds inheritable Full Control entries throughout the per-user profile. It is not a validated general or minimum repair. /C continues after errors, so inspect the completion summary. Do not remove ACLs from a healthy profile to reproduce this result. Prefer a vendor-supported recovery path.

Write-up with the same scoped claim: https://simoneresearch.com/blog/chatgpt-desktop-access-denied-after-close/

Author: Jonathan Simone (thisisntjon). AI-assisted investigation; the reversal and the claim list are mine.

Start with the read-only PowerShell commands for Get-AppxPackage and icacls, then correlate Microsoft-Windows-AppModel-Runtime/Admin Event 208 during an AUMID cold start. Done means identifying the denied object, requested access mask, and principal, and establishing whether a vendor-supported change is needed without treating the one-machine ACL experiment as a general fix.