Claude Desktop “Windows cannot access” after close
On one Windows 11 PC, Claude Desktop launch results and Event 208 changed when two permission entries were removed and restored.
- Author
- Jonathan Simone
- Kind
- Result, measured by the author
- Published
- Revised
- History
- 2 revision notes (September 14; September 23, 2026), kept in the text
- Filed under
- Agent security
Update, September 14: this revision separates the earlier user-facing symptom from what the controlled run recorded, and reframes the recursive ACL command as an experimental intervention rather than a general repair.
Question
Claude Desktop installed, ran, and reported Status: Ok. On earlier genuine cold starts it displayed:
Windows cannot access the specified device, path, or file. You may not have the appropriate permissions to access the item.
At the start of this test, its per-user package profile contained NT AUTHORITY\SYSTEM and BUILTIN\Administrators, and Claude launched.
The controlled question was narrower: with Claude otherwise working, did deliberately withdrawing that two-SID treatment remove the visible cold-launch outcome and produce Event 208, and did reinstating it restore the visible launch?
Object and method
Object: Claude Desktop package Claude_1.52386.6.0_x64__pzs8sxrjxfjjc on Windows 11 Pro 25H2, build 26200.9445. Get-AppxPackage reported Status: Ok.
The profile was %LOCALAPPDATA%\Packages\Claude_pzs8sxrjxfjjc. Its root initially contained explicit Full Control entries for:
NT AUTHORITY\SYSTEM(S-1-5-18)BUILTIN\Administrators(S-1-5-32-544)
A guarded script used the registered AUMID, Claude_pzs8sxrjxfjjc!Claude, for each launch. It stopped only packaged Claude.exe processes under C:\Program Files\WindowsApps\Claude_*. It did not target a separately installed Claude CLI.
The script did not invoke reinstall, re-registration, reboot, service-control, or package-payload commands. File contents were not exhaustively compared. The run did not record whether its shell was elevated.
Each phase used one scored AUMID launch and recorded whether Claude created a visible window. AppModel-Runtime events were collected from the phase start. The script wrote an atomic resume record before withdrawal and restored both entries in a finally block.
Findings
| Phase | Two-entry bundle | Window | AppModel-Runtime evidence |
|---|---|---|---|
| B1 baseline | present | opened in 1 second | Events 210, 211, and 201; process created |
| A2 withdrawal | absent | no window in 15 seconds | Event 208 twice; 0x80070005 at [LaunchProcess] |
| B2 reinstatement | present | opened in 1 second | Events 210, 211, and 201; process created |
After withdrawal, a read of the profile root showed only the current user’s inherited entries. The result recorded no visible-window PID at timeout. It did not record a final all-process census; the script then ran package-scoped cleanup before restoration. Event 211 shows that Windows added a process to the container during the failed phase, so “no process existed” would be too broad.
The relevant error was:
0x80070005: Cannot create the process for package
Claude_1.52386.6.0_x64__pzs8sxrjxfjjc because an error was
encountered while configuring runtime. [LaunchProcess]
The removal command reported 51 files processed and zero failures. Reinstatement reported 53 files processed and zero failures after the intervening launch attempt. Those are command summaries, not proof that every file’s DACL changed.
This is a second package on the same Windows installation, not independent replication. The ChatGPT/Codex sequence found that the same jointly changed treatment tracked launch outcome. Its earlier natural failure on version 26.901.6511.0 ended at [FinishPackageActivation]; its later controlled withdrawal on 26.908.4834.0 ended at [LaunchProcess]. The comparison supports a shared local intervention pattern, not a shared root cause or prevalence estimate.
Window close versus cold exit
A separate three-cycle close/reopen record tested this distinction without changing ACLs.
In all three cycles, sending window-close removed the visible window but left nine packaged Claude processes after 10 seconds. Window-close therefore did not exercise cold activation on this installation. The test then stopped only packaged Claude processes, confirmed that no packaged Claude processes remained, and launched the registered AUMID. All three cold launches produced a visible window in 1.02 to 1.05 seconds. Both tested root ACL entries remained present before close, after stopping those processes, and after launch.
This confirms that the B-A-B method exercised genuine zero-process starts. It does not show that window-close, a user-selected Quit action, or full process exit caused the ACL entries to disappear.
What this does not establish
Both package sequences were run on a single Windows installation, with both SIDs withdrawn and restored together, so this test does not establish prevalence, which trustee is individually necessary, or whether Full Control and recursive propagation are the minimum required permissions. Because the failed phase was induced by withdrawing the entries directly, the run does not show what originally removed them, whether ordinary window-close or an app update removes them, or why two comparator packages on the same machine worked without them.
The instrumented run also measured no visible window and Event 208 at [LaunchProcess] rather than reproducing the earlier interactive shell dialog. It does not explain separate Claude issue families involving install error 0x80073CF6, update locks such as 0x80073D02, or container sharing violations such as 0x80070020. The closed report claude-code#62200 contains the same user-facing dialog, but it was closed as outside Claude Code scope without this ACL test.
The team (the AI agents I direct) assisted with the investigation, instrumentation, and drafting. I authorized the reversal and remain responsible for what this report claims.
Read-only diagnostic and tested intervention
First confirm the exact dialog, an AppModel-Runtime Event 208 for the Claude package with 0x80070005, and Get-AppxPackage status Ok. A matching HRESULT alone is not sufficient. Inspect the per-user profile; do not modify C:\Program Files\WindowsApps.
$p = "$env:LOCALAPPDATA\Packages\Claude_pzs8sxrjxfjjc"
Get-AppxPackage -Name Claude |
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 one-machine result does not establish the command as a generally safe or minimum repair. It recursively adds inheritable Full Control entries for LocalSystem and the local Administrators group throughout Claude’s per-user profile. The experiment did not test either SID alone, narrower rights, rollback, another machine, or future updates. /C continues after errors, so inspect the completion summary.
Do not remove ACLs from a healthy profile to reproduce this result. Prefer an Anthropic-supported recovery path. An expert reproduction should first preserve a tested, restorable ACL backup and collect read-only state.
The command below documents the B2 intervention:
$p = "$env:LOCALAPPDATA\Packages\Claude_pzs8sxrjxfjjc"
icacls $p /grant "*S-1-5-18:(OI)(CI)(F)" "*S-1-5-32-544:(OI)(CI)(F)" /T /C
Vendor request
Please determine the supported ACL for Claude’s per-user package profile, why activation outcome on this machine changed with this jointly modified two-SID treatment, and whether installation, update, or activation should detect and recover from this state. Please expose the denied object, access mask, and principal in diagnostics. This run does not establish that both trustees, Full Control, or recursive propagation are required.
Data
The sanitized run record and three-cycle close/reopen audit contain the phase dates and sequence, ACL states, launch outcomes, processing counts, and relevant AppModel-Runtime events.
The public record redacts the computer and account names, user-profile path, and process IDs. Phase dates and sequence, ACL rights and inheritance, events, HRESULTs, outcomes, and command summaries are retained. The October 12, 2026 publication note records the removal of clock-time precision.
Author-run on one workstation on 2026-09-14. Package family Claude_pzs8sxrjxfjjc. Event source Microsoft-Windows-AppModel-Runtime/Admin, Event 208, 0x80070005, stage [LaunchProcess]. The final phase restored both entries and left Claude Desktop open.
Editorial update, September 23, 2026: clarified the summary and terminology. The methods, data, results and earlier correction record are unchanged.