[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, now a repository so you can read the scripts before running them: https://github.com/leonidrysev/claude-cowork-fix — download: latest release.

The scripts warn first, wait for Enter (Закрыть и продолжить), then close Claude and Google Chrome before applying the update/repair flow. They handle CoworkVMService/AppX deployment locks, stop package-resident helpers such as chrome-native-host.exe, and relaunch Claude under the Cowork guard. If chrome-native-host.exe still remains or respawns after the automatic Chrome close, exit Chrome from the tray/background process and run the fix again.

Two notes that match reports in this thread:

• Because the fix intentionally leaves CoworkVMService Disabled + Stopped, Cowork may later say the VM service is not running. That is this state, not a new problem — run fix-restore-service.bat to put the service back on on-demand (Manual) start, which keeps Cowork working without re-locking the package at boot.
• After any relaunch, previously connected sessions do not re-enable Remote Control on their own (separate bug, #48949) — type /remote-control in each session you still need.

The previous attachment was stale and broken: two .ps1 files had non-ASCII strings saved without a UTF-8 BOM, so Windows PowerShell 5.1 mis-decoded them and the run died before writing a log. Fixed in v1.1.0.

For anyone stuck on this while it is open: the update fails because cowork-svc.exe holds a lock on files inside the package, so stopping the service first gets you past it.

# elevated
Stop-Service CoworkVMService -Force
Get-Process claude -ErrorAction SilentlyContinue | Stop-Process -Force

Then run the update.

One thing to know before you do that. On this build the service is configured AUTO_START, and it also carries an ETW start trigger on its named pipe:

sc.exe qtriggerinfo CoworkVMService

  START SERVICE
    CUSTOM  : 1f81d131-3e60-4c76-9860-37334e4ffce3 [ETW PROVIDER UUID]
      DATA  : \pipe\cowork-vm-service

That trigger is what starts it on demand when Claude asks for a workspace. After a manual stop I would not rely on it re-arming inside the same session, so if you stop the service and then decide not to update, start it again yourself before opening Claude:

Start-Service CoworkVMService

Otherwise Cowork can come up reporting that the VM service is not running, which sends you looking for a different problem than the one you created.

For disclosure, I maintain an unofficial toolkit for Cowork VM failures on Windows (ClaudeFix). Stop-ClaudeDesktop.bat does the above in order, including restarting the service into an idle state afterwards, which is the step that is easy to forget by hand.

None of this fixes the actual issue, which is that an application update should be able to shut down its own bundled service. It is just a way to get updated today.

Hit the same 0x80073CF6 -> 0x80073D05 chain on a reinstall, but in my case CoworkVMService wasn't running or even present (log showed Conflicting service: false, no Removing: step before AddPackage failed). Root cause traced to a different locked file under the same package family:
AppData\Local\Packages\Claude_pzs8sxrjxfjjc\LocalCache\Roaming\Claude\ChromeNativeHost\chrome-native-host.exe
held open by an active Chrome session (Claude for Chrome extension).
Stopping the process alone wasn't enough, Chrome just respawned it while the extension was still connected. What worked: uninstall the Claude for Chrome extension, use a lock-clearing tool (LockHunter) to release the file handle, then reboot so Windows could actually delete the folder. Reinstall succeeded cleanly after that.
Worth noting this is a second, independent trigger for the same failure mode, not tied to Cowork/Helium at all. Might be worth broadening the fix here to also stop chrome-native-host and prompt to close Chrome, separate from the CoworkVMService handling.
Windows 11 Pro, Claude Desktop 1.26832.0 (per ClaudeSetup.log).

1 week ago, I did all this, and it is not working.
Nothing Chrome-related running, either.

It's impressive that at PAID service with seemingly intelligent developers behind it CANNOT FIGURE OUT HOW TO ACTUALLY UPDATE AN APPLICATION.

Also, Claude Setup won't work for me unless I run it as administrator (makes sense though). The setup is NOT marked as requiring Administrator access.