[BUG] Claude Desktop update fails with 0x80073CF6 when CoworkVMService is running (Windows)

Found 3 possible duplicate issues:

1. https://github.com/anthropics/claude-code/issues/49540
2. https://github.com/anthropics/claude-code/issues/48437
3. https://github.com/anthropics/claude-code/issues/48426

This issue will be automatically closed as a duplicate in 3 days.

• If your issue is a duplicate, please close it and 👍 the existing issue instead
• To prevent auto-closure, add a comment or 👎 this comment

🤖 Generated with Claude Code

Hey i just did a workaround and it worked, hope it helps: https://github.com/anthropics/claude-code/issues/49917#issuecomment-4268321062

Confirming this is still happening on Claude Desktop 1.3561.0.0 (Windows 11 Home, Build 26200).

This has broken at least the last 4–5 updates in a row for me — both auto-update and the in-app update button. It's happened at least 5 times over the past ~3 months and, as best I can tell, every recent update has hit it; it doesn't feel intermittent, it feels like the default outcome. Each occurrence requires the reboot + manual Remove-Item recovery to get Claude Desktop back.

Two additional symptoms that might be useful for triage:

• After some broken updates, window-state.json retains coordinates from a previously connected secondary monitor (in my case y=-989). The Claude process launches and stays running, but the window is positioned off-screen and never becomes visible — looks like a crash from the user side.
• Multiple claude.exe processes spawn after a broken update. One of them logs Not main instance, returning early from app ready.

The Stop-Service CoworkVMService -Force + targeted process-kill workaround described above is a big improvement on what I've been doing (full reboot + manual Remove-Item of the Claude_pzs8sxrjxfjjc package directory). I'll try it on the next update.

Impact note: this has been frequent and disruptive enough that I built a small Claude Code skill on my end that automates the recovery dance (uninstall → wait → cleanup → reinstall) so I'm not doing it by hand each time. Mentioning it not to brag about a workaround but to flag that real users are spending real effort routing around this — happy to share the skill privately if it's useful for repro or for designing the fix.

I have AppXDeployment logs, Squirrel install logs, and main.log captures from multiple occurrences across versions. Happy to upload sanitized copies — let me know the preferred channel (attach here, gist, support ticket).

I hit what appears to be the same Windows update/file-lock failure and was able to isolate a reproducible workaround.

Observed behavior

On Windows, updating Claude Desktop can fail with the Windows dialog:

Another program is currently using this file.

This can happen even after the visible Claude window is closed.

Root cause observed locally

There were two separate lock sources:

1. CoworkVMService was still running from inside the MSIX package:

C:\Program Files\WindowsApps\Claude_1.8089.1.0_x64__pzs8sxrjxfjjc\app\resources\cowork-svc.exe

Restart Manager reported that CoworkVMService was actively using/locking its own package executable.

1. After stopping the service, Claude Desktop relaunched and multiple claude.exe child processes were again running from:

C:\Program Files\WindowsApps\Claude_1.8089.1.0_x64__pzs8sxrjxfjjc\app\Claude.exe

Those processes also keep the package locked and cause the same update failure.

Additional detail

CoworkVMService can be stopped, but cannot be disabled by a normal elevated Administrator shell:

sc.exe config CoworkVMService start= disabled

returns:

[SC] OpenService FAILED 5:
Access is denied.

So the practical workaround is not to disable the service, but to stop the service and terminate all running Claude package processes immediately before updating.

Workaround that succeeded

Run from PowerShell before starting the Claude update:

Stop-Service CoworkVMService -Force

Get-CimInstance Win32_Process | Where-Object {
  $_.ExecutablePath -like 'C:\Program Files\WindowsApps\Claude_*' -or
  ($_.Name -eq 'chrome-native-host.exe' -and $_.ExecutablePath -like "$env:APPDATA\Claude\*") -or
  $_.CommandLine -match '\\.claude\\|cowork-svc|ChromeNativeHost'
} | ForEach-Object {
  Stop-Process -Id $_.ProcessId -Force
}

Then verify nothing Claude-related remains:

Get-CimInstance Win32_Process | Where-Object {
  $_.ExecutablePath -like 'C:\Program Files\WindowsApps\Claude_*' -or
  $_.CommandLine -match '\\.claude\\|cowork-svc|ChromeNativeHost'
}

If that returns no Claude package processes, running the update immediately afterwards succeeds without logging out or rebooting.

Suggested installer-side fix

Before MSIX remove/add/register operations, the updater should terminate all processes running from the current Claude package directory, not only the visible desktop window and not only CoworkVMService. In particular:

