### Preflight Checklist - [x] I have searched [existing issues](https://github.com/anthropics/claude-code/issues?q=is%3Aissue%20state%3Aopen%20label%3Abug) and this hasn't been reported yet - [x] This is a single bug report (please file separate reports for different bugs) - [x] I am using the latest version of Claude Code ### What's Wrong? Claude Desktop on Windows 11 regularly fails to launch. A dialog appears, titled with the package path: C:\Program Files\WindowsApps\Claude_1.44121.4

[BUG] Claude Desktop (Windows 11 25H2) fails to launch with misleading "Another program is currently using this file" — 0x80070020 Silo/Job failure with cowork-svc.exe in an SCM restart loop; only reboot recovers

Status Open

Maintainer reply None cached

Workaround ✓ Mentioned in description ↑

Activity 4 comments · opened Sep 3, 2026

Preflight Checklist

[x] I have searched existing issues and this hasn't been reported yet
[x] This is a single bug report (please file separate reports for different bugs)
[x] I am using the latest version of Claude Code

What's Wrong?

Claude Desktop on Windows 11 regularly fails to launch. A dialog appears, titled
with the package path:

C:\Program Files\WindowsApps\Claude_1.44121.4.0_x64__pzs8sxrjxfjjc

with the message "Another program is currently using this file."

The message is wrong on two counts.

There is no file lock. With the dialog still on screen, Resource Monitor →

CPU → Associated Handles searched for WindowsApps\Claude returns ZERO
results. Nothing holds a handle on that path.

The actual failure is container creation. Microsoft-Windows-AppModel-Runtime/

Admin logs 0x80070020 (ERROR_SHARING_VIOLATION) while converting the Job
Object into a Silo for the Desktop AppX container — EventIDs 215 and 208,
once per launch attempt.

The failing component is in a restart loop, not merely orphaned. cowork-svc.exe
is started by services.exe (the Service Control Manager) under CoworkVMService:

PID : 33620
Name : cowork-svc.exe
ParentPID : 1860
Parent : services
Started : 03-09-2026 12:48:06
Cmd : "C:\Program Files\WindowsApps\Claude_1.44121.4.0_x64__pzs8sxrjxfjjc\app\resources\cowork-svc.exe"

That start time falls between the container failures at 12:48:03 and 12:48:07 —
cowork-svc.exe dies, the SCM restarts it under service recovery policy, and the
restart hits the same 0x80070020. taskkill on the PID therefore cannot break
the cycle; the process reappears within seconds. This is why every published
workaround of the form "stop CoworkVMService and kill Claude.exe" is unreliable.

There is no Claude.exe process at any point — what Task Manager displays as
"Claude" is cowork-svc.exe grouped under the app name.

Only a Windows restart (or sign out / sign in) recovers the app. It then recurs,
roughly every update cycle.

Critically, the mitigation suggested in related threads — disabling
CoworkVMService — is NOT available to users. The service's ACL rejects
reconfiguration even from an elevated administrator prompt:

PS> Set-Service -Name CoworkVMService -StartupType Disabled
Set-Service : Service 'Claude (CoworkVMService)' cannot be configured due to
the following error: Access is denied

PS> sc.exe config CoworkVMService start= disabled
[Access is denied]

The only route that worked was writing the service's start type directly in the
registry:

Set-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Services\CoworkVMService" `
-Name Start -Value 4

Asking users to edit HKLM to keep the app launchable is not a reasonable
workaround.

Related: #53247 (same 0x80070020 Silo signature), #76357, #57221, #49655,
#50825 (also Windows 11 25H2), #36590.

What Should Happen?

Claude Desktop should launch without requiring a Windows restart or sign-out.

AppX container teardown should be reliable. When the app or cowork-svc.exe

crashes, the associated Silo/Job object should be cleaned up so the next
launch can create a fresh container.

cowork-svc.exe should not be restarted blindly into a known-failing state.

If container creation fails with 0x80070020, the service should stop retrying
and surface the condition rather than looping under SCM recovery.

The error message should reflect the real failure. "Another program is

currently using this file" sends users hunting for file locks that do not
exist. Surfacing the container-creation failure, with a "sign out and back in"
recovery hint, would save a great deal of time.

There should be a supported way to disable the Cowork VM service — a setting

in the app, or an ACL that permits an elevated administrator to use
Set-Service. Currently neither works and the registry is the only option.

Ideally, a chat-only fallback when the Cowork VM container cannot be created,

so the app remains usable instead of failing to launch entirely.

Error Messages/Logs

Microsoft-Windows-AppModel-Runtime/Admin:

TimeCreated : 03-09-2026 12:48:03
Id          : 215
Message     : 0x80070020: Cannot create the Desktop AppX container for package
              Claude_1.44121.4.0_x64__pzs8sxrjxfjjc because an error was
              encountered converting the job.

TimeCreated : 03-09-2026 12:48:03
Id          : 208
Message     : 0x80070020: Cannot create the process for package
              Claude_1.44121.4.0_x64__pzs8sxrjxfjjc because an error was
              encountered while configuring runtime. [LaunchProcess]

