ChatGPT Desktop “Windows cannot access” after close

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.

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 to A2 to 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.

Scope of the result

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.

The team (the AI agents I direct) assisted with the investigation and drafting. 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 /C

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

The 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 /C

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 (B1 -> A2 -> B2) 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.

For this package, the phase table, Event 208 messages, and icacls commands above are the complete public record; the companion same-host Claude Desktop B-A-B ACL reversal JSON and three-cycle close/reopen audit JSON provide the machine-readable schema from the paired run on the same workstation.

Editorial update, September 23, 2026: clarified the summary and terminology. The methods, data, results and earlier correction record are unchanged.