• stop CoworkVMService
• wait for cowork-svc.exe to exit
• terminate all claude.exe processes whose executable path is under C:\Program Files\WindowsApps\Claude_*
• terminate the Claude native host if present under %APPDATA%\Claude
• re-check with Restart Manager before proceeding

This would avoid requiring users to log out/reboot just to release the MSIX package locks.

I scanned the public issue tracker for related Windows/MSIX/CoworkVMService update/file-lock reports. These look like the closest overlaps with this issue:

Same or very similar update/file-lock symptom

• #42776 — Windows relaunch fails with Another program is currently using this file; orphaned process holds WindowsApps executable lock.
• #45400 — Same relaunch/update failure; specifically calls out CoworkVMService / cowork-svc.exe holding locks under C:\Program Files\WindowsApps\Claude_*.
• #48787 — Stale WindowsApps package lock after closing/updating; reboot was the only reported recovery.
• #46179 — Windows Store update fails because CoworkVMService keeps running from the MSIX package folder; Stop-Service CoworkVMService -Force is required.
• #57221 — CoworkVMService AutoStart prevents MSIX updates/launches; service binary lives inside the package directory.
• #42897 — Auto-update leaves orphaned cowork-svc.exe / native-host processes; reboot needed to relaunch.
• #45896 — Stale file lock after in-app update requires reboot.
• #51847 — Repeated post-update Another program is currently using this file error.
• #60779 — Recent relaunch/update click fails with file-in-use / 0x80073CF6.

Same installer / package failure family

• #49917 — AddPackage HRESULT 0x80073CF6 after installer fails to remove old package/service; includes failed to remove conflicting service: could not open CoworkVMService: Access is denied.
• #48437 — MSIX installation fails with 0x80073CF6; log shows CoworkVMService already exists and Access is denied removing it.
• #48367 — Startup crash after update; reinstall logs show CoworkVMService removal denied and RemovePackage 0x80073CFA / AddPackage 0x80073CF6.
• #51578 — Window never appears; logs include same CoworkVMService access-denied and RemovePackage 0x80073CFA sequence.
• #60459 — 0x80073CF6 / 0x80073D28, suspected CoworkVMService artifact or partially-registered MSIX state.
• #51132 — MSIX stuck in Servicing/Staged; CoworkVMService blocks reinstall with access denied.
• #57744 — Similar Status: Servicing / 0x80073CFA / 0x80073D28 wedge; notes service may be a contributor but not always the only root cause.
• #60487 — Install/update fails with 0x80073D28; logs show CoworkVMService removal access denied and RemovePackage 0x80073CFA.

Root-cause-level related issue

• #57035 — Calls out the CoworkVMService DACL omitting normal admin/system management permissions, which explains why an elevated admin can stop the service but cannot disable/delete/reconfigure it (OpenService FAILED 5: Access is denied). This matches what I observed locally: Stop-Service CoworkVMService -Force works, but sc.exe config CoworkVMService start= disabled fails with access denied.

The recurring pattern across these is that the updater/installer needs to treat the packaged service and all package-scoped Claude processes as part of the update boundary:

1. stop CoworkVMService
2. wait for cowork-svc.exe to exit
3. terminate all claude.exe processes running from C:\Program Files\WindowsApps\Claude_*
4. terminate Claude native-host/helper processes if present
5. verify no Restart Manager lock holders remain before MSIX remove/add/register operations
6. avoid continuing to AddPackage if RemovePackage or service cleanup failed

Verified again after another update, run the following then launch Claude.exe:

1. Open a Windows Powershell / Terminal
2. Copy and paste the following
3. Then run Claude

Stop-Service CoworkVMService -Force

Get-CimInstance Win32_Process | Where-Object {
  $_.ExecutablePath -like 'C:\Program Files\WindowsApps\Claude_*' -or
  ($_.Name -eq 'chrome-native-host.exe' -and $_.ExecutablePath -like "$env:APPDATA\Claude\*") -or
  $_.CommandLine -match '\\.claude\\|cowork-svc|ChromeNativeHost'
} | ForEach-Object {
  Stop-Process -Id $_.ProcessId -Force
}

+1, just hit this again today (2026-05-27) on Windows 11 Pro 26200.7462. Auto-update to Claude Desktop 1.9255.0.0, app closed for the restart, never came back. "Another program is currently using this file." on every launch attempt after that. Reboot is still the only thing that gets it running again.

