Claude Desktop “Windows cannot access” after close
On one Windows 11 PC, Claude Desktop visible cold-launch outcome and Event 208 tracked a two-SID profile ACL treatment in a B-A-B sequence.
Status: Result. Author-run B-A-B withdrawal and reinstatement on one machine and one Claude Desktop package. The run measured visible-window outcome and AppModel-Runtime events. It did not capture the Windows shell dialog, test whether ordinary closing removed the entries, or establish a mechanism.
Public tracking: anthropics/claude-code#94384. Anthropic’s support messenger is the official Desktop support channel; the GitHub issue is a public engineering record.
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.
This follows a sequence involving the same two-SID treatment on the ChatGPT Desktop package. It is same-host consistency across two packages, not independent replication. Host access control is one of the four failure modes tracked in the agent security research here.
If your failure includes this dialog and Event 208 with 0x80070005, compare it with the signature below, then start with the read-only diagnostic. Similar dialogs can arise from different HRESULTs and activation stages.
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 a zero-process fence, 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 the process fence, 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
This does not establish prevalence. Both package sequences were run on one Windows installation.
It does not show which SID is individually necessary. Both were withdrawn and restored together.
It does not establish that Full Control, recursive propagation, or both trustees are the minimum required treatment.
It does not show that ordinary window-close or full exit removed these entries. The failed controlled phase was induced by withdrawing them.
It does not reproduce the earlier Windows shell dialog inside the instrumented run. The run’s failed phase measured no visible window and Event 208 at [LaunchProcess].
This run does not show that absence of these entries is sufficient to break other packages. The linked ChatGPT/Codex article reports two working comparator packages without them on this machine.
It does not show what removed the entries or whether an app update will remove them again.
It does not explain the 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.
AI agents assisted the investigation, instrumentation, and writing. 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 /CThe 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 /CThis 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.
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 contains the phase timestamps, 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 timestamps, ACL rights and inheritance, events, HRESULTs, outcomes, and command summaries are retained.
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.