Contents
- 1. Bottom line — sign out of Windows first to recover
- 2. Symptom — it appears when you launch after an update
- 3. The fix — what works and what doesn't
- 4. What the error really is — not a file lock (confirmed)
- 5. Two competing explanations, not yet settled
- 6. Check it on your own machine (PowerShell)
- 7. Different problems that are easy to confuse
- Summary
- FAQ
Right after you update Claude Desktop (Windows), trying to launch the app pops a dialog reading "Another program is currently using this file" and the app won't start — and it stays broken until you restart the PC. This is a known bug reported for the Microsoft Store (MSIX) build of Claude Desktop (GitHub #53247 and others).
Here's the bottom line first. A full PC restart isn't necessarily needed. In many cases just signing out of Windows and back in recovers it (not a PC restart, and not logging out of Claude). Below we separate what works, what doesn't, and what the error really is, split into confirmed / inferred / unconfirmed. This article is based on investigation logs from a single machine (Windows 11 Home, 10.0.26200) cross-checked against known GitHub issues.
⚠️ Confidence labels in this article: ✅ Confirmed = directly verified in machine logs or an issue / 🟡 Inferred = interpretation from circumstantial evidence / 🔴 Unconfirmed = not determined. We don't assert things we can't prove, such as "the cause is a file lock."
Recovery order to try first
1. Bottom line — sign out of Windows first to recover
The real damage from this bug is "can't launch," but recovering it doesn't necessarily require a full PC restart. Per the analysis in #53247, the "orphaned handle" behind the problem persists per Windows user session, so just signing out of Windows and back in clears it. Most people reflexively restart the whole PC, so this saves that time.
"Sign out" means Windows — not a PC restart, not logging out of Claude
The sign-out here is signing out of your Windows user account (Start → your user icon at the lower left → "Sign out"). Open apps close, but the PC does not power off, and it's faster than a restart. It is not logging out of the Claude app/account, and not relaunching the app — those don't fix it.
- ✅ Want it fixed now: sign out → sign in. Cases are reported where this lets the app launch again (#53247).
- ✅ Want it fixed for sure: restart the PC. Heavy, but reliable.
- ✅ Want to stop it recurring: drop the MSIX build and switch to the Squirrel (installer) build (below; per the #57221 reporter).
2. Symptom — it appears when you launch after an update
The typical sequence: after a Claude Desktop update is applied, opening the app shows a Windows Explorer-style dialog reading "Another program is currently using this file," and it won't launch. Closing and reopening does the same, and it doesn't recover until a PC restart (or a sign-out).
Crucially, the wording of this dialog does not accurately reflect what's happening (details in §4). Also, the update itself succeeded — what fails is not the update but "launching the app." This affects the Microsoft Store (MSIX) build of Claude Desktop.
3. The fix — what works and what doesn't
This is the biggest trap. Around the web you'll find claims like "stopping the service fixes it," but for this bug those are reported not to work. Let's cleanly separate what works from what doesn't.
- Sign out of Windows → sign in (fastest; a PC restart may be unnecessary)
- Restart the PC (reliable)
- Switch to the Squirrel build (permanent; prevents recurrence)
Stop-Service CoworkVMService(restarts and recurs)taskkillon all Claude/Cowork processesReset-AppxPackage/Add-AppxPackage -Register- Restarting AppXSvc, ClipSVC, vmcompute, etc.
The right-hand items are recorded as tried and failed in both #48003 and #53247. They tend to waste time, so it's rational to try signing out first.
Permanent fix: switch to the Squirrel (installer) build
If hitting this on every update is intolerable, the #57221 reporter states that uninstalling the MSIX build and switching to the installer (Squirrel) build resolved both the update and launch problems. The gist of the steps:
- Fully uninstall the Store (MSIX) build of Claude Desktop.
- Install the installer build from the official Claude download or via winget (e.g.
winget install Anthropic.Claude). - After that, auto-update brings it up to the latest version.
🟡 The rationale given is that it steps outside the constraints of C:\Program Files\WindowsApps and the AppX container layer. Behavior can differ by environment, so check your use case (enterprise distribution policy, etc.) before switching.
4. What the error really is — not a file lock (confirmed)
The dialog reads like "the file is in use," but in the machine logs the failure is elsewhere. The Microsoft-Windows-AppModel-Runtime/Admin event log records the following (✅ confirmed on the machine):
Event ID 215:
0x80070020: Cannot create the Desktop AppX container for package
Claude_..._x64__pzs8sxrjxfjjc
because an error was encountered converting the job.
Event ID 208:
0x80070020: Cannot create the process for package ... [LaunchProcess]
| Element | Meaning |
|---|---|
0x80070020 | ERROR_SHARING_VIOLATION. The code Windows generically renders as "the process cannot access the file because it is being used by another process." That's what the dialog really is. |
[LaunchProcess] | A launch failure, not an update failure (the update already succeeded). |
| Where it fails | Creating the Desktop AppX container — specifically the step that converts the Job Object into a Silo. |
And ✅ it has been verified that "no file lock exists." In #53247, checking with handle.exe and Process Explorer showed no user-space file lock. So "because another program is holding the file" is wrong, at least as a user-space lock. The real thing is a problem in the AppX/Desktop Bridge container layer (Job/Silo).
5. Two competing explanations, not yet settled
"A container-layer problem" is confirmed, but there are two views on the trigger, and it isn't settled. We avoid asserting one and present both.
The bundled CoworkVMService (SYSTEM account, auto-start) holds the package's Job Object and blocks the new package's container creation. On the machine, the error occurred in the same second as a service reinstall, consistent with this view (🟡 circumstantial).
If the Claude process crashes at startup, the kernel-side Silo/Job cleanup doesn't run and an orphaned handle remains. Subsequent launches then fail to convert the same package's job. The fact that signing out fixes it is consistent with this view.
Note the tension: if View A (service holding) were right, "stopping the service" should fix it — but it's reported not to (§3). Because of this contradiction, which one is primary isn't settled. 🔴 For now, presenting both is the honest stance.
Also, this symptom is confirmed across languages. The #53247 reporter is on a Portuguese environment, where the dialog reads "Há um outro programa usando este arquivo no momento" (another program is currently using this file) — the same symptom as the English/Japanese wording.
🔴 Status of an official fix: at the time of investigation, no official permanent fix has shipped. The central issue #53247 is still Open (no assignee). On the issue, permanent fixes are proposed — changing CoworkVMService from auto-start to on-demand (Manual), or moving the service binary out of WindowsApps — but they're at the proposal stage.
6. Check it on your own machine (PowerShell)
You can check whether your issue is the same as this article (no admin rights needed). If events 215/208 and 0x80070020 appear, it's the same problem.
Get-WinEvent -LogName 'Microsoft-Windows-AppModel-Runtime/Admin' |
Where-Object { $_.Message -match 'Claude' } |
Select-Object TimeCreated, Id, Message | Format-List
To cross-check against your update history, and to see the current settings of the bundled service:
Get-WinEvent -LogName 'Microsoft-Windows-AppXDeploymentServer/Operational' |
Where-Object { $_.Message -match 'Claude' } |
Select-Object TimeCreated, Id, LevelDisplayName, Message | Format-List
Get-CimInstance Win32_Service -Filter "Name='CoworkVMService'" |
Select-Object Name, StartMode, State, PathName
7. Different problems that are easy to confuse
Claude Desktop (Windows) has other bugs with similar-looking codes that are easy to confuse. They're distinct from this article's 0x80070020 (a launch failure), so keep them separate.
| Symptom | Code | Difference from this bug |
|---|---|---|
| This article: won't launch after update | 0x80070020 | — |
| The update fails (#49655) | 0x80073CF6 | An update failure, not a launch. Different code. |
| Reinstall stuck at "Servicing" (#51132) | 0x80073D28, etc. | A deployment stall. Different code. |
Also, when the Claude Code CLI (the claude.exe the desktop app manages) updates, you may see EPERM: operation not permitted, unlink ... claude.exe, but that is merely a failure to delete the old version — the new one installed fine — and is unrelated to this bug.
Summary
- ✅ Sign out of Windows → sign in first: recovery doesn't necessarily need a full PC restart (#53247). If that fails, restart the PC.
- 🔴 Stopping/re-registering the service is reported not to work: it tends to waste time, so avoid it.
- ✅ The real cause is not a "file lock": it's a failure in the AppX container layer (Job→Silo conversion). The dialog wording doesn't reflect reality.
- 🔴 The trigger has two unsettled explanations: service-holding (#57221) vs. startup-crash → orphaned-handle (#53247). No official fix yet.
- ✅ The permanent fix is switching to the Squirrel build: reported to resolve both update and launch problems (#57221).
This article is based on investigation logs from a single machine (Windows 11 Home, 10.0.26200) cross-checked against GitHub issues. Please use it knowing, honestly, that it may not reproduce identically for every user and that the fine details of the cause remain unsettled.
FAQ
Q1. What's the fastest way to fix it?
Sign out of Windows once and sign back in (Start → your user icon → "Sign out"). It's not a PC restart, and not logging out of the Claude app/account. Per #53247, the orphaned handle behind it persists per Windows user session, so a full PC restart may be unnecessary. If it still won't recover, restart the PC.
Q2. I saw "just stop the service" — does that work?
For this bug it's reported not to work (#48003, #53247). Stop-Service CoworkVMService restarts and the error recurs, and Reset-AppxPackage and restarting the various services didn't resolve it either. It's more rational to try signing out first.
Q3. Is the file really locked?
No. The dialog reads like "the file is in use," but verification (handle.exe / Process Explorer) confirmed no user-space file lock (#53247). The real thing is a failure in the AppX/Desktop Bridge container layer (Job Object → Silo conversion); the generic code 0x80070020 (ERROR_SHARING_VIOLATION) is simply rendered that way.
Q4. So what's the cause, in the end?
The container-layer problem is confirmed, but the trigger has two unsettled explanations: (1) CoworkVMService (auto-start) holding the Job Object (#57221), and (2) a startup crash leaving the Silo/Job cleanup undone so an orphaned handle remains (#53247). Since stopping the service doesn't fix it, which contradicts (1), it can't be stated definitively for now.
Q5. Is there an official fix?
At the time of investigation, no official permanent fix has shipped. The central issue #53247 is still Open. On the issue, permanent fixes such as changing the service to on-demand (Manual) start are at the proposal stage.
Q6. Does it happen on every update?
🔴 Can't be stated definitively. On the machine there was a sense of "it happens every update," yet the event log only showed it in 2 of 6 updates (older records may have rolled off the log's size limit, so it's undetermined). Frequency may vary by machine.
Q7. How do I stop it from recurring?
There's a report that dropping the MSIX (Store) build and switching to the Squirrel (installer) build resolved both the update and launch problems (#57221). You fully uninstall the Store build, then install the installer build from the official site or via winget. If you have constraints like an enterprise distribution policy, check first.
Related articles
- Claude Code "Response stalled mid-stream" error — cause and fix for another known error
- Claude Code "Output blocked" error — stopping on the content filter