Second time this same failure hit me on update. First was 2026-05-21 on 1.8089.1.0, so it's persistent across at least two releases now, not a one-off bad build. I've still got the full AppXDeploymentServer log dump from the 05-21 occurrence (the 0x80073CF6 / 0x80073D05 / 0x800703FA sequence). Can attach it here if useful.

Yeah plus 1 million, claude is the only app to have this problem, clearly they did something silly and unusual that they did not have to.

Verified again after another update, run the following then launch Claude.exe: 1. Open a Windows Powershell / Terminal 2. Copy and paste the following 3. Then run Claude `` Stop-Service CoworkVMService -Force Get-CimInstance Win32_Process | Where-Object { $_.ExecutablePath -like 'C:\Program Files\WindowsApps\Claude_*' -or ($_.Name -eq 'chrome-native-host.exe' -and $_.ExecutablePath -like "$env:APPDATA\Claude\*") -or $_.CommandLine -match '\\.claude\\|cowork-svc|ChromeNativeHost' } | ForEach-Object { Stop-Process -Id $_.ProcessId -Force } ``

Unfortunately, this workaround stopped working for me on today's update.

> Verified again after another update, run the following then launch Claude.exe: > > 1. Open a Windows Powershell / Terminal > 2. Copy and paste the following > 3. Then run Claude > > `` > Stop-Service CoworkVMService -Force > > Get-CimInstance Win32_Process | Where-Object { > $_.ExecutablePath -like 'C:\Program Files\WindowsApps\Claude_*' -or > ($_.Name -eq 'chrome-native-host.exe' -and $_.ExecutablePath -like "$env:APPDATA\Claude\*") -or > $_.CommandLine -match '\\.claude\\|cowork-svc|ChromeNativeHost' > } | ForEach-Object { > Stop-Process -Id $_.ProcessId -Force > } > `` Unfortunately, this workaround stopped working for me on today's update.

Yes I'm still facing the issue even after doing this with update to 1.9659

+1, this has hit me on basically every update for the past few months. Windows 11 Pro build 26200, Claude Desktop 1.12603.1.0 (MSIX). Confirmed CoworkVMService running as an auto-start service on my machine. Until finding this issue, a full reboot was the only recovery that worked. Stopping CoworkVMService and killing the package-path processes before relaunching is now my pre-update routine.

Making sure this remains an active and open issue. Still experiencing this with version Claude 1.20186.0 (d7731e) 2026-07-09T06:13:11.000Z

This is super frustrating to have regular Claude updates that force a computer restart in order to continue using Claude, particularly when the client auto-updates. It takes me 20+ minutes to reconcile open operational work for clients and save open images and generally reprioritizes my work. I have a corporate image that, even with admin PowerShell, the workaround scripts do not run. I will be spending more time on the next reboot to remove Cowork entirely. Is Cowork useful? Yes, I use it periodically and would like to use it more but it is absolutely not worth the overhead of needing to reboot my machine with the frequent Claude updates.

Can we get a status update for activity related to this? If it is not a priority, then please explain that.

Best,
Mike

What is up with this mickey mouse BS? This has been going on for HOW long now? You can't fix auto-update in windows? Getting really really tired of it. Totally unacceptable.

> > Verified again after another update, run the following then launch Claude.exe: > > > > 1. Open a Windows Powershell / Terminal > > 2. Copy and paste the following > > 3. Then run Claude > > > > `` > > Stop-Service CoworkVMService -Force > > > > Get-CimInstance Win32_Process | Where-Object { > > $_.ExecutablePath -like 'C:\Program Files\WindowsApps\Claude_*' -or > > ($_.Name -eq 'chrome-native-host.exe' -and $_.ExecutablePath -like "$env:APPDATA\Claude\*") -or > > $_.CommandLine -match '\\.claude\\|cowork-svc|ChromeNativeHost' > > } | ForEach-Object { > > Stop-Process -Id $_.ProcessId -Force > > } > > `` > > > Unfortunately, this workaround stopped working for me on today's update. Yes I'm still facing the issue even after doing this with update to 1.9659

I am a little late, but https://github.com/anthropics/claude-code/issues/42776#issuecomment-4937945107 adding taskkill /f /im "node.exe" is the finishing move to fix it

It's insane that this is still a thing. The next update that gets pushed should be to fix this.

Windows workaround: claude-cowork-install-now-fix.zip

The scripts stop Claude processes whose executable path is inside the versioned WindowsApps package, including chrome-native-host.exe, handle the CoworkVMService/AppX deployment locks, and then relaunch Claude. If chrome-native-host.exe remains or respawns, close Chrome completely, including its tray/background process, and run the fix again.