[BUG] Claude Code Desktop on windows errors when updating

I instrumented this on Windows 11 (10.0.26200) with the MSIX install and captured the modal five times across six consecutive updates. Posting the measurements here because this issue is the one carrying triage labels — #42776 has 162 reports but is labeled invalid, so the evidence there appears to be going nowhere.

Note on language: this machine runs Windows in pt-BR. Log lines are quoted verbatim because they are the evidence, with an English gloss in brackets.

The modal is a launch failure reported by the Windows shell

The window is owned by sihost.exe, and no process from the package is alive when it appears:

Window title : C:\Program Files\WindowsApps\Claude_1.46388.2.0_x64__pzs8sxrjxfjjc\app\claude.exe
Owner PID    : 8620
  Name       : sihost.exe          <- Shell Infrastructure Host
  Path        : C:\WINDOWS\system32\sihost.exe
  Parent     : svchost.exe

-- PROCESSES RUNNING FROM INSIDE THE PACKAGE --
  (none)

sihost.exe is what Windows uses to surface application launch errors. There is nothing left running from the package to hold the exe — so the "another program is using this file" text is misleading. The file isn't locked; the path stopped existing.

Timeline

App log plus Microsoft-Windows-AppXDeploymentServer/Operational, same second-by-second shape on every capture:

11:42:40  [stealth-update] Triggering stealth update after idle timeout
11:42:40  [stealth-relaunch] Saved z-order anchor: 0x1c0834
11:42:40  [stealth-relaunch] Saved navigation history (5 entries, active=4)
11:42:41  beforeQuitForUpdate handler fired, going down for update
11:42:41  Windows session ending (close-app) - quitting the app
11:42:42  [AppX 9627] "manifesto PackagedServiceDEH analisado com exito para remocao do pacote
                       Claude_1.44121.4.0_x64__pzs8sxrjxfjjc"
                      [PackagedServiceDEH manifest parsed successfully for package removal]
11:42:43  [AppX 400]  "Operacao de Register ... concluida com exito"
                      [Register operation completed successfully]
11:42:43  [AppX 472]  "Movendo pasta de pacote ...\Claude_1.44121.4.0... para
                       ...\WindowsApps\Deleted\Claude_1.44121.4.0..."
                      [Moving package folder ... to ...\WindowsApps\Deleted\...]
11:42:48  MODAL       (owner: sihost.exe)

stealth-relaunch saves restore state and the app exits. AppX replaces the package folder, moving the old one to WindowsApps\Deleted\. The relaunch then tries to start claude.exe by absolute path inside WindowsApps — the path AppX just moved — and the shell fails.

In the bundle the relaunch goes through app.relaunch({args}), which in Electron respawns via process.execPath, an absolute path. The same bundle already contains shell:AppsFolder\${e}, the package-identity launch form.

The intervals repeat, so this is deterministic

| Update | quit → Register | Register → modal | quit → modal |
|---|---|---|---|
| 1.40609.1 → 1.44121.2 | 2 s | 5 s | 7 s |
| 1.44121.2 → 1.44121.4 | 2 s | 4 s | 6 s |
| 1.44121.4 → 1.46388.2 | 2 s | 5 s | 7 s |
| 1.46388.2 → 1.46388.3 | 2 s | 6 s | 8 s |

It is not only the automatic relaunch

Seven minutes after one of those updates I caught a second modal with a different owner and no stealth-relaunch in the log at all:

Window title : ...\Claude_1.46388.2.0_x64__pzs8sxrjxfjjc\app\Claude.exe
Owner        : explorer.exe          <- not sihost.exe
Processes running from inside the package: (none)
main.log relaunch lines: nothing newer than the previous update

That was me launching the app from the shell after the failed relaunch. The launch triggered an AppX repair — a Register of the version already installed — and failed anyway. So a launch by absolute path fails from any initiator while the package is being serviced, and a user-initiated launch can itself trigger the servicing that breaks it.

Practical consequence: "wait for deployment to complete before relaunching" is not sufficient on its own. The launch form has to change.

What actually recovers the app, without a reboot

Launching through package identity works where the path does not. claude:// is registered by identity — HKCU\SOFTWARE\Classes\claude has URL Protocol and no shell\open\command, i.e. AppX activation — so a deep link survives the folder swap:

