ChatGPT Desktop “Windows cannot access” after close
On one Windows 11 PC, ChatGPT Desktop cold-start outcome tracked a two-SID ACL treatment across grant, withdrawal, and reinstatement.
Status: Result. One observed failed baseline, then an author-run grant, withdrawal, and reinstatement sequence. n = 1 machine, one package. The treatment was a recursive two-SID Full Control bundle. Mechanism and prevalence are unknown.
Public tracking: openai/codex#45511.
Update, September 14: this revision separates the observed baseline from the controlled phases, records version and activation-stage drift, and reframes the ACL command as an experimental intervention rather than a general repair.
If you have this exact dialog, compare the event and package state below, then start with the read-only diagnostic. Similar ChatGPT Desktop launch failures can require different fixes. Host access control is one of the four failure modes tracked in the agent security research here.
Question
ChatGPT Desktop (OpenAI.Codex) installed and ran. After every process exited, the next launch failed. Reinstalling restored it until the next genuine exit. That cycle lasted months.
The question is narrow. On this machine, did adding, withdrawing, and reinstating a recursive access-control treatment for NT AUTHORITY\SYSTEM and BUILTIN\Administrators track one scored cold-start outcome at each controlled phase?
The target is the treatment-outcome sequence on this workstation, not the responsible SID, object, access check, mechanism, or prevalence.
Object and method
Object: Microsoft Store package OpenAI.Codex_2p2nqsd0c76g0 on Windows 11 Pro 25H2, build 26200.9445. Defender only. Smart App Control off.
“Closed” here means a full process exit. Window-close is not enough. These apps can keep processes alive. Clicking the icon then re-focuses the running instance and never exercises activation.
The natural failure captured on September 13 used package version 26.901.6511.0. It produced the shell dialog:
Windows cannot access the specified device, path, or file. You may not have the appropriate permissions to access the item.
and 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]The controlled grant, withdrawal, and reinstatement ran on September 14 after the Store package had advanced to 26.908.4834.0. Its failed withdrawal produced the same dialog and 0x80070005, but Event 208 ended at [LaunchProcess], not [FinishPackageActivation].
The treatment used icacls against %LOCALAPPDATA%\Packages\OpenAI.Codex_2p2nqsd0c76g0, granting or removing both SIDs with container and object inheritance, recursively. Each controlled phase used one scored launch after confirming no ChatGPT.exe or Codex.exe remained.
The experiment did not invoke install, re-registration, reboot, or package-payload commands. Windows did automatically complete a RepairAppRegistration operation during the absent-treatment phase. A later Event 208 still recorded [LaunchProcess] while the two entries were absent.
Findings
| Evidence | Package version | Two-SID treatment | Outcome |
|---|---|---|---|
| Observed failed state* | 26.908.4834.0 | absent when inspected | app already failing |
| B1 grant | 26.908.4834.0 | present | one scored cold start launched |
| A2 withdrawal | 26.908.4834.0 | absent | one scored cold start failed with the same dialog; Event 208 at [LaunchProcess] |
| B2 reinstatement | 26.908.4834.0 | present | one scored cold start launched |
*The first row is observational. The app was already failing when the ACL state was inspected; it was not a pre-registered or scripted phase. The controlled evidence is B1 → A2 → B2. The earlier natural failure on 26.901.6511.0 supplies the separate [FinishPackageActivation] record.
Outcome tracked the treatment in both controlled directions. 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.
Get-AppxPackage reported Status: Ok, one PackageFullName, and Installed for this user during the experiment. Status: Ok is not a payload-integrity result. File contents were not exhaustively compared.
An AUMID launch, shell:AppsFolder\OpenAI.Codex_2p2nqsd0c76g0!App, produced the same denial. That rules out a shortcut aimed only at a stale versioned path on this machine.
PowerShell and Xbox Accessories, both missing the same two entries on this machine, launched through their AUMIDs. This treatment is not a general requirement demonstrated for all Store packages.
What this does not establish
It does not establish a class-wide root cause for every ChatGPT or Codex Windows launch thread. Do not triage these reports by HRESULT alone. #25770 concerns Store/MSIX update registration failing while the old package remains in use. #35347 begins from Modified, NeedsRemediation and Store redirection. A later comment there discusses 0x80073CFC; the original report does not. This report retained Status: Ok and concerns cold-start activation.
It does not identify which of the two SIDs is load-bearing.
It does not explain how the entries went missing, or whether the next update will recreate the profile without them.
It does not establish that Full Control, recursive propagation, or both trustees are the minimum required treatment.
AI agents assisted the investigation and the writing. I chose the question, the reversal, and what to claim.
Read-only diagnostic and tested intervention
First confirm the same dialog, an AppModel-Runtime Event 208 for OpenAI.Codex, and Get-AppxPackage status Ok. A matching HRESULT alone is not sufficient. Inspect the per-user profile; do not rewrite C:\Program Files\WindowsApps.
$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 /CThe command below documents the treatment that restored launch on this machine:
$p = "$env:LOCALAPPDATA\Packages\OpenAI.Codex_2p2nqsd0c76g0"
icacls $p /grant "*S-1-5-18:(OI)(CI)(F)" "*S-1-5-32-544:(OI)(CI)(F)" /T /CThis is an experimental intervention, not a general or minimum repair. It recursively adds inheritable Full Control entries for LocalSystem and the local Administrators group throughout the per-user profile. The experiment did not test either SID alone, narrower rights, rollback, another machine, or update durability. /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. An expert reproduction should begin with an already-failing package, preserve restorable ACL evidence, and collect read-only state before changing it.
Vendor request
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 SYSTEM and Administrators is the correct product fix.
Data
Author-run on one workstation. Natural failure recorded on 2026-09-13 with version 26.901.6511.0; controlled treatment sequence run on 2026-09-14 with version 26.908.4834.0. Package family OpenAI.Codex_2p2nqsd0c76g0. Event source Microsoft-Windows-AppModel-Runtime/Admin, Event 208, 0x80070005. No second-machine replication.