Short answer: an update closed Claude, but some of the programs Claude had started for you - MCP servers, plugins, Claude Code tools - kept running. While they live, Windows considers the old version still in use and refuses to start the new one. No file is really locked. In order:
Never use Reset to get back in: it deletes Claude's data on this PC, and Repair or a sign-out does the job.
You open Claude Desktop from the Start menu or the taskbar, and Windows answers:
Another program is currently using this file.
C:\Program Files\WindowsApps\Claude_<version>_x64__pzs8sxrjxfjjc\app\Claude.exe
It usually starts right after Claude updated itself - overnight, or after you clicked Relaunch on the update notice - and it repeats on every attempt. Reinstalling changes nothing. Behind the message, Windows logs error 0x80070020.
A different message, saying Claude can't open and offering to Repair it, is a related but separate case: see below.
Claude Desktop for Windows is installed as a Windows app package, which Windows runs inside a container of its own. Updates follow this sequence:
node.exe, python.exe, uv.exe, bun.exe), a Claude Code helper (tail.exe), the Chrome extension bridge (chrome-native-host.exe).0x80070020 - a "sharing violation", which Windows translates as "another program is using this file".That explains why the usual moves fail: those leftover processes are not called Claude, so ending every claude.exe misses them. The detailed analysis is in Anthropic's issue tracker, #53247 and #42776 (open since April 2026, hundreds of comments).
What we measured ourselves. On 17 September 2026, after Windows forced a Claude update on our test PC, no launch worked for 25 minutes; Windows repaired the package twice on its own, without effect, and only a restart got Claude back. On 19 August, a similar block cleared by itself after about four minutes, because the update was still finishing.
Windows records each failed launch. In PowerShell:
Get-WinEvent -LogName 'Microsoft-Windows-AppModel-Runtime/Admin' -MaxEvents 3000 |
Where-Object { $_.Id -in 208,215 -and $_.Message -match 'Claude_' } |
Select-Object -First 5 TimeCreated, Id, Message
Events 215 and 208 mentioning 0x80070020 at the times you tried to open Claude: that is it.
Every failed launch makes Windows re-register Claude's package to repair it. That does not help, and it can interrupt an install that is still finishing. Wait two or three minutes, then try once. To see whether Windows is still installing:
Get-AppxPackage -Name Claude | Select-Object Name, Version, Status
Ok means the install is done: go to step 2. Anything else (Servicing, for example) means Windows is still working on it: wait a little longer.
List what could still belong to the old Claude:
Get-CimInstance Win32_Process |
Where-Object { $_.Name -match '^(claude|node|bun|uvx?|python|tail|chrome-native-host)\.exe$' } |
Select-Object ProcessId, Name, CommandLine | Format-List
End the ones Claude started: any claude.exe under WindowsApps, chrome-native-host.exe, and the node, python, uv, bun or tail processes whose command line names an MCP server, a .claude folder or Claude:
Stop-Process -Id 1234, 5678
Read before you end anything. The same names cover your own tools: a development server in a project folder, or Claude Code running in a terminal (its claude.exe sits under a claude-code folder, not WindowsApps). Ending all node.exe works for many people, but it also stops those.
Prefer clicking? Open Resource Monitor (resmon), tab CPU, type Claude_ in the Associated Handles search box, and end the processes it lists with a right-click.
Start menu → your account picture → Sign out, then sign in again. It closes everything the old version left in your session, and nearly every report in #53247 says it clears the block, in seconds. Save your work in other apps first.
The slowest, and the one that always works. If you want to know what held Claude before you restart, look at Resource Monitor as in step 2: afterwards, the evidence is gone.
claude.exe or cowork-svc.exe. The processes that matter have other names.Sometimes Windows marks Claude's package as needing repair after an update, and opening it shows a Windows message saying Claude can't open, with a Repair button. Try opening Claude once more first: on our test PC the mark stayed for three days while Claude kept running normally. If it really will not start:
Reset deletes everything Claude keeps on this PC: your sign-in, settings, MCP server configuration, and local Claude Code and Cowork data. Your chats live online and come back after you sign in; the rest does not. If you ever decide to reset anyway, copy %LOCALAPPDATA%\Packages\Claude_pzs8sxrjxfjjc\LocalCache somewhere safe first.
The block appears when an update closes a running Claude. When Claude shows that an update is ready, quit it completely (icon near the clock → Quit, not just the window's X), wait a minute, then open it again: the update installs while nothing of Claude is running.
Running several Claude profiles? Claude Desktop Manager recognizes this case instead of failing silently: when Windows closes Claude for an update, it says so and reopens your profiles once the update is done; while the update is still installing, it waits and retries by itself rather than piling up launch attempts; and if the block outlives the update, it tells you to restart instead of promising a launch that will not come.
🖥️ Windows app - download it from a PC. This page reads fine on a phone, but the installer only runs on Windows 10 / 11.
| What you see | What it means | What to do |
|---|---|---|
| "Another program is currently using this file" right after an update | The update may still be installing | Wait two or three minutes, try once |
The same, still there once the package says Ok | Leftover processes keep the old version alive | End them, or sign out and back in |
| Still there after a sign-out | Rare, but reported | Restart Windows |
| "Claude can't open" with a Repair button | Package marked as needing repair | Try once more, then Settings → Repair. Never Reset |
Because an update closed Claude while programs it had started - MCP servers, plugins, Claude Code tools - kept running. Windows then considers the old version still in use and refuses to start the new one with error 0x80070020. No file is actually locked.
Wait two or three minutes without clicking, then try once. If it still fails, end the leftover processes Claude started (node, python, uv, bun, tail, chrome-native-host), or sign out of Windows and back in, which clears it in under a minute. Restart Windows as a last resort.
It is a Windows sharing violation. Here it means Windows cannot create the container for the new version of Claude because the old version's container is still alive. Events 215 and 208 in the Microsoft-Windows-AppModel-Runtime/Admin log show it.
No. Signing out of Windows and back in does the same job much faster, and ending the leftover processes often avoids even that. Quitting Claude completely before an update installs makes the block less likely.
No. Windows handles an install over the top as an update and removes nothing, so whatever keeps the old version alive stays. Sign out and back in instead.
No. Reset deletes everything Claude keeps on this PC: sign-in, settings, MCP server configuration, and local Claude Code and Cowork data. Use Repair in Settings, Apps, Installed apps, Claude, Advanced options.
Free to download. Standard ($10, one-time purchase) runs two Claude windows at the same time with no time limit. Pro ($30, one-time) removes all limits and adds QuickPrompt and QuickAsk.
🖥️ Windows app - download it from a PC. The installer only runs on Windows 10 / 11.