TimeCreated : 03-09-2026 12:48:06
Id          : 215
Message     : (same as above)

TimeCreated : 03-09-2026 12:48:07
Id          : 215
Message     : (same as above)

TimeCreated : 03-09-2026 12:48:07
Id          : 208
Message     : (same as above)

Package state is healthy — not a stuck upgrade:

PS> Get-AppxPackage *Claude* | Select Name, Version, Status, PackageFullName

Name   Version      Status PackageFullName
----   -------      ------ ---------------
Claude 1.44121.4.0      Ok Claude_1.44121.4.0_x64__pzs8sxrjxfjjc

The only process running from the package — parent is the SCM, started between
the two failure timestamps above:

PS> Get-CimInstance Win32_Process |
      Where-Object { $_.Name -like '*laude*' -or $_.Name -like 'cowork*' } | ...

PID       : 33620
Name      : cowork-svc.exe
ParentPID : 1860
Parent    : services
Started   : 03-09-2026 12:48:06
Cmd       : "C:\Program Files\WindowsApps\Claude_1.44121.4.0_x64__pzs8sxrjxfjjc\app\resources\cowork-svc.exe"

Service cannot be reconfigured, even elevated:

PS> Set-Service -Name CoworkVMService -StartupType Disabled
Set-Service : Service 'Claude (CoworkVMService)' cannot be configured due to the
following error: Access is denied
    + CategoryInfo          : PermissionDenied: (System.ServiceProcess.ServiceController:ServiceController) [Set-Service], ServiceCommandException
    + FullyQualifiedErrorId : CouldNotSetService,Microsoft.PowerShell.Commands.SetServiceCommand

PS> Get-Service CoworkVMService | Select Name, Status, StartType

Name             Status StartType
----             ------ ---------
CoworkVMService Stopped Automatic

Resource Monitor → CPU → Associated Handles, search "WindowsApps\Claude",
captured while the error dialog was displayed: no results.

Steps to Reproduce

Windows 11 25H2 (build 26200), Claude Desktop installed as MSIX.
Use the app normally, including Cowork sessions. At some point the app or

cowork-svc.exe crashes (non-deterministic; correlates with update cycles here).

Launch Claude Desktop from the Start menu.
Dialog appears — title is the WindowsApps package path, body reads "Another

program is currently using this file." The app never opens.

Inspect the event log:

Get-WinEvent -LogName Microsoft-Windows-AppModel-Runtime/Admin -MaxEvents 20 |
Where-Object { $_.Id -in 208,215 } |
Select TimeCreated, Id, Message | Format-List

EventIDs 215 and 208 with 0x80070020 are logged per launch attempt.

Confirm no file lock — resmon → CPU → Associated Handles →

search "WindowsApps\Claude" → zero results.

Observe the restart loop:

Get-CimInstance Win32_Process |
Where-Object { $_.Name -like 'cowork*' } |
Select ProcessId, ParentProcessId, CreationDate, CommandLine

Kill the PID; it reappears within seconds, parented to services.exe.

Does NOT resolve it:

Settings → Apps → Claude → Advanced options → Repair
Settings → Apps → Claude → Advanced options → Reset
Add-AppxPackage -Register (manifest re-registration)
net stop CoworkVMService
taskkill /F /IM Claude.exe (no such process exists)
taskkill /F /IM cowork-svc.exe (SCM restarts it)
Set-Service / sc.exe config to disable the service (Access is denied)

Resolves it:

Restart Windows (confirmed)
Sign out and sign back in (per #53247)

Prevents the loop re-establishing, but requires a registry edit:

Set-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Services\CoworkVMService" -Name Start -Value 4

Then recurs.

Claude Model

Not sure / Multiple models

Is this a regression?

I don't know

Last Working Version

_No response_

Claude Code Version

N/A — this is Claude Desktop, not the CLI. Claude Desktop 1.44121.4.0 (MSIX, x64), package Claude_1.44121.4.0_x64__pzs8sxrjxfjjc

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

PowerShell

Additional Information

Environment:
OsName : Microsoft Windows 11 Home Single Language
OsVersion : 10.0.26200
OsBuildNumber : 26200 (25H2)
Architecture : x64
Install type : MSIX (C:\Program Files\WindowsApps)

Frequency: recurs regularly, roughly every update cycle.
Impact: app is completely unusable until a Windows restart.

Summary of the three findings that may be new to the existing threads:

Zero associated handles on the package path while the "file in use" dialog

is displayed — the message is spurious.

cowork-svc.exe is restarted in a loop by services.exe (SCM), not merely

orphaned, so process-killing workarounds cannot succeed.

CoworkVMService cannot be disabled via Set-Service or sc.exe even from an

elevated prompt (Access is denied); only a direct HKLM registry edit works.

Screenshots of the error dialog, the empty Resource Monitor handle search, and
the PowerShell output above are attached.

View original on GitHub ↗

This issue has 4 comments on GitHub. Read the full discussion on GitHub ↗