[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.

Still affected on Windows 11 ARM64 — same root cause, unresolved for over a month and across multiple releases

I want to flag this plainly: I'm on the Max plan and the desktop app has been effectively unusable on my machine for over a month now. Confirming this install failure is the same root cause described in this issue.

The cycle I'm stuck in, over and over:

1. Desktop app crashes in the middle of a working session
2. After the crash it will not start again
3. To recover, the app has to be fully uninstalled
4. Reboot
5. Download and reinstall
6. Works for a while — then crashes mid-session again → back to step 1

An endless loop, for weeks.

Environment

• Windows 11 Core, version 10.0.26200, ARM64 (Snapdragon)
• Package: Claude_pzs8sxrjxfjjc
• Reproduced across versions 1.24012.9 and 1.26832.0 (latest desktop is now 1.34493.0)

Install failure — reproducible, log-backed

The pattern across ~10 install attempts is completely consistent:

• When the log shows Conflicting service: false → install succeeds
• When it shows Conflicting service: true (CoworkVMService still registered) → install fails with AddPackage failed with HRESULT 0x80073CF6

The relevant log lines every time it fails:

WARNING: CoworkVMService already exists (potential conflict)
WARNING: failed to remove conflicting service: could not open CoworkVMService: Access is denied.
...
MSIX installation failed: AddPackage failed: AddPackage failed with HRESULT 0x80073CF6

This happens even with Is elevated: true. The follow-up dialog says "Administrator access is required... You can try again or install without Cowork" — but in my build there is no "install without Cowork" button shown, only OK. So there is no supported way for me to avoid the failing component.

The only thing that lets an install succeed is a full reboot immediately before installing, so CoworkVMService isn't running yet. Any prior launch of Claude re-registers the service and re-locks the package, so the next install fails again. It's a loop.

Second problem — app crashes mid-session (cause unclear)

Separately from the install failure: even when installed successfully, the app crashes while Claude Code is actively running, and afterwards won't relaunch until reinstalled — which then hits the install failure above.

I want to be honest about this part: I can't confirm the cause of the runtime crash. No log is written to %LOCALAPPDATA%\Packages\Claude_pzs8sxrjxfjjc\LocalCache\Roaming\Claude\logs\ before it dies, and Windows Event Viewer shows no crash entry — only routine CoworkVMService start/stop. So I'm not claiming it's Cowork; I'm reporting that the app crashes with no diagnostic trail on ARM64.

Request

1. Have the installer force-stop CoworkVMService (and release the Helium registry locks) before AddPackage, per the fix already suggested in this thread — or actually surface a working "install without Cowork" path on ARM64.
2. Please look at why the desktop app produces no crash log on Windows ARM64. Without it, neither users nor support can diagnose the runtime crashes.

Support has acknowledged this as a known issue with no ETA and no workaround, and closed my ticket. For a paid Max subscription, having the core desktop app unusable on a supported platform for more than a month — stuck in a crash / uninstall / reinstall loop, with the only advice being "wait" — is not acceptable. I'd appreciate this being prioritized for ARM64.

A source-only workaround that now handles both the Cowork service path and the Chrome/native-host/package-hive path is available here:

https://github.com/leonidrysev/claude-cowork-fix

I verified it with a real update on Windows 11 Pro x64 build 26200: Claude Desktop updated from 1.32885.1.0 to 1.34493.0.0, Get-AppxPackage reported Status: Ok, Claude relaunched, and no reboot was required. The flow closes Claude and Chrome, removes the Cowork ETW respawn trigger, leaves CoworkVMService Disabled + Stopped, closes package-resident helpers, probes the Helium\User.dat hive before AppX registration, and has a guarded backup-first SYSTEM recovery path when that hive remains kernel-held.

The scripts are readable in the repository, !fix-install-now.bat --self-test is non-destructive, and no ZIP is distributed. Please try it if the normal updater still ends in 0x80073CF6, 0x80073D02, or 0x80070020, and attach the final lines of %TEMP%\cowork-install-now.log if it fails.

Important limitation for the ARM64 report above: my successful live verification was on x64. The scripts avoid hard-coded x64 package paths, but I have not yet validated the recovery flow on ARM64, so that platform is not claimed as confirmed.

Update: after 3 consecutive crashes on Windows 11 ARM64, removing the Claude in Chrome extension (chrome-native-host) stopped the crashing entirely. No crashes since. This may point at chrome-native-host as the crash trigger on ARM64.

Still reproducing after this was closed as completed on 27 Aug 2026.

Windows 11 IoT Enterprise LTSC 10.0.26200 build 26200 x64, Claude for Windows 1.44121.2.0, package family Claude_pzs8sxrjxfjjc.

Microsoft-Windows-AppXDeploymentServer/Operational event 658 has fired on every update since, four of them after the close:

03.09.2026 01:41:26  Marking package {Claude_1.44121.2.0} for deferred registration because {Claude_1.44121.1.0} is still running.
02.09.2026 17:38:08  {Claude_1.44121.1.0}  <- {Claude_1.40609.1.0}
01.09.2026 21:45:01  {Claude_1.40609.1.0}  <- {Claude_1.40609.0.0}
28.08.2026 20:14:02  {Claude_1.40609.0.0}  <- {Claude_1.37937.3.0}

Unbroken back to 03.08.2026 — 19 consecutive updates, none of them registered without a reboot.

The service is still installed as Auto start and still holds the package:

Name        : CoworkVMService
DisplayName : Claude
State       : Running
StartMode   : Auto
StartName   : LocalSystem
PathName    : "C:\Program Files\WindowsApps\Claude_1.44121.2.0_x64__pzs8sxrjxfjjc\app\resources\cowork-svc.exe"

Windows Restart Manager names it as a holder of the package files, alongside the 14 Claude.exe processes:

Id     Name    Service           Path
8480   Claude  CoworkVMService   ...\app\resources\cowork-svc.exe
14488  Claude                    ...\app\Claude.exe

Worth flagging for anyone else hitting this: ending cowork-svc.exe in Task Manager does not help, because StartMode is Auto and the Service Control Manager restarts it immediately. sc stop CoworkVMService from an elevated prompt does.

I never use Cowork, so an Auto-start LocalSystem service does nothing here except block every update.

Separately, three package versions are still on disk (1.32352.0.0, 1.34493.0.0, 1.44121.2.0) and event 1230 reports hardlinks into 1.32352.0.0 with no package in the repository, so the deferred registrations appear to be leaving stale packages behind.

Resolved for me on 2.2553.1