start claude://
explorer.exe "shell:AppsFolder\Claude_pzs8sxrjxfjjc!Claude"

Claude Code's own /desktop command uses the deep link, which is why it recovers the app when double-clicking does not. For the many people in #42776 rebooting or signing out: try this first. It is also independent evidence for the fix below.

Suggested fix

1. Primary: when the install identity is MSIX, relaunch via shell:AppsFolder\<AUMID> rather than app.relaunch(). The AUMID is stable across package versions; the physical WindowsApps\<version> directory is not (Third Rule of MSIX). The identity form is already in the bundle.
2. Complement: wait for deployment completion before relaunching — necessary but, per the capture above, not sufficient.
3. Suppress the modal when the update actually succeeded. It reports failure for an operation that completed.

Ruled out here, with evidence

| Suspect | Why not |
|---|---|
| Orphaned process holding a file lock (the premise of #42776) | No process from the package was alive in any of the five captures. Nothing is holding the file. |
| Orphaned node.exe holding the Claude Code scratchpad | Checked: 92 node.exe processes, 2 orphans, neither touching %LOCALAPPDATA%\Temp\claude. Not applicable on this machine. |
| CoworkVMService holding the folder | AppX logs 0x0: êxito de TerminateSingleService ... no pacote CoworkVMService and êxito no encerramento do serviço [TerminateSingleService succeeded / service shutdown succeeded]. Windows terminates the packaged service correctly. |
| MSIX deployment failure | Zero Error/Warning events for the package in any capture window; Register completes; Get-AppxPackage reports the new version. |
| Antivirus | Defender passive, zero detections, zero 1116/1117 events. McAfee present only as WebAdvisor + firewall. |
| Third-party package patcher | "Multi Instance for Claude Desktop" uninstalled; the modal returned on the next update with it gone. |

A separate, real defect in CoworkVMService — and please look at the workaround being shared

Not the cause of the modal, but a genuine bug in the same component, and the community fix for it is unsafe.

The service cannot configure its own SCM recovery actions. Logged on every start — six times in one day here — and sc.exe qfailure CoworkVMService confirms the config is empty (RESET_PERIOD 0, no actions):

Claude VM Service: failed to configure SCM recovery actions; if the service crashes it will
not restart until the machine reboots: open service: Acesso negado.   [Access is denied]

It also cannot disarm them on stop:

Claude VM Service: failed to disarm SCM recovery actions for this stop; if the stop overruns,
the service may be auto-restarted during package servicing: open service: Acesso negado.

Both fail, so today they cancel out. But people in #42776 are now arming the recovery actions externally with sc.exe failure CoworkVMService reset= 86400 actions= restart/5000/.... Since the app still cannot disarm them, the next update's service stop can overrun and SCM will restart cowork-svc.exe during package servicing — creating exactly the live in-package process the "orphaned file lock" reports describe. The app's own log is effectively steering users toward a change that can make their installation worse.

Either grant the service the rights for both operations, or attempt neither.

One note on the ClaudeSetup.exe --exe workaround

It is circulating as a fix: force the legacy Squirrel install, get no CoworkVMService and no WindowsApps, and the problem disappears. That is a real escape hatch, but it costs Cowork entirely — for anyone who uses Cowork daily it is not an option. Worth knowing that the workaround being recommended trades away a shipped feature.

Frequency

Two updates landed within three hours on 2026-09-04, each costing a sign-out/sign-in. The updater logged Using GrowthBook check_interval_ticks=1 (default 4), so the check interval is being turned down server-side. Whatever the intended cadence, this defect now fires several times a day for some of us.

Occurrences on this machine: 2026-08-28, 09-01, 09-02, 09-03, and twice on 09-04. Six of six updates. Happy to share the full capture log or the watcher script.

Still happening on my end (Windows, Claude Desktop) — cowork-svc.exe holds a lock even after killing all Claude-related processes via Task Manager (Details tab, not just Processes). Has anyone found a reliable workaround that doesn't require a reboot every time?

<img width="694" height="267" alt="Image" src="https://github.com/user-attachments/assets/6c09aa5f-5a5e-428b-992d-0b648e2e60c0" />

@Talelor I'm suffering from this too, random crashes and then unable to start Claude. I've found that killing git.exe processes allows Claude to restart without requiring a system reboot.

There is a lot of valuable data on #42776 that someone who's going to fix this might need...