[BUG] Claude Code Desktop fails to Relaunch on Windows due to orphaned process file lock

I have the same experience after every update of the Claude desktop app.

<img width="357" height="132" alt="Image" src="https://github.com/user-attachments/assets/edfff0e6-7d09-4f8e-9ec7-3c859a637973" />

I have the same problem now. It previously worked normally. Happened after I Relaunched the app from the update prompt.

<img width="356" height="126" alt="Image" src="https://github.com/user-attachments/assets/331041e9-bb68-47ba-9968-a4424d4e203a" />

same issue for me -- after latest update

Seems Windows restart is the only solution atm

What seemed to fix it for me was using Claude Code in terminal. I've used it in two terminals to do some work, then tried opening the desktop app again and this time it worked.

same for me, as of yesterday

I've got the same issue and have for a while.

have the same issue. killed the .net host in task manager and now its working again

Yes, this is a regression. Has been happening for the past week.

1. Killing claude.exe instances doesn't help.
2. Killing cowork-svc.exe doesn't help

Only reboot has helped so far. This is bad. It'll make me avoid updates cause I'm not going to be rebooting every time this app pushes an update.

Joining the fun - same problem happening here.

have the same issue. killed the .net host in task manager and now its working again

I was running .net apps as well. likely a connection

Just updated to ver. 1.1348.0.0 and the relaunch worked

Also joining the party, same issue, really annoying, restart is the only thing that helps...

same here!

same here

same issue.. needs restart.

It looks like it's been resolved and is working as usual for the app version (not Claude Code): 1.1617.0.0

Adding details from #46179 — the specific process holding the lock is CoworkVMService (cowork-svc.exe).

Why it won't die: The service has StartupType = Automatic with auto-recovery. Even if the main app signals beforeQuitForUpdate, the service keeps running and auto-restarts if killed. It runs from inside the MSIX package folder (C:\Program Files\WindowsApps\Claude_*\app\resources\cowork-svc.exe), so it holds a lock on the exact files the Store needs to replace.

Fix suggestion: The updater should call Stop-Service CoworkVMService (or equivalent via SCM API) before attempting package replacement, then restart it post-update. This is the standard pattern for MSIX apps with companion services.

Scope: This affects every Windows Store/MSIX user on every update. The workaround requires admin PowerShell (Stop-Service CoworkVMService -Force && Set-Service CoworkVMService -StartupType Disabled), which most users won't know to do.

Related: #46179, #45400 (closed as dup of this)

Same issue

Same problem

Adding details from #46179 — the specific process holding the lock is CoworkVMService (cowork-svc.exe). Why it won't die: The service has StartupType = Automatic with auto-recovery. Even if the main app signals beforeQuitForUpdate, the service keeps running and auto-restarts if killed. It runs from inside the MSIX package folder (C:\Program Files\WindowsApps\Claude_*\app\resources\cowork-svc.exe), so it holds a lock on the exact files the Store needs to replace. Fix suggestion: The updater should call Stop-Service CoworkVMService (or equivalent via SCM API) before attempting package replacement, then restart it post-update. This is the standard pattern for MSIX apps with companion services. Scope: This affects every Windows Store/MSIX user on every update. The workaround requires admin PowerShell (Stop-Service CoworkVMService -Force && Set-Service CoworkVMService -StartupType Disabled), which most users won't know to do. Related: #46179, #45400 (closed as dup of this)

Even after setting this, it seems Claude sets the service to Automatic again and does the same behaviour.

Only way to resolve this issue, is to uninstall, reboot and then install again.

Killing node.js javascript runtime seemed to get it to work for me. Still happening with the latest version.

It looks like it's been resolved and is working as usual for the app version (not Claude Code): 1.1617.0.0

Haven't hit this as well on last update. Good!

latest update today did it again. I killed the Node.Js Process from task manager and that allowed me to open claude without a restart

latest update today did it again. I killed the Node.Js Process from task manager and that allowed me to open claude without a restart

Killing node worked for me as well

have the same issue. killed the .net host in task manager and now its working again

This worked! @Lewdcifer666 how did you know this was the culprit?

> have the same issue. killed the .net host in task manager and now its working again This worked! @Lewdcifer666 how did you know this was the culprit?

Just a wild guess. I opened task manager and saw this at the top of the list and thought hmm weird and killed it. Then the next update the same thing happened and i saw it again, killed it and yup sure enough that was the culprit, at least for me.

Also happened to me. I didn't have a .net host open, so there was nothing for me to kill on that front. I had a bunch of node.js, and killed all of them and that did not help at all. I was fine until today, but today is the second update I've had on windows 11. Was on windows 10 until yesterday. The first update on windows 11 restarted fine.

Confirming I have the same issue... this has been going on awhile. I reinstalled claude and lost my cowork and code chat histories in the dekstop app yesterday too which I didnt realize I would lose and was annoying. Super frustrating as now I dont want to update or have to restart everytime

In my case the problem was different:

winget install Microsoft.Sysinternals.Handle
handle.exe Claude

I saw that Claude was held by bun.exe and python.exe so I killed them both:

taskkill /IM bun.exe /F
SUCCESS: The process "bun.exe" with PID 36008 has been terminated.
SUCCESS: The process with PID 5212 has been terminated.
PS C:\Users\mirko> taskkill /IM python.exe /F
ERROR: The process "python.exe" not found.

And then Claude finally restarted.

This happens consistently on every IDE relaunch after updates 7/7 times. The orphaned process pattern is reproducible:
IDE update → shutdown → relaunch → file lock error.

Had the same issue also.

The fix that work for me is after getting the error:

1. Click "Ok" on the error window to close it.
2. Open task manager
3. Go to Services tab
4. Search for "claude"
5. Restart the CoworkVMServices,

In my case the problem was different: `` winget install Microsoft.Sysinternals.Handle handle.exe Claude ` I saw that Claude was held by bun.exe and python.exe so I killed them both: ` taskkill /IM bun.exe /F SUCCESS: The process "bun.exe" with PID 36008 has been terminated. SUCCESS: The process with PID 5212 has been terminated. PS C:\Users\mirko> taskkill /IM python.exe /F ERROR: The process "python.exe" not found. `` And then Claude finally restarted.

Same for me. Also, this "Handle" is very useful. Thanks!

Open task manager and Close these processes

Claude.exe
Bun.exe
Python.exe

then turn off CoworkVMServices on the services tab in tasks manager

Handle

Thank you! Installed and ran handle, and for me four git to be the culprit. Killed it and was back in business.

it seems that any process that Claude starts up while its running locks it. I have had these cause the issue:

Node.JS
Bun
Tail.exe
python

same here, and no amount of killing the process or .net or using powershell to stop the workspace process fixed it.

had to bring the entire machine to a full reboot.

absolutely not stoked. if this happens again i will uninstall and never reinstall this app.

there is no way a simple desktop app should ever ever require a restart to release a file lock. Completely broken design

This just happened to me after clicking the UPDATE button... lol

Same issue i killed everything still same cannot open claude its keep giving same error

This happened again after the latest update; no amount of killing processes or stopping services solves this, a full reboot is required.

Killing node.exe (instead of bun.exe) fixed this in my environment.
taskkill /IM node.exe /F

Note that I had been developing a Vite project using Claude Code on Claude Desktop application prior to upgrading. The development server (vite dev) invoked by the Claude Code in the background, may still have been running at that time, causing a file lock by node.exe.

Same thing has happened to me for the last couple updates. Only solution is a full reboot with a full re-install. It makes the updates more of an annoyance than a thing to look forward to.

same for me, but when i kill all node.js processes its started :D

Same here, happened twice today because ... two updates for some reason. I don't know why I keep pressing that Re-launch button, grrr!

Yep happened again, twice in a row. Two days in a row. Fresh install, too.

node.exe and bun.exe are not running. Force quitting the service or the running process also does nothing. It is actually seriously legitimately really truly broken

broken, nothing in this thread fixes it either.

Funny thing is, you could have used Mythos etc to fix it:

Cause
What we observed exactly was:

Claude downloaded the MSIX update, then logged beforeQuitForUpdate handler fired.
Windows AppX logs showed the update had been deferred while Claude was still running.
On relaunch, Windows repeatedly logged AppModel Runtime errors 208 and 215 with 0x80070020, which is a sharing violation: Windows could not create the new Claude Desktop AppX container.
At the same time, Windows was auto-installing and starting Claude’s packaged CoworkVMService from ...\app\resources\cowork-svc.exe as LocalSystem.
The strongest conclusion from the logs is that the glitch was in Claude’s cowork / local-agent VM subsystem, not the main Electron shell. A stale packaged service/runtime state survived the MSIX update boundary, so the new package could not relaunch until that state was cleared. Rebooting fixed it because reboot forcibly tears down that service/VM state; our repair script now does the same thing surgically.

Here's a powershell script. Needs elevated permissions.

repair_claude_update.txt

Spun right back up for me. It's a modern software miracle. No reboot needed

Here's a reliable workaround using Sysinternals handle.exe to identify and kill only the processes actually holding a lock on Claude — without nuking unrelated Node/Python processes you may have running for development work.

1. Install handle.exe (one-time)

winget install Microsoft.Sysinternals.Handle

After install, open a new PowerShell window so handle.exe is on your PATH. The first time you run it, accept the Sysinternals EULA:

handle.exe -accepteula

2. Diagnose (optional, to see what's actually holding the lock)

handle.exe Claude

This lists every process with an open handle matching Claude. In my case it was bun.exe (MCP server runtime) — yours may be node.exe, python.exe, uv.exe, etc. depending on which MCP servers you've configured.

3. Run this PowerShell snippet to surgically kill only the lock holders

# Parse handle.exe output to kill only processes holding Claude locks
handle.exe -nobanner Claude | Select-String 'pid:\s*(\d+)' | ForEach-Object {
    $targetPid = $_.Matches[0].Groups[1].Value
    Write-Host "Killing PID $targetPid"
    Stop-Process -Id $targetPid -Force -ErrorAction SilentlyContinue
}

Important: use $targetPid (or any other name) rather than $pid — $pid is an automatic PowerShell variable holding the current shell's PID and is read-only; assigning to it throws an error.

After the snippet finishes, Claude Desktop launches normally.

Why this fixes it

• handle.exe Claude enumerates every process in the system with a handle whose name contains Claude — i.e., the exact processes blocking the executable.
• Parsing the pid: field and piping to Stop-Process -Force terminates only those PIDs, leaving the rest of your environment intact. This matters if you're a developer with Node/Python/Bun processes running for unrelated work (dev servers, watchers, etc.) — a blanket taskkill /IM node.exe /F would take those down too.
• Because the handles are released, the next Claude launch no longer hits the file lock and the MSIX loader can open the executable normally.

Permanent-ish convenience

Save the snippet as Restart-Claude.ps1 and create a shortcut that runs:

powershell.exe -ExecutionPolicy Bypass -File "C:\path\to\Restart-Claude.ps1"

Until the underlying child-process-cleanup bug is fixed upstream, this is a clean, non-destructive recovery path.

+1, ongoing. workarounds are not valid long term.

Here's a reliable workaround using Sysinternals handle.exe to identify and kill only the processes actually holding a lock on Claude — without nuking unrelated Node/Python processes you may have running for development work. ### 1. Install handle.exe (one-time) winget install Microsoft.Sysinternals.Handle After install, open a new PowerShell window so handle.exe is on your PATH. The first time you run it, accept the Sysinternals EULA: handle.exe -accepteula ### 2. Diagnose (optional, to see what's actually holding the lock) handle.exe Claude This lists every process with an open handle matching Claude. In my case it was bun.exe (MCP server runtime) — yours may be node.exe, python.exe, uv.exe, etc. depending on which MCP servers you've configured. ### 3. Run this PowerShell snippet to surgically kill only the lock holders # Parse handle.exe output to kill only processes holding Claude locks handle.exe -nobanner Claude | Select-String 'pid:\s(\d+)' | ForEach-Object { $targetPid = $_.Matches[0].Groups[1].Value Write-Host "Killing PID $targetPid" Stop-Process -Id $targetPid -Force -ErrorAction SilentlyContinue } Important: use $targetPid (or any other name) rather than $pid — $pid is an automatic PowerShell variable holding the current shell's PID and is read-only; assigning to it throws an error. After the snippet finishes, Claude Desktop launches normally. ### Why this fixes it handle.exe Claude enumerates every process in the system with a handle whose name contains Claude — i.e., the exact processes blocking the executable. Parsing the pid: field and piping to Stop-Process -Force terminates only those PIDs, leaving the rest of your environment intact. This matters if you're a developer with Node/Python/Bun processes running for unrelated work (dev servers, watchers, etc.) — a blanket taskkill /IM node.exe /F would take those down too. Because the handles are released, the next Claude launch no longer hits the file lock and the MSIX loader can open the executable normally. ### Permanent-ish convenience Save the snippet as Restart-Claude.ps1 and create a shortcut that runs: `` powershell.exe -ExecutionPolicy Bypass -File "C:\path\to\Restart-Claude.ps1" `` Until the underlying child-process-cleanup bug is fixed upstream, this is a clean, non-destructive recovery path.

Doesn't work for me. For me it wasn't a stray bun.exe/node.exe/python.exe process literally holding some open handle on a claude path.

What was (and continues to be) required in my case was:

explicitly stopping the packaged service
rotating stale runtime state like vm_bundles and ChromeNativeHost
validating the config JSON
preserving and not disturbing Claude Code session stores

so yeah, the caveat is that "handle.exe Claude" matches stuff with names containing Claude, which is useful in some cases maybe, but not perfect and didn't solve my problem. It missed the real cause for me b/c the problematic lock is indirect and service-managed, i.e. not exposed under a path name that matches the search string with simple process kills.

The auto-updater is not properly scanning for lock handles before initiating application relaunch.
I had processes that Claude spawned that were running from the Claude package folder.

1. Start Resource Monitor (resmon from RUN)
2. Go to CPU tab
3. Search for Claude in Associated Handles
4. Find and kill ELIGIBLE child processes.
5. Start Claude once done.

<img width="1207" height="912" alt="Image" src="https://github.com/user-attachments/assets/dd99c63e-0ce1-4423-a55f-d174f113e683" />

Having the same problem, non of the temp fixes shared here fixed it for me

I hear you but this shouldn't be happening to begin with. I get a lot of
workarounds but I want a real fix pushed to Claude lol

All the best,

Shaya Kutnowski

On Wed, Apr 22, 2026, 6:43 p.m. Atoki @.***> wrote:

carterlist left a comment (anthropics/claude-code#42776) <https://github.com/anthropics/claude-code/issues/42776#issuecomment-4297669828> The auto-updater is not properly scanning for lock handles before initiating application relaunch. I had processes that Claude spawned that were running from the Claude package folder. 1. Start Resource Monitor (resmon from RUN) 2. Go to CPU tab 3. Search for Claude in Associated Handles 4. Find and kill ELIGIBLE child processes. 5. Start Claude once done. image.png (view on web) <https://github.com/user-attachments/assets/dd99c63e-0ce1-4423-a55f-d174f113e683> — Reply to this email directly, view it on GitHub <https://github.com/anthropics/claude-code/issues/42776?email_source=notifications&email_token=ABHZPPW76VMXUYREOMUSCID4XDSDPA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTIMRZG43DMOJYGI4KM4TFMFZW63VHMNXW23LFNZ2KKZLWMVXHJLDGN5XXIZLSL5RWY2LDNM#issuecomment-4297669828>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABHZPPVO3HFXBTZAZCV2FN34XDSDPAVCNFSM6AAAAACXLA33VSVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHM2DEOJXGY3DSOBSHA> . You are receiving this because you commented.Message ID: @.***>

Claude is the most popular vibe-coded app in the world. Brace yourselves for more bugs and security issues. It's practically inevitable.

<img width="352" height="125" alt="Image" src="https://github.com/user-attachments/assets/c4b18147-3bfd-425a-9593-23004ac64e7f" />

please fix this already!

In my cases, it was handles on Claude being held open by Rider and PyCharm that was causing me issues and a cowork.exe that had some file handle open to ProgramData/Claude/Logs/cowork-service.log. Killed them and Claude then started

Tried everything in this thread, only a full reboot helps.

Killing node processes worked for me. I'm not sure which one was causing the issue, but after clearing them I was able to reopen Claude Desktop. I even did another update right after that and it worked fine.

Tried everything, only a full reboot helps.
I was not even able to re-install.

After installation, Windows Apps showed version 1.5354.0.0 under C:\Program Files\WindowsApps, and that directory appeared to be locked.

Before rebooting, I also tried updating Git as well.
The Git installer reported that tail.exe and grep.exe were blocking the installation.
I manually ended both processes in Task Manager, and Git then installed successfully.

This made me suspect that Claude Code may have been holding these tools open,
since I mainly use Claude Code through Claude Desktop App.
After that, I tried opening Claude Desktop App again,
and the previous “Another program is currently using the file.” error disappeared.
Claude Desktop App now opens successfully.

The displayed version is 1.5354.0 (9A9E3D) in app,
matching the locked Windows Apps' version.

Hope this may help with debugging.

from @LehiThomas ...

Killing node processes worked for me. I'm not sure which one was causing the issue, but after clearing them I was able to reopen Claude Desktop. I even did another update right after that and it worked fine.

100% worked for me as well, thanks for calling that out

It can be a variety of processed that keep it locked out. I've had to kill one or more of the following-

dotnet
cowork-*
cmd
python
node

full reboot always works as a last resort.

Full reboot is my first resort I don't have 30+ mins to troubleshoot why
stuff doesn't work. 😂

All the best,

Shaya Kutnowski

On Wed, Apr 29, 2026, 4:48 p.m. setiri @.***> wrote:

setiri left a comment (anthropics/claude-code#42776) <https://github.com/anthropics/claude-code/issues/42776#issuecomment-4344336352> It can be a variety of processed that keep it locked out. I've had to kill one or more of the following- dotnet cowork- cmd python node full reboot always works as a last resort. — Reply to this email directly, view it on GitHub <https://github.com/anthropics/claude-code/issues/42776#issuecomment-4344336352>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABHZPPXQASU5RKJKTHUZR634YIB35AVCNFSM6AAAAACXLA33VSVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHM2DGNBUGMZTMMZVGI> . Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>. You are receiving this because you commented.Message ID: @.**>

Git

have the same problem when updating git for windows, while having Claude Code on.

After installation, Windows Apps showed version 1.5354.0.0 under C:\Program Files\WindowsApps, and that directory appeared to be locked. Before rebooting, I also tried updating Git as well. The Git installer reported that tail.exe and grep.exe were blocking the installation. I manually ended both processes in Task Manager, and Git then installed successfully. This made me suspect that Claude Code may have been holding these tools open, since I mainly use Claude Code through Claude Desktop App. After that, I tried opening Claude Desktop App again, and the previous “Another program is currently using the file.” error disappeared. Claude Desktop App now opens successfully. The displayed version is 1.5354.0 (9A9E3D) in app, matching the locked Windows Apps' version. Hope this may help with debugging.

Finally! I have looked into this so many times, and never found an answer, but THIS was it for me!

tail.exe - killing this from the Task Manager fixed it for me! 🙏

Can confirm - tail.exe hangs (many, many copies), killing all one by one fixes the issue.

confirming here too, I had a single tail process running, and killing it fixed it.

What is the tail.exe process anyway?

All the best,

Shaya Kutnowski

On Thu, May 7, 2026, 9:13 p.m. Thomas Zarebczan @.***>
wrote:

tzarebczan left a comment (anthropics/claude-code#42776) <https://github.com/anthropics/claude-code/issues/42776#issuecomment-4399856859> confirming here too, I had a single tail process running, and killing it fixed it. — Reply to this email directly, view it on GitHub <https://github.com/anthropics/claude-code/issues/42776#issuecomment-4399856859>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABHZPPVX4LABYNUB64V46OL4ZTG5FAVCNFSM6AAAAACXLA33VSVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHM2DGOJZHA2TMOBVHE> . You are receiving this because you commented.Message ID: @.***>

What is the tail.exe process anyway? All the best, Shaya Kutnowski On Thu, May 7, 2026, 9:13 p.m. Thomas Zarebczan @.***> wrote: > tzarebczan left a comment (anthropics/claude-code#42776) > <https://github.com/anthropics/claude-code/issues/42776#issuecomment-4399856859> > > confirming here too, I had a single tail process running, and killing it > fixed it. > > — > Reply to this email directly, view it on GitHub > <https://github.com/anthropics/claude-code/issues/42776#issuecomment-4399856859>, > or unsubscribe > <https://github.com/notifications/unsubscribe-auth/ABHZPPVX4LABYNUB64V46OL4ZTG5FAVCNFSM6AAAAACXLA33VSVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHM2DGOJZHA2TMOBVHE> > . > You are receiving this because you commented.Message ID: > @.***> >

The Linux equivalent of tail, which basically reads some lines from a file. Claude runs it internally to work with your files.

> What is the tail.exe process anyway? > All the best, > Shaya Kutnowski > On Thu, May 7, 2026, 9:13 p.m. Thomas Zarebczan _@_.> > wrote: > > _tzarebczan_ left a comment (#42776) > > #42776 (comment) > > confirming here too, I had a single tail process running, and killing it > > fixed it. > > — > > Reply to this email directly, view it on GitHub > > #42776 (comment), > > or unsubscribe > > https://github.com/notifications/unsubscribe-auth/ABHZPPVX4LABYNUB64V46OL4ZTG5FAVCNFSM6AAAAACXLA33VSVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHM2DGOJZHA2TMOBVHE > > . > > You are receiving this because you commented.Message ID: > > _@_.> The Linux equivalent of tail, which basically reads some lines from a file. Claude runs it internally to work with your files.

Doesn't work on my side. I don't have tail.exe and never run claude on Windows for coding task. Only for chat. My coding tasks are all in WSL.

But still, relaunching will fail...

> After installation, Windows Apps showed version 1.5354.0.0 under C:\Program Files\WindowsApps, and that directory appeared to be locked. > > Before rebooting, I also tried updating Git as well. The Git installer reported that tail.exe and grep.exe were blocking the installation. I manually ended both processes in Task Manager, and Git then installed successfully. > > This made me suspect that Claude Code may have been holding these tools open, since I mainly use Claude Code through Claude Desktop App. After that, I tried opening Claude Desktop App again, and the previous “Another program is currently using the file.” error disappeared. Claude Desktop App now opens successfully. > > The displayed version is 1.5354.0 (9A9E3D) in app, matching the locked Windows Apps' version. > > Hope this may help with debugging. Finally! I have looked into this so many times, and never found an answer, but THIS was it for me! tail.exe - killing this from the Task Manager fixed it for me! 🙏

Killing 108!! tail processes spawned by cowork fixed it for me too.
Get-Process -Name "tail" -ErrorAction SilentlyContinue | Stop-Process -Force

Cross-linking with #49655. I reproduced the same Windows Another program is currently using this file behavior and confirmed that the lock can come from processes running under C:\Program Files\WindowsApps\Claude_*.

A working no-reboot workaround was posted here: https://github.com/anthropics/claude-code/issues/49655#issuecomment-4498317708

Key point: stopping CoworkVMService alone may not be enough if claude.exe has relaunched; terminate all claude.exe processes whose executable path is under C:\Program Files\WindowsApps\Claude_*, then retry the update/relaunch.

I have hesitation every time the update prompt comes up in the Claude app because of previous disastrous updates. Now mine is doing the same as yours.

I don't want to restart just yet before I've captured all the Claude files, and I'll have to wait until some active processes have finished on the GPU before trying to restart the computer. I lost a lot of work a few updates ago, and I am keen not to repeat the experience.

Moved to a repository so the scripts can be read before running: https://github.com/leonidrysev/claude-cowork-fix — download: latest release.

Use my bat. It warns first, waits for Enter, then closes Claude and Google Chrome before applying the update fix.

The old attachment here was stale and, worse, broken: it shipped two .ps1 files with non-ASCII strings saved without a UTF-8 BOM, so Windows PowerShell 5.1 (the engine the .bat launches them with) mis-decoded them and the script died before it could log anything. Fixed in v1.1.0, and !fix-install-now.bat --self-test now parse-checks every shipped .ps1 under 5.1 so it cannot regress silently.

Solution here
https://github.com/anthropics/claude-code/issues/42776#issuecomment-4413702296

Small Python workaround that automates the manual handle.exe → taskkill dance on Windows. Wraps Sysinternals handle.exe, parses PIDs from its output, and runs taskkill (graceful, then /F) on each. Skips its own PID and the parent shell so it can't kill the terminal that launched it. Requires Sysinternals handle.exe (from sysinternals.com) on PATH, or pass --handle <full path>.

python kill_claude_handles.py # one pass, default search "Claude"
python kill_claude_handles.py --dry-run # list matches, don't kill
python kill_claude_handles.py --loop # re-scan until clear (capped at 5 at the moment)

Not a root-cause fix - it just saves the manual handle-hunt while the underlying leak gets sorted out by Anthropic.

kill_claude_handles.py

1 shot solution in Windows PS/Terminal here https://github.com/anthropics/claude-code/issues/49655#issuecomment-4510576757

What seemed to fix it for me was using Claude Code in terminal. I've used it in two terminals to do some work, then tried opening the desktop app again and this time it worked.

thx for this hint
this one worked also for me: open the cmd, start claude, close it, open the app and it runs again

Still happening for me.

Use:
Stop-Service -Name "CoworkVMService" -ErrorAction SilentlyContinue; taskkill /f /im "claude.exe" /im "node.exe" /im "git.exe" /im "grep.exe" /im "tail.exe" /im "bun.exe" /im "ssh.exe" /t; Start-Service -Name "CoworkVMService" -ErrorAction SilentlyContinue

I'm seeing this too with every update for past several weeks.

same on my side on windows home

Confirming this is still happening on the current build - same orphaned-process file lock.

Environment

• OS: Windows 11 Home 10.0.26200
• Package: Claude_1.11847.5.0_x64__pzs8sxrjxfjjc (MSIX, Microsoft Store install)

Symptom: After an update, the previous version under C:\Program Files\WindowsApps\Claude_<version>_... stays locked and Windows shows "Another program is currently using this file." Background Claude processes survive after the main window is closed and keep file handles open, so MSIX cannot replace/remove the old package.

The only reliable fix I have found is a full machine reboot. Manually killing the leftover processes works too, but a typical user will not know to do that, and having to reboot on every update is a rough experience.

Seconding the fix direction in this thread and the related reports (#45489, #46200, #41743): on quit/update the app should terminate all of its helper/background processes (the single-instance lock holder, chrome-native-host.exe, GPU/renderer helpers) so the MSIX package can be swapped without a reboot.

Same here, simplest fix is the poweshell one someone posted above:
Get-Process -Name "tail" -ErrorAction SilentlyContinue | Stop-Process -Force

Tried re-installing claude app and this the log file related to this error:

2026/06/13 23:19:17.061501 Log file: C:\Users\admin\AppData\Local\Temp\ClaudeSetup.log
2026/06/13 23:19:17.062035 === Claude Setup 3df4fd263723119bc45f0af2d784afd5055e2ba9 started ===
2026/06/13 23:19:17.063082 AllowAllTrustedApps not found (sideloading assumed enabled): The system cannot find the file specified.
2026/06/13 23:19:17.063082 Windows edition: Professional
2026/06/13 23:19:17.063608 WARNING: CoworkVMService already exists (potential conflict)
2026/06/13 23:19:17.063608 Windows version: 10.0.26100
2026/06/13 23:19:17.063608 Native arch: x64
2026/06/13 23:19:17.063608 Elevation type: Limited
2026/06/13 23:19:17.063608 Is elevated: false
2026/06/13 23:19:17.063608 Sideloading enabled: true
2026/06/13 23:19:17.063608 S Mode: false
2026/06/13 23:19:17.063608 Conflicting service: true
2026/06/13 23:19:17.063608 Running in non-elevated context
2026/06/13 23:19:17.063608 User can elevate — installing MSIX directly
2026/06/13 23:19:17.083415 Splash: 400x300, 8 frame(s), animated=true
2026/06/13 23:19:17.083415 System DPI: 96 (scale: 100%)
2026/06/13 23:19:17.125804 MSIX URL: https://api.anthropic.com/api/desktop/win32/x64/msix/latest/redirect
2026/06/13 23:19:17.126312 Downloading MSIX to C:\Users\admin\AppData\Local\Temp\Claude-3627407367.msix
2026/06/13 23:19:17.134224 proxy: WinHttpGetProxyForUrl("https://api.anthropic.com/api/desktop/win32/x64/msix/latest/redirect"): winapi error #12180
2026/06/13 23:19:17.284040 proxy: WinHttpGetProxyForUrl("https://downloads.claude.ai/releases/win32/x64/1.12603.1/Claude-3df4fd263723119bc45f0af2d784afd5055e2ba9.msix"): winapi error #12180
2026/06/13 23:19:17.723089 Download progress: 10% (23084880 / 230697820 bytes)
2026/06/13 23:19:17.991599 Download progress: 20% (46153376 / 230697820 bytes)
2026/06/13 23:19:18.260724 Download progress: 30% (69221872 / 230697820 bytes)
2026/06/13 23:19:18.530220 Download progress: 40% (92290368 / 230697820 bytes)
2026/06/13 23:19:18.787269 Download progress: 50% (115358864 / 230697820 bytes)
2026/06/13 23:19:19.062924 Download progress: 60% (138427360 / 230697820 bytes)
2026/06/13 23:19:19.337811 Download progress: 70% (161495856 / 230697820 bytes)
2026/06/13 23:19:19.612873 Download progress: 80% (184564352 / 230697820 bytes)
2026/06/13 23:19:19.846375 Download progress: 90% (207649232 / 230697820 bytes)
2026/06/13 23:19:20.099438 Download progress: 100% (230697820 / 230697820 bytes)
2026/06/13 23:19:20.099960 Download complete: 230697820 bytes, SHA256: 01777d6e38533e2b7a7454d21a65b23fb1264d8f5957613c6f44d5bc34b42f37
2026/06/13 23:19:20.100991 Download complete
2026/06/13 23:19:20.115564 Self-elevating: C:\Users\admin\Downloads\Claude Setup (1).exe --elevated --msix-path "C:\Users\admin\AppData\Local\Temp\Claude-3627407367.msix" --log-path "C:\Users\admin\AppData\Local\Temp\ClaudeSetup.log"
2026/06/13 23:19:21.342393 Waiting for elevated process to complete...
2026/06/13 23:19:21.353202 Log file: C:\Users\admin\AppData\Local\Temp\ClaudeSetup.log
2026/06/13 23:19:21.353714 === Claude Setup 3df4fd263723119bc45f0af2d784afd5055e2ba9 started ===
2026/06/13 23:19:21.354242 AllowAllTrustedApps not found (sideloading assumed enabled): The system cannot find the file specified.
2026/06/13 23:19:21.354766 Windows edition: Professional
2026/06/13 23:19:21.355284 WARNING: CoworkVMService already exists (potential conflict)
2026/06/13 23:19:21.355284 Windows version: 10.0.26100
2026/06/13 23:19:21.355284 Native arch: x64
2026/06/13 23:19:21.355284 Elevation type: Full
2026/06/13 23:19:21.355284 Is elevated: true
2026/06/13 23:19:21.355284 Sideloading enabled: true
2026/06/13 23:19:21.355284 S Mode: false
2026/06/13 23:19:21.355284 Conflicting service: true
2026/06/13 23:19:21.355284 Running in elevated context
2026/06/13 23:19:21.355284 Installing MSIX from C:\Users\admin\AppData\Local\Temp\Claude-3627407367.msix (all-users: false)
2026/06/13 23:19:21.375925 Splash: 400x300, 8 frame(s), animated=true
2026/06/13 23:19:21.376452 System DPI: 96 (scale: 100%)
2026/06/13 23:19:21.408103 Verifying Authenticode signature on C:\Users\admin\AppData\Local\Temp\Claude-3627407367.msix
2026/06/13 23:19:21.963327 WinVerifyTrust: MSIX signature is valid
2026/06/13 23:19:22.209254 Signature verified: MSIX signer matches bootstrapper
2026/06/13 23:19:22.209761 Extracted family name from MSIX manifest: Claude_pzs8sxrjxfjjc
2026/06/13 23:19:22.209761 Squirrel process prefix: c:\users\admin\appdata\local\anthropicclaude\
2026/06/13 23:19:22.209761 Checking for running Squirrel Claude processes...
2026/06/13 23:19:22.238053 No Squirrel Claude processes found
2026/06/13 23:19:22.238561 Removing conflicting CoworkVMService...
2026/06/13 23:19:22.238561 WARNING: failed to remove conflicting service: could not open CoworkVMService: Access is denied.
2026/06/13 23:19:22.238561 Checking for existing Claude MSIX packages...
2026/06/13 23:19:22.247560 Removing: Claude_1.11847.5.0_x64__pzs8sxrjxfjjc
2026/06/13 23:19:22.501829 WARNING: Remove failed for Claude_1.11847.5.0_x64__pzs8sxrjxfjjc: RemovePackage failed with HRESULT 0x80073CFA
2026/06/13 23:19:22.501829 Removing: Claude_1.12603.1.0_x64__pzs8sxrjxfjjc
2026/06/13 23:19:22.505021 WARNING: Remove failed for Claude_1.12603.1.0_x64__pzs8sxrjxfjjc: RemovePackage failed with HRESULT 0x80073CFA
2026/06/13 23:19:22.512904 Removing (user): Claude_1.11847.5.0_x64__pzs8sxrjxfjjc
2026/06/13 23:19:22.515002 WARNING: Remove failed for Claude_1.11847.5.0_x64__pzs8sxrjxfjjc: RemovePackage failed with HRESULT 0x80073CFA
2026/06/13 23:19:22.515002 Installing MSIX: C:\Users\admin\AppData\Local\Temp\Claude-3627407367.msix
2026/06/13 23:19:22.515002 Standard install (not split-account), using AddPackage
2026/06/13 23:19:22.515002 Installing via AddPackage (current-user)...
2026/06/13 23:19:54.015282 MSIX package installed successfully
2026/06/13 23:19:54.015282 No Squirrel installation found, skipping uninstall
2026/06/13 23:19:54.019517 MSIX installation succeeded
2026/06/13 23:19:54.036146 Launching Claude...
2026/06/13 23:19:54.036898 Launching Claude via explorer.exe shell:AppsFolder\Claude_pzs8sxrjxfjjc!Claude
2026/06/13 23:19:54.047646 === Claude Setup completed successfully ===
2026/06/13 23:19:54.061247 Elevated process exited with code 0
2026/06/17 00:02:59.216480 Log file: C:\Users\admin\AppData\Local\Temp\ClaudeSetup.log
2026/06/17 00:02:59.217509 === Claude Setup 3df4fd263723119bc45f0af2d784afd5055e2ba9 started ===
2026/06/17 00:02:59.218021 AllowAllTrustedApps not found (sideloading assumed enabled): The system cannot find the file specified.
2026/06/17 00:02:59.218545 Windows edition: Professional
2026/06/17 00:02:59.219061 WARNING: CoworkVMService already exists (potential conflict)
2026/06/17 00:02:59.219061 Windows version: 10.0.26100
2026/06/17 00:02:59.219061 Native arch: x64
2026/06/17 00:02:59.219061 Elevation type: Limited
2026/06/17 00:02:59.219061 Is elevated: false
2026/06/17 00:02:59.219061 Sideloading enabled: true
2026/06/17 00:02:59.219061 S Mode: false
2026/06/17 00:02:59.219061 Conflicting service: true
2026/06/17 00:02:59.219061 Running in non-elevated context
2026/06/17 00:02:59.219061 User can elevate — installing MSIX directly
2026/06/17 00:02:59.240027 Splash: 400x300, 8 frame(s), animated=true
2026/06/17 00:02:59.240027 System DPI: 96 (scale: 100%)
2026/06/17 00:02:59.281427 MSIX URL: https://api.anthropic.com/api/desktop/win32/x64/msix/latest/redirect
2026/06/17 00:02:59.281949 Downloading MSIX to C:\Users\admin\AppData\Local\Temp\Claude-982980574.msix
2026/06/17 00:02:59.290763 proxy: WinHttpGetProxyForUrl("https://api.anthropic.com/api/desktop/win32/x64/msix/latest/redirect"): winapi error #12180
2026/06/17 00:02:59.456762 proxy: WinHttpGetProxyForUrl("https://downloads.claude.ai/releases/win32/x64/1.13576.0/Claude-1290fc2ef5fd27a3883b74505e0ff917413d6832.msix"): winapi error #12180
2026/06/17 00:02:59.889341 Download progress: 10% (23281488 / 232800403 bytes)
2026/06/17 00:03:00.159031 Download progress: 20% (46562976 / 232800403 bytes)
2026/06/17 00:03:00.428829 Download progress: 30% (69844464 / 232800403 bytes)
2026/06/17 00:03:00.699827 Download progress: 40% (93125952 / 232800403 bytes)
2026/06/17 00:03:00.941209 Download progress: 50% (116423952 / 232800403 bytes)
2026/06/17 00:03:01.138137 Download progress: 60% (139689120 / 232800403 bytes)
2026/06/17 00:03:01.334971 Download progress: 70% (162970896 / 232800403 bytes)
2026/06/17 00:03:01.532560 Download progress: 80% (186268832 / 232800403 bytes)
2026/06/17 00:03:01.729522 Download progress: 90% (209534224 / 232800403 bytes)
2026/06/17 00:03:01.926221 Download progress: 100% (232800403 / 232800403 bytes)
2026/06/17 00:03:01.926915 Download complete: 232800403 bytes, SHA256: 36bc69e5dcfdc67959057f9db5427cf4aba2d360808988537c07f68237e2e21a
2026/06/17 00:03:01.927434 Download complete
2026/06/17 00:03:01.940285 Self-elevating: C:\Users\admin\Downloads\Claude Setup (1).exe --elevated --msix-path "C:\Users\admin\AppData\Local\Temp\Claude-982980574.msix" --log-path "C:\Users\admin\AppData\Local\Temp\ClaudeSetup.log"
2026/06/17 00:03:03.405542 Waiting for elevated process to complete...
2026/06/17 00:03:03.417760 Log file: C:\Users\admin\AppData\Local\Temp\ClaudeSetup.log
2026/06/17 00:03:03.417760 === Claude Setup 3df4fd263723119bc45f0af2d784afd5055e2ba9 started ===
2026/06/17 00:03:03.418793 AllowAllTrustedApps not found (sideloading assumed enabled): The system cannot find the file specified.
2026/06/17 00:03:03.418793 Windows edition: Professional
2026/06/17 00:03:03.419324 WARNING: CoworkVMService already exists (potential conflict)
2026/06/17 00:03:03.419324 Windows version: 10.0.26100
2026/06/17 00:03:03.419324 Native arch: x64
2026/06/17 00:03:03.419324 Elevation type: Full
2026/06/17 00:03:03.419324 Is elevated: true
2026/06/17 00:03:03.419324 Sideloading enabled: true
2026/06/17 00:03:03.419324 S Mode: false
2026/06/17 00:03:03.419324 Conflicting service: true
2026/06/17 00:03:03.419324 Running in elevated context
2026/06/17 00:03:03.419324 Installing MSIX from C:\Users\admin\AppData\Local\Temp\Claude-982980574.msix (all-users: false)
2026/06/17 00:03:03.439509 Splash: 400x300, 8 frame(s), animated=true
2026/06/17 00:03:03.439509 System DPI: 96 (scale: 100%)
2026/06/17 00:03:03.471602 Verifying Authenticode signature on C:\Users\admin\AppData\Local\Temp\Claude-982980574.msix
2026/06/17 00:03:04.001958 WinVerifyTrust: MSIX signature is valid
2026/06/17 00:03:04.258598 Signature verified: MSIX signer matches bootstrapper
2026/06/17 00:03:04.259628 Extracted family name from MSIX manifest: Claude_pzs8sxrjxfjjc
2026/06/17 00:03:04.259628 Squirrel process prefix: c:\users\admin\appdata\local\anthropicclaude\
2026/06/17 00:03:04.259628 Checking for running Squirrel Claude processes...
2026/06/17 00:03:04.285700 No Squirrel Claude processes found
2026/06/17 00:03:04.285700 Removing conflicting CoworkVMService...
2026/06/17 00:03:04.285700 WARNING: failed to remove conflicting service: could not open CoworkVMService: Access is denied.
2026/06/17 00:03:04.285700 Checking for existing Claude MSIX packages...
2026/06/17 00:03:04.295548 Removing: Claude_1.13576.0.0_x64__pzs8sxrjxfjjc
2026/06/17 00:03:04.299668 WARNING: Remove failed for Claude_1.13576.0.0_x64__pzs8sxrjxfjjc: RemovePackage failed with HRESULT 0x80073CFA
2026/06/17 00:03:04.306963 Removing (user): Claude_1.13576.0.0_x64__pzs8sxrjxfjjc
2026/06/17 00:03:04.309735 WARNING: Remove failed for Claude_1.13576.0.0_x64__pzs8sxrjxfjjc: RemovePackage failed with HRESULT 0x80073CFA
2026/06/17 00:03:04.309735 Installing MSIX: C:\Users\admin\AppData\Local\Temp\Claude-982980574.msix
2026/06/17 00:03:04.309735 Standard install (not split-account), using AddPackage
2026/06/17 00:03:04.309735 Installing via AddPackage (current-user)...
2026/06/17 00:03:04.810120 MSIX package installed successfully
2026/06/17 00:03:04.810120 No Squirrel installation found, skipping uninstall
2026/06/17 00:03:04.823926 MSIX installation succeeded
2026/06/17 00:03:04.841887 Launching Claude...
2026/06/17 00:03:04.842736 Launching Claude via explorer.exe shell:AppsFolder\Claude_pzs8sxrjxfjjc!Claude
2026/06/17 00:03:04.849900 === Claude Setup completed successfully ===
2026/06/17 00:03:04.859693 Elevated process exited with code 0
2026/06/17 00:05:36.852372 Log file: C:\Users\admin\AppData\Local\Temp\ClaudeSetup.log
2026/06/17 00:05:36.852895 === Claude Setup 3df4fd263723119bc45f0af2d784afd5055e2ba9 started ===
2026/06/17 00:05:36.853419 AllowAllTrustedApps not found (sideloading assumed enabled): The system cannot find the file specified.
2026/06/17 00:05:36.853948 Windows edition: Professional
2026/06/17 00:05:36.853948 Windows version: 10.0.26100
2026/06/17 00:05:36.854474 Native arch: x64
2026/06/17 00:05:36.854474 Elevation type: Limited
2026/06/17 00:05:36.854474 Is elevated: false
2026/06/17 00:05:36.854474 Sideloading enabled: true
2026/06/17 00:05:36.854474 S Mode: false
2026/06/17 00:05:36.854474 Conflicting service: false
2026/06/17 00:05:36.854474 Running in non-elevated context
2026/06/17 00:05:36.854474 User can elevate — installing MSIX directly
2026/06/17 00:05:36.873267 Splash: 400x300, 8 frame(s), animated=true
2026/06/17 00:05:36.873792 System DPI: 96 (scale: 100%)
2026/06/17 00:05:36.909208 MSIX URL: https://api.anthropic.com/api/desktop/win32/x64/msix/latest/redirect
2026/06/17 00:05:36.909884 Downloading MSIX to C:\Users\admin\AppData\Local\Temp\Claude-3522112062.msix
2026/06/17 00:05:36.919301 proxy: WinHttpGetProxyForUrl("https://api.anthropic.com/api/desktop/win32/x64/msix/latest/redirect"): winapi error #12180
2026/06/17 00:05:37.088305 proxy: WinHttpGetProxyForUrl("https://downloads.claude.ai/releases/win32/x64/1.13576.0/Claude-1290fc2ef5fd27a3883b74505e0ff917413d6832.msix"): winapi error #12180
2026/06/17 00:05:37.530207 Download progress: 10% (23281488 / 232800403 bytes)
2026/06/17 00:05:37.804079 Download progress: 20% (46562976 / 232800403 bytes)
2026/06/17 00:05:38.078451 Download progress: 30% (69860848 / 232800403 bytes)
2026/06/17 00:05:38.351879 Download progress: 40% (93125952 / 232800403 bytes)
2026/06/17 00:05:38.562492 Download progress: 50% (116423856 / 232800403 bytes)
2026/06/17 00:05:38.759051 Download progress: 60% (139689024 / 232800403 bytes)
2026/06/17 00:05:38.956844 Download progress: 70% (162986896 / 232800403 bytes)
2026/06/17 00:05:39.153305 Download progress: 80% (186251392 / 232800403 bytes)
2026/06/17 00:05:39.350725 Download progress: 90% (209549232 / 232800403 bytes)
2026/06/17 00:05:39.547568 Download progress: 100% (232800403 / 232800403 bytes)
2026/06/17 00:05:39.548088 Download complete: 232800403 bytes, SHA256: 36bc69e5dcfdc67959057f9db5427cf4aba2d360808988537c07f68237e2e21a
2026/06/17 00:05:39.549124 Download complete
2026/06/17 00:05:39.561608 Self-elevating: C:\Users\admin\Downloads\Claude Setup (1).exe --elevated --msix-path "C:\Users\admin\AppData\Local\Temp\Claude-3522112062.msix" --log-path "C:\Users\admin\AppData\Local\Temp\ClaudeSetup.log"
2026/06/17 00:05:40.716629 Waiting for elevated process to complete...
2026/06/17 00:05:40.730434 Log file: C:\Users\admin\AppData\Local\Temp\ClaudeSetup.log
2026/06/17 00:05:40.730955 === Claude Setup 3df4fd263723119bc45f0af2d784afd5055e2ba9 started ===
2026/06/17 00:05:40.731475 AllowAllTrustedApps not found (sideloading assumed enabled): The system cannot find the file specified.
2026/06/17 00:05:40.732190 Windows edition: Professional
2026/06/17 00:05:40.732714 Windows version: 10.0.26100
2026/06/17 00:05:40.732714 Native arch: x64
2026/06/17 00:05:40.732714 Elevation type: Full
2026/06/17 00:05:40.732714 Is elevated: true
2026/06/17 00:05:40.732714 Sideloading enabled: true
2026/06/17 00:05:40.732714 S Mode: false
2026/06/17 00:05:40.732714 Conflicting service: false
2026/06/17 00:05:40.732714 Running in elevated context
2026/06/17 00:05:40.732714 Installing MSIX from C:\Users\admin\AppData\Local\Temp\Claude-3522112062.msix (all-users: false)
2026/06/17 00:05:40.752660 Splash: 400x300, 8 frame(s), animated=true
2026/06/17 00:05:40.752660 System DPI: 96 (scale: 100%)
2026/06/17 00:05:40.792572 Verifying Authenticode signature on C:\Users\admin\AppData\Local\Temp\Claude-3522112062.msix
2026/06/17 00:05:41.330723 WinVerifyTrust: MSIX signature is valid
2026/06/17 00:05:41.572802 Signature verified: MSIX signer matches bootstrapper
2026/06/17 00:05:41.573821 Extracted family name from MSIX manifest: Claude_pzs8sxrjxfjjc
2026/06/17 00:05:41.573821 Squirrel process prefix: c:\users\admin\appdata\local\anthropicclaude\
2026/06/17 00:05:41.573821 Checking for running Squirrel Claude processes...
2026/06/17 00:05:41.599459 No Squirrel Claude processes found
2026/06/17 00:05:41.599459 Checking for existing Claude MSIX packages...
2026/06/17 00:05:41.618959 Installing MSIX: C:\Users\admin\AppData\Local\Temp\Claude-3522112062.msix
2026/06/17 00:05:41.618959 Standard install (not split-account), using AddPackage
2026/06/17 00:05:41.618959 Installing via AddPackage (current-user)...
2026/06/17 00:06:03.873048 MSIX installation failed: AddPackage failed: AddPackage failed with HRESULT 0x80073CF6
2026/06/17 00:06:03.873048 ERROR dialog (opening log): Installation failed: AddPackage failed: AddPackage failed with HRESULT 0x80073CF6

Please share this log with us.
2026/06/17 00:06:28.342809 Elevated process exited with code 1
2026/06/17 00:06:28.342809 Elevation failed: elevated installer exited with code 1
2026/06/17 00:06:28.342809 ERROR dialog (with log path): Administrator access is required to install Claude with full features. You can try again or install without Cowork.
2026/06/17 00:07:01.063837 Log file: C:\Users\admin\AppData\Local\Temp\ClaudeSetup.log
2026/06/17 00:07:01.064357 === Claude Setup 3df4fd263723119bc45f0af2d784afd5055e2ba9 started ===
2026/06/17 00:07:01.065401 AllowAllTrustedApps not found (sideloading assumed enabled): The system cannot find the file specified.
2026/06/17 00:07:01.065401 Windows edition: Professional
2026/06/17 00:07:01.065921 Windows version: 10.0.26100
2026/06/17 00:07:01.065921 Native arch: x64
2026/06/17 00:07:01.065921 Elevation type: Full
2026/06/17 00:07:01.065921 Is elevated: true
2026/06/17 00:07:01.065921 Sideloading enabled: true
2026/06/17 00:07:01.065921 S Mode: false
2026/06/17 00:07:01.065921 Conflicting service: false
2026/06/17 00:07:01.065921 Running in non-elevated context
2026/06/17 00:07:01.065921 User can elevate — installing MSIX directly
2026/06/17 00:07:01.087876 Splash: 400x300, 8 frame(s), animated=true
2026/06/17 00:07:01.087876 System DPI: 96 (scale: 100%)
2026/06/17 00:07:01.120495 MSIX URL: https://api.anthropic.com/api/desktop/win32/x64/msix/latest/redirect
2026/06/17 00:07:01.120495 Downloading MSIX to C:\Users\admin\AppData\Local\Temp\Claude-265286785.msix
2026/06/17 00:07:01.129347 proxy: WinHttpGetProxyForUrl("https://api.anthropic.com/api/desktop/win32/x64/msix/latest/redirect"): winapi error #12180
2026/06/17 00:07:01.276162 proxy: WinHttpGetProxyForUrl("https://downloads.claude.ai/releases/win32/x64/1.13576.0/Claude-1290fc2ef5fd27a3883b74505e0ff917413d6832.msix"): winapi error #12180
2026/06/17 00:07:01.717566 Download progress: 10% (23297872 / 232800403 bytes)
2026/06/17 00:07:01.989213 Download progress: 20% (46562976 / 232800403 bytes)
2026/06/17 00:07:02.260360 Download progress: 30% (69844464 / 232800403 bytes)
2026/06/17 00:07:02.531982 Download progress: 40% (93125952 / 232800403 bytes)
2026/06/17 00:07:02.743490 Download progress: 50% (116407040 / 232800403 bytes)
2026/06/17 00:07:02.940621 Download progress: 60% (139705088 / 232800403 bytes)
2026/06/17 00:07:03.137994 Download progress: 70% (162970368 / 232800403 bytes)
2026/06/17 00:07:03.335489 Download progress: 80% (186268416 / 232800403 bytes)
2026/06/17 00:07:03.532523 Download progress: 90% (209533696 / 232800403 bytes)
2026/06/17 00:07:03.728883 Download progress: 100% (232800403 / 232800403 bytes)
2026/06/17 00:07:03.730003 Download complete: 232800403 bytes, SHA256: 36bc69e5dcfdc67959057f9db5427cf4aba2d360808988537c07f68237e2e21a
2026/06/17 00:07:03.730518 Download complete
2026/06/17 00:07:03.739444 Self-elevating: C:\Users\admin\Downloads\Claude Setup (1).exe --elevated --msix-path "C:\Users\admin\AppData\Local\Temp\Claude-265286785.msix" --log-path "C:\Users\admin\AppData\Local\Temp\ClaudeSetup.log"
2026/06/17 00:07:03.780585 Waiting for elevated process to complete...
2026/06/17 00:07:03.787453 Log file: C:\Users\admin\AppData\Local\Temp\ClaudeSetup.log
2026/06/17 00:07:03.787984 === Claude Setup 3df4fd263723119bc45f0af2d784afd5055e2ba9 started ===
2026/06/17 00:07:03.789032 AllowAllTrustedApps not found (sideloading assumed enabled): The system cannot find the file specified.
2026/06/17 00:07:03.789032 Windows edition: Professional
2026/06/17 00:07:03.789549 Windows version: 10.0.26100
2026/06/17 00:07:03.789549 Native arch: x64
2026/06/17 00:07:03.789549 Elevation type: Full
2026/06/17 00:07:03.789549 Is elevated: true
2026/06/17 00:07:03.789549 Sideloading enabled: true
2026/06/17 00:07:03.789549 S Mode: false
2026/06/17 00:07:03.789549 Conflicting service: false
2026/06/17 00:07:03.789549 Running in elevated context
2026/06/17 00:07:03.789549 Installing MSIX from C:\Users\admin\AppData\Local\Temp\Claude-265286785.msix (all-users: false)
2026/06/17 00:07:03.810571 Splash: 400x300, 8 frame(s), animated=true
2026/06/17 00:07:03.810571 System DPI: 96 (scale: 100%)
2026/06/17 00:07:03.840278 Verifying Authenticode signature on C:\Users\admin\AppData\Local\Temp\Claude-265286785.msix
2026/06/17 00:07:04.382765 WinVerifyTrust: MSIX signature is valid
2026/06/17 00:07:04.629229 Signature verified: MSIX signer matches bootstrapper
2026/06/17 00:07:04.629736 Extracted family name from MSIX manifest: Claude_pzs8sxrjxfjjc
2026/06/17 00:07:04.629736 Squirrel process prefix: c:\users\admin\appdata\local\anthropicclaude\
2026/06/17 00:07:04.629736 Checking for running Squirrel Claude processes...
2026/06/17 00:07:04.656030 No Squirrel Claude processes found
2026/06/17 00:07:04.656030 Checking for existing Claude MSIX packages...
2026/06/17 00:07:04.672009 Installing MSIX: C:\Users\admin\AppData\Local\Temp\Claude-265286785.msix
2026/06/17 00:07:04.672009 Standard install (not split-account), using AddPackage
2026/06/17 00:07:04.672009 Installing via AddPackage (current-user)...
2026/06/17 00:07:26.676519 MSIX installation failed: AddPackage failed: AddPackage failed with HRESULT 0x80073CF6
2026/06/17 00:07:26.676519 ERROR dialog (opening log): Installation failed: AddPackage failed: AddPackage failed with HRESULT 0x80073CF6

Please share this log with us.
2026/06/17 00:07:31.208008 Elevated process exited with code 1
2026/06/17 00:07:31.208008 Elevation failed: elevated installer exited with code 1
2026/06/17 00:07:31.208008 ERROR dialog (with log path): Administrator access is required to install Claude with full features. You can try again or install without Cowork.
2026/06/17 00:08:10.171507 Log file: C:\Users\admin\AppData\Local\Temp\ClaudeSetup.log
2026/06/17 00:08:10.172024 === Claude Setup 3df4fd263723119bc45f0af2d784afd5055e2ba9 started ===
2026/06/17 00:08:10.172539 AllowAllTrustedApps not found (sideloading assumed enabled): The system cannot find the file specified.
2026/06/17 00:08:10.172539 Windows edition: Professional
2026/06/17 00:08:10.173059 Windows version: 10.0.26100
2026/06/17 00:08:10.173059 Native arch: x64
2026/06/17 00:08:10.173059 Elevation type: Limited
2026/06/17 00:08:10.173059 Is elevated: false
2026/06/17 00:08:10.173059 Sideloading enabled: true
2026/06/17 00:08:10.173059 S Mode: false
2026/06/17 00:08:10.173059 Conflicting service: false
2026/06/17 00:08:10.173059 Running in non-elevated context
2026/06/17 00:08:10.173059 User can elevate — installing MSIX directly
2026/06/17 00:08:10.192727 Splash: 400x300, 8 frame(s), animated=true
2026/06/17 00:08:10.192727 System DPI: 96 (scale: 100%)
2026/06/17 00:08:10.224105 MSIX URL: https://api.anthropic.com/api/desktop/win32/x64/msix/latest/redirect
2026/06/17 00:08:10.224624 Downloading MSIX to C:\Users\admin\AppData\Local\Temp\Claude-2743911772.msix
2026/06/17 00:08:10.232080 proxy: WinHttpGetProxyForUrl("https://api.anthropic.com/api/desktop/win32/x64/msix/latest/redirect"): winapi error #12180
2026/06/17 00:08:10.447417 proxy: WinHttpGetProxyForUrl("https://downloads.claude.ai/releases/win32/x64/1.13576.0/Claude-1290fc2ef5fd27a3883b74505e0ff917413d6832.msix"): winapi error #12180
2026/06/17 00:08:10.886034 Download progress: 10% (23297872 / 232800403 bytes)
2026/06/17 00:08:11.159068 Download progress: 20% (46562976 / 232800403 bytes)
2026/06/17 00:08:11.432795 Download progress: 30% (69844464 / 232800403 bytes)
2026/06/17 00:08:11.706326 Download progress: 40% (93125952 / 232800403 bytes)
2026/06/17 00:08:11.918017 Download progress: 50% (116423952 / 232800403 bytes)
2026/06/17 00:08:12.114996 Download progress: 60% (139705504 / 232800403 bytes)
2026/06/17 00:08:12.311738 Download progress: 70% (162970768 / 232800403 bytes)
2026/06/17 00:08:12.509313 Download progress: 80% (186268832 / 232800403 bytes)
2026/06/17 00:08:12.706595 Download progress: 90% (209534096 / 232800403 bytes)
2026/06/17 00:08:12.903587 Download progress: 100% (232800403 / 232800403 bytes)
2026/06/17 00:08:12.904108 Download complete: 232800403 bytes, SHA256: 36bc69e5dcfdc67959057f9db5427cf4aba2d360808988537c07f68237e2e21a
2026/06/17 00:08:12.904728 Download complete
2026/06/17 00:08:12.915452 Self-elevating: C:\Users\admin\Downloads\Claude Setup (1).exe --elevated --msix-path "C:\Users\admin\AppData\Local\Temp\Claude-2743911772.msix" --log-path "C:\Users\admin\AppData\Local\Temp\ClaudeSetup.log"
2026/06/17 00:08:14.292446 Waiting for elevated process to complete...
2026/06/17 00:08:14.303789 Log file: C:\Users\admin\AppData\Local\Temp\ClaudeSetup.log
2026/06/17 00:08:14.303789 === Claude Setup 3df4fd263723119bc45f0af2d784afd5055e2ba9 started ===
2026/06/17 00:08:14.304862 AllowAllTrustedApps not found (sideloading assumed enabled): The system cannot find the file specified.
2026/06/17 00:08:14.304862 Windows edition: Professional
2026/06/17 00:08:14.305395 Windows version: 10.0.26100
2026/06/17 00:08:14.305395 Native arch: x64
2026/06/17 00:08:14.305395 Elevation type: Full
2026/06/17 00:08:14.305395 Is elevated: true
2026/06/17 00:08:14.305395 Sideloading enabled: true
2026/06/17 00:08:14.305395 S Mode: false
2026/06/17 00:08:14.305395 Conflicting service: false
2026/06/17 00:08:14.305395 Running in elevated context
2026/06/17 00:08:14.305925 Installing MSIX from C:\Users\admin\AppData\Local\Temp\Claude-2743911772.msix (all-users: false)
2026/06/17 00:08:14.326755 Splash: 400x300, 8 frame(s), animated=true
2026/06/17 00:08:14.327271 System DPI: 96 (scale: 100%)
2026/06/17 00:08:14.375071 Verifying Authenticode signature on C:\Users\admin\AppData\Local\Temp\Claude-2743911772.msix
2026/06/17 00:08:14.913019 WinVerifyTrust: MSIX signature is valid
2026/06/17 00:08:15.150573 Signature verified: MSIX signer matches bootstrapper
2026/06/17 00:08:15.151188 Extracted family name from MSIX manifest: Claude_pzs8sxrjxfjjc
2026/06/17 00:08:15.151188 Squirrel process prefix: c:\users\admin\appdata\local\anthropicclaude\
2026/06/17 00:08:15.151188 Checking for running Squirrel Claude processes...
2026/06/17 00:08:15.176317 No Squirrel Claude processes found
2026/06/17 00:08:15.176831 Checking for existing Claude MSIX packages...
2026/06/17 00:08:15.193300 Installing MSIX: C:\Users\admin\AppData\Local\Temp\Claude-2743911772.msix
2026/06/17 00:08:15.193300 Standard install (not split-account), using AddPackage
2026/06/17 00:08:15.193300 Installing via AddPackage (current-user)...
2026/06/17 00:08:36.956677 MSIX installation failed: AddPackage failed: AddPackage failed with HRESULT 0x80073CF6
2026/06/17 00:08:36.956677 ERROR dialog (opening log): Installation failed: AddPackage failed: AddPackage failed with HRESULT 0x80073CF6

Please share this log with us.
2026/06/17 00:08:39.107938 Elevated process exited with code 1
2026/06/17 00:08:39.107938 Elevation failed: elevated installer exited with code 1
2026/06/17 00:08:39.107938 ERROR dialog (with log path): Administrator access is required to install Claude with full features. You can try again or install without Cowork.

I have kind of a different issue, I fully uninstalled Claude, then reinstalled it yesterday. After a computer restart, Claude fails to launch, everytime. I don't have an error saying it's already in use, but it's about Windows not being able to access the directory because of some authorization access to files.

<img width="556" height="136" alt="Image" src="https://github.com/user-attachments/assets/c2e540c2-19b3-4392-99fc-bb1a7b819139" />

what a shame... they cannot fix this THE MOST ANNOING BUG even having Mythos. what a shame...

Yes that's really crazy. On Mac the don't have this issue I guess. On
windows we are left behind it seems...

Le ven. 19 juin 2026, 10:32, Raule Blanko @.***> a
écrit :

raulblanko left a comment (anthropics/claude-code#42776) <https://github.com/anthropics/claude-code/issues/42776#issuecomment-4749877424> what a shame... they cannot fix this THE MOST ANNOING BUG even having Mythos. what a shame... — Reply to this email directly, view it on GitHub <https://github.com/anthropics/claude-code/issues/42776?email_source=notifications&email_token=AKXMFLH775MXTMG2CFPVB3T5AT3ATA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTINZUHE4DONZUGI2KM4TFMFZW63VHMNXW23LFNZ2KKZLWMVXHJLDGN5XXIZLSL5RWY2LDNM#issuecomment-4749877424>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AKXMFLCKCY462IZIYTB45UT5AT3ATAVCNFSNUABFKJSXA33TNF2G64TZHM4TGNZSGUZTINZVHNEXG43VMU5TIMJZGY4DGNZSHA2KC5QC> . You are receiving this because you commented.Message ID: @.***>

Killing all node.exe processes worked for me as a workaround

genuinely pathetic you guys haven't fixed this bug

outrageous i have to fully restart my computer every time an update comes in

UNACCAPETABLE

Killing all node.exe processes worked for me as a workaround

This works for me too! Thx.

Moved to a repository so the scripts can be read before running: https://github.com/leonidrysev/claude-cowork-fix — download: latest release.

Fair point above about running a zip of .bat/.ps1 from a stranger — so the sources are now in the open, one file per step, commented inline. !fix-install-now.bat --self-test is non-destructive (no UAC, nothing closed, no scheduled task, no registry unload) if you want to exercise it before trusting it.

What it does: disarms CoworkVMService (its ETW named-pipe trigger plus Start=4), closes processes running out of the Claude package folder, then commits the already-staged update by registering the newer version's manifest directly — so it does not depend on the app's own relaunch, and normally needs no reboot. A deeper repair (stale runtime-cache folders, corrupted config) and a backup-first SYSTEM recovery for the kernel-held package-hive case are included but only offered when the matching failure is actually detected.

The old attachment here was stale and broken: two .ps1 files carried non-ASCII strings without a UTF-8 BOM, which Windows PowerShell 5.1 mis-decodes, killing the script before it logs anything. Fixed in v1.1.0; the self-test now parse-checks all shipped .ps1 files under 5.1.

@leonidrysev please dont provide zip file, its risky to run someone ps1/bat files downloaded from net these days, that does mean yours are dangerous (dont look at them yet), but its bad habbit i think.

on windows use this:
Get-Process node -ErrorAction SilentlyContinue | Stop-Process -Force

or taskkill /F /IM node.exe

and similar cmd on linux (pkill -9 -f node ?)

same issue

<img width="440" height="154" alt="Image" src="https://github.com/user-attachments/assets/4a8f3791-2a7e-4efc-ac77-96bc5ee8afb3" />

Those who are looking for the solution check out this reddit thread: https://www.reddit.com/r/ClaudeAI/comments/1sncgki/comment/ol8a8ap/?utm_source=share&utm_medium=web3x&utm_name=web3xcss&utm_term=1&utm_content=share_button

Those who are looking for the solution check out this reddit thread: https://www.reddit.com/r/ClaudeAI/comments/1sncgki/comment/ol8a8ap/?utm_source=share&utm_medium=web3x&utm_name=web3xcss&utm_term=1&utm_content=share_button

For me , killing all instances of node.exe was enough.

Root cause & registry-level fix (no reboot needed)

The commonly suggested workarounds (Stop-Service, Set-Service -StartupType Disabled, taskkill) don't work for most people because CoworkVMService is a WIN32_PACKAGED_PROCESS service — Windows blocks sc.exe and Set-Service with Access Denied (error 5) even from an elevated admin shell.

On top of that, the service has an ETW trigger registered on the named pipe \pipe\cowork-vm-service. This means even if you manage to kill the process, Windows auto-respawns it the moment anything touches that pipe. Setting the startup type to Manual doesn't help — the trigger bypasses it.

The fix (run from an elevated PowerShell before updating):

# 1. Delete the ETW trigger that auto-respawns the service
Remove-Item -Path "HKLM:\SYSTEM\CurrentControlSet\Services\CoworkVMService\TriggerInfo" -Recurse -Force

# 2. Set startup type to Disabled via registry (sc.exe can't touch packaged services)
Set-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Services\CoworkVMService" -Name "Start" -Value 4

# 3. Now you can actually kill it and it stays dead
Stop-Process -Name cowork-svc -Force -ErrorAction SilentlyContinue

Then close Claude Desktop, confirm no claude.exe or cowork-svc.exe processes remain, and apply the update. The new MSIX package will recreate the service pointing at the new version with a fresh config.

Why this works

• Registry writes bypass the MSIX service protection that blocks sc.exe / Set-Service
• Deleting TriggerInfo prevents Windows from auto-respawning the service via the ETW named pipe trigger
• Setting Start=4 (Disabled) prevents it from starting on boot

Suggestion for Anthropic

The auto-updater should stop CoworkVMService before attempting to replace the MSIX package files. This is the root cause — the service holds file locks on the old package directory, preventing the Store from swapping in the new version.

## Root cause & registry-level fix (no reboot needed) The commonly suggested workarounds (Stop-Service, Set-Service -StartupType Disabled, taskkill) don't work for most people because CoworkVMService is a WIN32_PACKAGED_PROCESS service — Windows blocks sc.exe and Set-Service with Access Denied (error 5) even from an elevated admin shell. On top of that, the service has an ETW trigger registered on the named pipe \pipe\cowork-vm-service. This means even if you manage to kill the process, Windows auto-respawns it the moment anything touches that pipe. Setting the startup type to Manual doesn't help — the trigger bypasses it. ### The fix (run from an elevated PowerShell before updating): # 1. Delete the ETW trigger that auto-respawns the service Remove-Item -Path "HKLM:\SYSTEM\CurrentControlSet\Services\CoworkVMService\TriggerInfo" -Recurse -Force # 2. Set startup type to Disabled via registry (sc.exe can't touch packaged services) Set-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Services\CoworkVMService" -Name "Start" -Value 4 # 3. Now you can actually kill it and it stays dead Stop-Process -Name cowork-svc -Force -ErrorAction SilentlyContinue Then close Claude Desktop, confirm no claude.exe or cowork-svc.exe processes remain, and apply the update. The new MSIX package will recreate the service pointing at the new version with a fresh config. ### Why this works Registry writes bypass the MSIX service protection that blocks sc.exe / Set-Service Deleting TriggerInfo prevents Windows from auto-respawning the service via the ETW named pipe trigger * Setting Start=4 (Disabled) prevents it from starting on boot ### Suggestion for Anthropic The auto-updater should stop CoworkVMService before attempting to replace the MSIX package files. This is the root cause — the service holds file locks on the old package directory, preventing the Store from swapping in the new version.

Doesn't work for me. Only fix is to either restart or sign-out and sign back in (which is a bit quicker than restarting).

Also having this issue and have had it for several versions. I have learned to just not install updates unless I want a reboot. One bonus, I have been reminded of how good Codex is every time I get locked out of Claude Code because of this error and switch over. Just sayin'.

Killing the node processes with taskkill /f /im "node.exe" worked for me!

Cannot believe this issue is still happening, crazy

I do not see any node.exe child procs laying around on the latest release, so you can also try this:

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
}

Update: If the above doesn't work, taskkill /f /im "node.exe" is the finishing touch, thanks @Jerrill

same issue - last two updates with this bug.
I kill all processes but fix only with full reboot

I've been dealing with this issue for months now.

This issue been around for months. I keep an eye on this but none of above fixes works for me. Can't believe a company who creates fable has such a critical issue for months.

My most recent work around is to "Quit" from the status bar and restart. This usually allows me to update successfully. Still very frustrating.

New lock vector not yet documented in this thread: chrome-native-host.exe is held open by Chrome, not by Claude — which is why quitting Claude entirely still doesn't free the package, and why a full reboot "fixes" it.

Mechanism:

• The browser-extension native-messaging manifest at %APPDATA%\Claude\ChromeNativeHost\com.anthropic.claude_browser_extension.json points Chrome at the exe inside the versioned package directory: C:\Program Files\WindowsApps\Claude_<version>\app\resources\chrome-native-host.exe.
• Chrome spawns that host and owns its lifetime. Quit Claude → the host keeps running under Chrome → MSIX deployment can't replace the package → "Another program is currently using this file" / 0x80073D02.
• A reboot works only because it also restarts Chrome. Same reason stopping CoworkVMService alone doesn't always fix it for extension users.

Repro: Claude desktop + Chrome extension enabled; quit Claude, keep Chrome open; run Get-Process | Where-Object { $_.Path -like 'C:\Program Files\WindowsApps\Claude_*' } → chrome-native-host.exe (and often orphaned Claude.exe — 13 observed on my machine) still running; update fails.

Observed on: Windows 11 Pro 26200, package Claude_1.20186.0.0_x64__pzs8sxrjxfjjc. AppXDeploymentServer/Operational logs daily 0x80073D02 retries at the 6:00 AM maintenance window.

Suggested fixes:

1. Install the native-messaging host to a version-stable path outside the package (e.g. %LOCALAPPDATA%), so Chrome's handle never blocks package replacement — standard practice for auto-updating apps that ship native hosts.
2. On "Relaunch to update": terminate all processes whose image path is inside the package (native host included; Chrome respawns it on demand).
3. Use Restart Manager to name the actual holder in the error dialog ("Chrome is holding the extension helper") instead of the raw file-lock message.
4. Retry the staged update on next launch after 0x80070020/0x80073D02 instead of a dead-end modal.

User-side workaround (no admin, no ACL changes): stop every process whose image path is under WindowsApps\Claude_*, close Chrome if the host respawns, then relaunch Claude — the update applies without a reboot.

Root cause analysis: "Another program is currently using this file" on relaunch after update (Windows, MSIX)

Follow-up to my earlier comments with hard evidence. I captured the failure live with ProcMon + Sysmon across eight failed launch attempts, correlated with Windows AppModel-Runtime event logs, and I believe this identifies the actual failing operation — and explains why every handle-hunting / taskkill workaround in this thread behaves so inconsistently.

TL;DR: This is not a file lock on anything under WindowsApps. The AppX container ("job") for the package cannot be created because the package's per-user virtual registry hive (Helium\User.dat) is still loaded in the kernel from the pre-update container. RegLoadKey fails with SHARING VIOLATION, activation fails with 0x80070020, and the shell surfaces the misleading "another program is currently using this file" dialog. The lock is held by the kernel's container/virtual-registry machinery — there is no user-mode handle to find, which is why Process Explorer / handle64 / Resource Monitor all come up empty and why only a reboot reliably clears it.

Environment

• Claude Desktop 1.22209.0.0 x64, MSIX (Claude_1.22209.0.0_x64__pzs8sxrjxfjjc), Get-AppxPackage Status: Ok
• Claude Code bundle 2.1.209
• Windows 11 Pro, build 10.0.26200
• Trigger: in-app update, followed by relaunch → error dialog on every attempt until reboot

Evidence 1 — ProcMon: the failing operation

Every click on the Claude icon produces exactly this pair (ProcMon trace, filter Result != SUCCESS; svchost PID is the AppInfo service, svchost.exe -k netsvcs -p -s Appinfo):

1:05:41.618 PM  svchost.exe (Appinfo)  RegLoadKey  \Registry\WC\Silo045431ea-...user_sid   SHARING VIOLATION
                Hive Path: C:\Users\<user>\AppData\Local\Packages\Claude_pzs8sxrjxfjjc\SystemAppData\Helium\User.dat
1:05:41.618 PM  svchost.exe (Appinfo)  CreateFile  ...\Claude_pzs8sxrjxfjjc\SystemAppData\Helium\User.dat  SHARING VIOLATION
                Desired Access: Read/Write, Disposition: OpenIf, ShareMode: None, Impersonating: <user>

Eight failed launch attempts in the capture window → eight RegLoadKey+CreateFile SHARING VIOLATION pairs, one per attempt. Nothing under C:\Program Files\WindowsApps\Claude_... ever fails. The contended file is the package's per-user Helium registry hive under AppData\Local\Packages.

Evidence 2 — Windows event log agrees

Microsoft-Windows-AppModel-Runtime/Admin, same seconds as each launch attempt:

Event 215  Error  0x80070020: Cannot create the Desktop AppX container for package
           Claude_1.22209.0.0_x64__pzs8sxrjxfjjc because an error was encountered converting the job.
Event 208  Error  0x80070020: Cannot create the process for package Claude_... [LaunchProcess]

0x80070020 = ERROR_SHARING_VIOLATION. "Converting the job" fails because mounting the user hive into the container silo is part of container creation — and that mount is what ProcMon shows failing. This is the same Event 215 signature reported in #57221.

Evidence 3 — why no tool can find the lock

Before capturing, I verified with an elevated Process Explorer Ctrl+F search that zero handles or DLLs referenced the package path. The error occurred anyway.

After recovering (reboot), with the app running healthily, I confirmed the mechanism:

• HKLM\SYSTEM\CurrentControlSet\Control\hivelist lists the hive as loaded: \REGISTRY\WC\Silo045431ea-...user_sid => ...\Claude_pzs8sxrjxfjjc\SystemAppData\Helium\User.dat
• An exclusive-share open of User.dat fails (file is locked)
• Yet elevated handle64 -a "User.dat", handle64 -a "REGISTRY\WC", and handle64 -a "Silo045431ea" all return "No matching handles found"

The hive is held entirely by the kernel (Configuration Manager / container virtual-registry layer) on behalf of the silo. There is never a user-mode handle to find, even when everything is working. So when the silo fails to tear down after the old instance exits, the leaked lock is invisible to Process Explorer, handle64, Resource Monitor, and Restart Manager — and no taskkill incantation can release it directly.

This explains the folklore in this thread: killing tail.exe / node.exe / powershell.exe / everything "works" only when it happens to terminate the last process still associated with the old container, letting the silo tear down and the kernel unload the hive. When the teardown is already wedged (my case: nothing visibly running, still broken), nothing short of a reboot clears it, because shutdown force-unloads all hives.

Root cause (hypothesis, but well-constrained)

The update/relaunch flow ends the old app instance without guaranteeing its AppX container (job + registry silo) is fully torn down before the next activation:

1. CoworkVMService is an AutoStart, LocalSystem packaged service whose binary lives inside the versioned package directory (WindowsApps\Claude_1.22209...\app\resources\cowork-svc.exe). It starts at boot (~10 s after logon on my machine, before any app launch) and is associated with the package's job/silo — exactly as analyzed in #57221. The MSIX update lifecycle does not stop it.
2. The app also spawns other package-associated processes (cowork-svc per-user instances, ChromeNativeHost respawned by the browser, Claude Code session children). Any survivor keeps the old silo alive; an unclean teardown ordering leaves the user hive load in a wedged state.
3. Next activation must create a fresh container and RegLoadKey the same User.dat → SHARING VIOLATION → Event 215 0x80070020 → misleading "file in use" dialog.

Suggested fixes (Anthropic-side)

1. Make CoworkVMService demand-start and have the app start/stop it, or move its binary out of the versioned package path. (Same recommendation as #57221 — it was closed without response.)
2. In the updater, before swapping packages: stop CoworkVMService, terminate every process associated with the package's containers, and verify teardown completed before proceeding — e.g. poll until ...\SystemAppData\Helium\User.dat can be opened with ShareMode: None, which is a direct probe of "is the hive unloaded."
3. In the launcher, detect the failure instead of surfacing the shell dialog: activation failing with 0x80070020 / Event 215 has exactly one meaning here. Catch it and either retry after teardown, or tell the user plainly: "A previous instance's container hasn't been released by Windows; restart your PC" — instead of letting them hunt for a file lock that cannot be found.

For other users hitting this — confirm you have the same root cause

Run this in PowerShell while the launch is failing:

$p = "$env:LOCALAPPDATA\Packages\Claude_pzs8sxrjxfjjc\SystemAppData\Helium\User.dat"
try { ([System.IO.File]::Open($p,'Open','Read','None')).Close(); "hive released - launch should work" }
catch { "hive still loaded (kernel lock) - this bug" }

and check Event Viewer → Applications and Services Logs\Microsoft\Windows\AppModel-Runtime\Admin for Event 215 / 0x80070020. If the probe says the hive is loaded and nothing Claude-related is running, no amount of process-killing will help — reboot, and add your confirmation here.

Full ProcMon PML captures, Sysmon timeline, and event log exports are available; happy to provide them to Anthropic through a private channel (they can contain command lines). Ref: my support thread https://claude.ai/chat/7951cbb0-1526-48ed-bd6c-b5f816a221d7

Press Win+R → type services.msc → Enter (this opens a GUI window, not a terminal). Scroll to the letter C and you should see Claude there, it has a loop that sometimes just keeps looping and opening the cowork.msc so:

Right-click the Claude service → Properties
Startup type dropdown → Disabled → Apply
Now click Stop → OK

If you cant disable the automatic button, disable it via regedit

Win+R → regedit → Enter (accept the UAC prompt)
Navigate to:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\CoworkVMService
Double-click the Start value in the right pane → change it from 2 to 4 (4 = Disabled) → OK
Back in services.msc → right-click Claude → Stop. It can no longer trigger-start.

Press Win+R → type services.msc → Enter (this opens a GUI window, not a terminal). Scroll to the letter C and you should see Claude there, it has a loop that sometimes just keeps looping and opening the cowork.msc so: Right-click the Claude service → Properties Startup type dropdown → Disabled → Apply Now click Stop → OK If you cant disable the automatic button, disable it via regedit Win+R → regedit → Enter (accept the UAC prompt) Navigate to: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\CoworkVMService Double-click the Start value in the right pane → change it from 2 to 4 (4 = Disabled) → OK Back in services.msc → right-click Claude → Stop. It can no longer trigger-start.

does not work, once I click Claude app, it switches back to automatic

> Press Win+R → type services.msc → Enter (this opens a GUI window, not a terminal). Scroll to the letter C and you should see Claude there, it has a loop that sometimes just keeps looping and opening the cowork.msc so: > Right-click the Claude service → Properties Startup type dropdown → Disabled → Apply Now click Stop → OK > If you cant disable the automatic button, disable it via regedit > Win+R → regedit → Enter (accept the UAC prompt) Navigate to: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\CoworkVMService Double-click the Start value in the right pane → change it from 2 to 4 (4 = Disabled) → OK Back in services.msc → right-click Claude → Stop. It can no longer trigger-start. does not work, once I click Claude app, it switches back to automatic

You are right, it switches back to automatic and relaunches cowork for some reason, I restarted after applying those changes hence why i didn't notice. If you dont use cowork disabling the virtual sd would fix it I guess but right now I think a restart is much easier and faster then spending multiple minutes building some DIY fix that might clash with a patch in the future and cause more headache. Thats if this 1T dollar company finally patches this 1yr+ old bug.

Why is the problem being ignored? Perhaps it would be worth sending a letter to the company itself?

The same issue during a lot of releases.
Come on, fix it with Claude Code!

this is still an issue

Win11 zh-TW repro + workaround (stantheman0128)

Environment

• OS: Windows 11 (build 26200), locale zh-TW
• Install: Claude Desktop (MSIX / Store-style)
• Symptom: after in-app Relaunch or normal quit + reopen, dialog says another program is using the file / session port blocked; only reboot clears it (matches #42776 / #76357 family)

What I tried before reboot

1. Fully quit tray + Task Manager end Claude.exe
2. Stop-Service CoworkVMService -Force + kill cowork-svc.exe (when service exists)
3. Still fails until reboot (suggests orphaned AppContainer Job / Silo path per #53247 on some machines)

Workaround script (local, not deleting user data):

# See gist-style steps: stop CoworkVMService, taskkill claude/cowork-svc, check netstat, relaunch
Stop-Service CoworkVMService -Force -ErrorAction SilentlyContinue
taskkill /F /IM claude.exe /T
taskkill /F /IM cowork-svc.exe /T

Ask

• Updater should stop companion service + release package handles before MSIX swap (as noted in #42776).
• On startup, detect stale Job/Silo and self-heal without requiring reboot when possible.

Happy to attach Event Viewer AppModel-Runtime 215/208 + handle.exe snapshot on next repro if useful.

Still reproducing on 1.25927.0.0 (Windows 11 Pro 10.0.26200, MSIX/Store build). Adding Windows Event Log evidence, because I think what this thread has been missing is proof of where in the update sequence the ordering breaks — which may be why it's carrying an invalid label despite 116 comments.

Windows itself names the cause. Microsoft-Windows-AppXDeploymentServer/Operational, Event ID 658 (Warning), twice on a single update:

2026-08-04 23:14:41  Marking package {Claude_1.25927.0.0_x64__pzs8sxrjxfjjc} for deferred
                     registration because {Claude_1.24012.11.0_x64__pzs8sxrjxfjjc} is still running.
2026-08-04 23:34:45  (same, repeated)

The updater does not stop the old package before swapping it. Everything else in this thread is downstream of that.

The service then dies uncleanly. System log, Event 7034 "The Claude service terminated unexpectedly" — five times in two months, each within seconds of an Event 7045 (service re-installed at a new version path) and 7040 (start type flipped Auto → Disabled):

2026-08-04 13:40:39  7045  Service installed: "…\Claude_1.24012.11.0_…\app\resources\cowork-svc.exe"
2026-08-04 13:40:39  7040  start type changed from Auto to Disabled
2026-08-04 13:40:43  7034  The Claude service terminated unexpectedly. (occurrence 1)
2026-08-04 23:18:17  7034  (occurrence 2)

Also: 2026-07-26 15:19:23, 2026-07-22 01:33:39, 2026-07-19 11:36:43.

Two things make the failure silent, which explains the "I click the icon and nothing happens" reports:

> sc.exe qc CoworkVMService
    ERROR_CONTROL : 0   IGNORE

> sc.exe qfailure CoworkVMService
    RESET_PERIOD (in seconds) : 0     ← no recovery actions at all

And in C:\ProgramData\Claude\Logs\cowork-service.log, at every service start without exception:

Warning: failed to open service for recovery config: Access is denied.

So cowork-svc.exe tries to self-configure SERVICE_FAILURE_ACTIONS at runtime, lacks SERVICE_CHANGE_CONFIG on its own service under MSIX, and gives up silently. Its recovery behaviour is whatever SCM defaults to — not what the code intends.

The VM is never shut down gracefully, so state is left dirty for the next start:

[VM] Graceful shutdown failed, forcing termination:
     HcsShutdownComputeSystem failed with HRESULT 0x0/0x80070032

0x80070032 = ERROR_NOT_SUPPORTED. The guest boots with console=ttyS0 … panic=10 and no ACPI shutdown path, so that call can never succeed — every VM stop is a hard power-off.

Supporting signals: winsrvext Event 101 — claude.exe … is delaying system shutdown after 5000 milliseconds; EBUSY: resource busy or locked copying chrome-native-host.exe out of the package dir; Application Hang (1002) on claude.exe. 13 claude.exe processes are live on this machine right now, the oldest having survived several close/reopen cycles. 39 service reinstalls here between 2026-06-10 and 2026-08-04 — roughly one exposure to this every 1–2 days.

Full write-up with reproduction steps, the remaining event excerpts, a code-signing bug found along the way (WinVerifyTrust 0x800B0109, plus a cert subject that changed from Anthropic, PBC to Anthropic PBC between two consecutive releases), and six concrete fix suggestions: #83968.

Related and closed as duplicate with no linked target: #42897, #36590. Closed as completed but still reproducing: #46179.

Still reproducing (2026-08-05) — Event Log confirmation

Win11 26200 zh-TW, MSIX. In-app Relaunch from 1.24012.11.0 → 1.25927.0.0:

1. AppXDeploymentServer Event 658 (16:27): new package deferred because old package still running
2. Relaunch → dialog “Another program is currently using this file.” (path under WindowsApps\Claude_1.25927.0.0_…)
3. AppModel-Runtime Event 215 + 208 at the same second: 0x80070020 container/LaunchProcess failure
4. Helium User.dat remains exclusively locked; Stop-Service + process kill + AppX re-register did not recover — only reboot left

Full write-up with the same evidence posted on #83968 (please keep that one as the evidenced track; this thread’s invalid label doesn’t match the Event Log).

I hit this same failure on Windows 11 Home (26200) with Claude Desktop 1.24012.9.0 (MSIX, Claude_pzs8sxrjxfjjc) and was able to dig to what looks like the actual root cause. It's deeper than an orphaned process holding the exe: the app's Desktop Bridge container registry hives get leaked, and every subsequent launch fails until reboot.

Symptom. After the app closed abnormally (in my case around July 27), launching from the Start menu did nothing — no window, no visible error. Microsoft-Windows-TWinUI triggered the auto-repair path (RegisterByPackageFullName with RepairAppRegistrationOption), which succeeded, but activation still failed. Every attempt logged this pair in Microsoft-Windows-AppModel-Runtime/Admin (twice per attempt):

Event 215, Error: 0x80070020: Cannot create the Desktop AppX container for package
  Claude_1.24012.9.0_x64__pzs8sxrjxfjjc because an error was encountered converting the job.
Event 208, Error: 0x80070020: Cannot create the process for package
  Claude_1.24012.9.0_x64__pzs8sxrjxfjjc because an error was encountered while configuring runtime. [LaunchProcess]

0x80070020 = ERROR_SHARING_VIOLATION, which matches the "Another program is currently using this file" popup in the original report.

Root cause evidence. With zero Claude processes alive (verified via Win32_Process), HKLM\SYSTEM\CurrentControlSet\Control\hivelist still contained five mounted container-silo hives pointing at the package's Helium state files:

\REGISTRY\WC\Silo2abf9767-...software      -> ...\ProgramData\Packages\Claude_pzs8sxrjxfjjc\<SID>\SystemAppData\Helium\Cache\7b183c2962702791.dat
\REGISTRY\WC\Silo2abf9767-...user_sid      -> ...\AppData\Local\Packages\Claude_pzs8sxrjxfjjc\SystemAppData\Helium\User.dat
\REGISTRY\WC\Silo2abf9767-...user_classes  -> ...\AppData\Local\Packages\Claude_pzs8sxrjxfjjc\SystemAppData\Helium\UserClasses.dat
\REGISTRY\WC\Silo8e8d10bd-...com           -> ...\Helium\Cache\7b183c2962702791_COM15.dat
\REGISTRY\WC\Silo2abf9767-...com           -> ...\Helium\Cache\7b183c2962702791.dat

These are the hives Windows mounts when it creates the app's Desktop AppX container; they should be unmounted when the container is destroyed. Two dead containers left them mounted, so every new container creation collided with the existing mounts -> sharing violation -> launch dead until reboot.

Things that did NOT fix it (may save others some time):

• Killing the leftover chrome-native-host.exe from the browser extension.
• Stopping the packaged CoworkVMService — SCM refuses reconfiguration of packaged services even elevated, activation restarts it, and the launch still failed while I held it dead with a kill loop, so the service is a bystander, not the cause.
• The automatic package re-registration/ACL repair that TWinUI performs.
• NtUnloadKey2 on the stale hives as elevated admin — returns 0xC0000022 (ACCESS_DENIED).

Workaround that works without a reboot: run NtUnloadKey2(..., REG_FORCE_UNLOAD) on the stale \REGISTRY\WC\Silo* hives as SYSTEM (e.g., via a scheduled task) with SeRestore/SeBackup privileges. Four of the five unloaded with STATUS_SUCCESS (one COM cache hive returned 0xC0000121 STATUS_CANNOT_DELETE), and the app launched normally on the very next attempt.

Suggestion: whatever tears the app down on Relaunch/close (or crashes during it) is destroying the container without its hives getting unmounted. On startup, the app could detect this state (activation failing 0x80070020 + stale \REGISTRY\WC\Silo* entries referencing its own package family) and surface a real error or self-heal, instead of silently failing until the user reboots. Happy to provide full event log excerpts if useful.

gannonlawlor here's a fix based on your share. Thank you!
Run the batch file as administrator.

claude-code-fix.zip

Getting this with version Claude_1.32352.1.0_x64

I don't think it's a big ask to have a "Relaunch" button that works.

The latest version seems to finally work for me now, with it updating and
launching correctly.

On Tue, Aug 18, 2026, 9:32 AM chk-mk @.***> wrote:

chk-mk left a comment (anthropics/claude-code#42776) <https://github.com/anthropics/claude-code/issues/42776#issuecomment-5325034090> Getting this with version Claude_1.32352.1.0_x64 I don't think it's a big ask to have a "Relaunch" button that works. — Reply to this email directly, view it on GitHub <https://github.com/anthropics/claude-code/issues/42776?email_source=notifications&email_token=B6QRK3RVDKY5IEE63E4NK4L5KQA7XA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTKMZSGUYDGNBQHEYKM4TFMFZW63VHMNXW23LFNZ2KKZLWMVXHJLDGN5XXIZLSL5RWY2LDNM#issuecomment-5325034090>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/B6QRK3XVK7JUJ467V6NALFD5KQA7XAVCNFSNUABFKJSXA33TNF2G64TZHM4TGNZSGUZTINZVHNEXG43VMU5TIMJZGY4DGNZSHA2KC5QC> . You are receiving this because you commented.Message ID: @.***>

Why is such a huge company unable to fix a bug like this after several years?
I just encountered another critical error: Claude restarts itself to update without my permission, but then fails to launch due to an error, forcing me to reboot my PC—all just because Claude decided to restart on its own. What kind of nonsense is this? Do the developers even look at what they're doing?!

i have this issue too , my workaround is manually finding any child process claude code had started in previous run and killing them

I imagine this issue might fly under the radar and not get solved as this ticket is labeled invalid and assigned nobody and other tickets with the issue are marked as a duplicate of this one.
@RonGamzu It might be worth deleting this post - it might be soft-locking its resolution. Or fixing it if possible

I am blocked by this issue. I am using the updated version of Claude code, and still see the issue.

<img width="432" height="146" alt="Image" src="https://github.com/user-attachments/assets/809bcb58-7ea3-4082-8e80-c24fccf3318a" />

Can Anthropic fix it as soon as possible?

Even if I kill running claude process and restart it, the issue doesn't go away

When it was been fixed??? Every update I need to reboot my PC and update automatic restart app, without my access!

Yes I'm still having the same issue. It wasn't fixed

On Fri, Aug 21, 2026, 11:31 AM Michael Rozshko @.***>
wrote:

NeiroNext left a comment (anthropics/claude-code#42776) <https://github.com/anthropics/claude-code/issues/42776#issuecomment-5368119496> When it was been fixed??? Every update I need to reboot my PC and update automatic restart app, without my access! — Reply to this email directly, view it on GitHub <https://github.com/anthropics/claude-code/issues/42776?email_source=notifications&email_token=B6QRK3REY5L6CPUZ6VCTXQ35LAJIRA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTKMZWHAYTCOJUHE3KM4TFMFZW63VHMNXW23LFNZ2KKZLWMVXHJLDGN5XXIZLSL5RWY2LDNM#issuecomment-5368119496>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/B6QRK3THVWR2IZDRW3AWZK35LAJIRAVCNFSNUABFKJSXA33TNF2G64TZHM4TGNZSGUZTINZVHNEXG43VMU5TIMJZGY4DGNZSHA2KC5QC> . You are receiving this because you commented.Message ID: @.***>

Update: the current source-only workaround is here:

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

I have now verified the latest version in a real update, not only with static tests: Claude Desktop updated from 1.32885.1.0 to 1.34493.0.0 on Windows 11 Pro x64 build 26200, the new package reported Status: Ok, and Claude relaunched without a reboot.

The main BAT warns first and waits for Enter, then closes Claude and Chrome, disables/stops CoworkVMService, removes its respawn trigger, closes package-resident processes, checks the Helium\User.dat lock before AppX registration, and registers the already-staged newer package directly. If Windows still holds the Claude Silo hive, it has a guarded backup-first SYSTEM recovery path. Cowork is intentionally left Disabled + Stopped afterward; fix-restore-service.bat restores it if needed.

The repository contains readable source files and a non-destructive !fix-install-now.bat --self-test; no ZIP is being distributed. If reboot/sign-out is the only workaround currently working for you, please try this version and report the final lines from %TEMP%\cowork-install-now.log if it still fails.

I can't update at all, and when claude decides to update itself, that means a full system reboot.

At least for me, the update mechanism on windows is ENTIRELY broken, and has been for at least two months, if not longer.

I think I was able to get over it for a few times just reinstalling Claude Code, but now I also need to reboot after it decided to update itself and broke mid remote session :(
Killing Claude/cowork-svc.exe does not change anything for me.

I’ve experienced this issue numerous times over the past few weeks. Whenever Claude updated or crashed, I couldn’t reopen it without restarting my PC. I just came across a Reddit thread suggesting killing Node processes in Task Manager. I tried that after the latest update and Claude opened immediately. It seems like unrelated Node processes may be getting stuck and preventing Claude from restarting properly after an update.

I’ve experienced this issue numerous times over the past few weeks. Whenever Claude updated or crashed, I couldn’t reopen it without restarting my PC. I just came across a Reddit thread suggesting killing Node processes in Task Manager. I tried that after the latest update and Claude opened immediately. It seems like unrelated Node processes may be getting stuck and preventing Claude from restarting properly after an update.

The very frustrating problem is that it depends entirely on which processes Claude had active at the time of auto updating. If it was Node, there is a Node process to kill, if it was Python, there is a Python process to kill, etc.
Unless Anthropics adds some system to track the processes started by Claude and kill them when Claude exits (i.e. right before updating, or when quitting the app/a session) this issue will remain, as it's not immediately evident which processes you should kill from task manager.

For me, also happens again and again, every day:
Yes, there was a backend server running started by claude in the background - after the crash, restart does not work with the error message we are all familiar with.
<img width="270" height="94" alt="Image" src="https://github.com/user-attachments/assets/65252ed8-2541-44c4-abbc-22332acc7d35" />
Unfortunately killing the node process or any open python process does not resolve it. I have to restart the computer every time, which sucks.

I found the easiest way to get around it is to give codex full access, then tell it to kill all claude processes and paste in a screen-shot of the popup.

Codex has never had an issue with this (meaning both killing claude and updating itself) - with claude desktop I can only click the upgrade button when I want to restart the PC (which I almost never do...)

Codex tells me the hidden lock was this time in claude's CoworkVMService (cowork-svc.exe), which was running as a system service.
(for the full analysis, check my comment on #73107 )

I put together this PowerShell workaround for the stuck Claude Desktop/Cowork processes. It stops the processes holding the lock, repairs the Claude AppX registration, and then relaunches Claude Desktop.

Add this to your PowerShell profile:

function Repair-ClaudeDesktopUpdate {
    [CmdletBinding()]
    param(
        [switch]$NoLaunch
    )

    $identity = [Security.Principal.WindowsIdentity]::GetCurrent()
    $principal = [Security.Principal.WindowsPrincipal]::new($identity)
    $isAdmin = $principal.IsInRole([Security.Principal.WindowsBuiltInRole]::Administrator)
    if (-not $isAdmin) {
        Write-Warning "Run Windows Terminal as Administrator for CoworkVMService and AppX repair. Process cleanup will still be attempted."
    }

    $service = Get-Service -Name CoworkVMService -ErrorAction SilentlyContinue
    if ($service -and $service.Status -ne 'Stopped') {
        Write-Host "Stopping CoworkVMService..."
        try {
            Stop-Service -Name CoworkVMService -Force -ErrorAction Stop
        } catch {
            Write-Warning "Failed to stop CoworkVMService: $($_.Exception.Message)"
        }
        Start-Sleep -Seconds 2
    }

    $currentPid = $PID
    $targetNames = @('Claude.exe', 'cowork-svc.exe', 'parsecd.exe', 'node_repl.exe')
    $targets = Get-CimInstance Win32_Process | Where-Object {
        if ($_.ProcessId -eq $currentPid) { return $false }

        $exe = [string]$_.ExecutablePath
        $cmd = [string]$_.CommandLine
        $name = [string]$_.Name

        $packageProcess = $exe -like 'C:\Program Files\WindowsApps\Claude_*'
        $claudeUserProcess = (
            $exe -like "$env:APPDATA\Claude\*" -or
            $exe -like "$env:LOCALAPPDATA\Claude\*" -or
            $exe -like "$env:LOCALAPPDATA\Packages\Claude_pzs8sxrjxfjjc\*"
        )
        $knownProcess = $name -in $targetNames
        $nativeHost = $name -eq 'chrome-native-host.exe' -and (
            $claudeUserProcess -or
            $cmd -match 'ChromeNativeHost|Claude_pzs8sxrjxfjjc'
        )
        $commandLineMatch = $cmd -match 'Claude_pzs8sxrjxfjjc|cowork-svc|ChromeNativeHost|node_repl'

        $packageProcess -or $claudeUserProcess -or $knownProcess -or $nativeHost -or $commandLineMatch
    } | Sort-Object ProcessId -Unique

    foreach ($target in $targets) {
        Write-Host ("Stopping {0} PID {1}" -f $target.Name, $target.ProcessId)
        try {
            Stop-Process -Id $target.ProcessId -Force -ErrorAction Stop
        } catch {
            Write-Warning ("Failed to stop {0} PID {1}: {2}" -f $target.Name, $target.ProcessId, $_.Exception.Message)
        }
    }

    $pkg = Get-AppxPackage -Name Claude -ErrorAction SilentlyContinue | Select-Object -First 1
    $family = if ($pkg) { $pkg.PackageFamilyName } else { 'Claude_pzs8sxrjxfjjc' }

    Write-Host "Repairing Claude AppX registration for $family..."
    try {
        Add-AppxPackage -RegisterByFamilyName -MainPackage $family -ForceApplicationShutdown -ErrorAction Stop
    } catch {
        Write-Warning "Claude AppX repair failed: $($_.Exception.Message)"
    }

    if (-not $NoLaunch) {
        Write-Host "Launching Claude Desktop..."
        Start-Process explorer.exe -ArgumentList "shell:AppsFolder\$family!Claude"
    }
}

Set-Alias fix-claude Repair-ClaudeDesktopUpdate

Run it from an elevated PowerShell terminal:

fix-claude

To clean up and repair without relaunching:

Repair-ClaudeDesktopUpdate -NoLaunch

This is a workaround rather than a permanent fix for the orphaned-process issue.

If you do not want to modify your PowerShell profile, download the standalone script archive below.

Repair-ClaudeDesktop.zip

Extract Repair-ClaudeDesktop.ps1 and put it somewhere convenient, for example:

$HOME\Scripts\Repair-ClaudeDesktop.ps1

Run it from an elevated PowerShell terminal:

& "$HOME\Scripts\Repair-ClaudeDesktop.ps1"

Run it without relaunching Claude Desktop:

& "$HOME\Scripts\Repair-ClaudeDesktop.ps1" -NoLaunch

most of the times, i found ending 'grep' and 'tail' in the task manager fix this issue.

If you do not want to modify your PowerShell profile, download the standalone script archive below. Repair-ClaudeDesktop.zip Extract Repair-ClaudeDesktop.ps1 and put it somewhere convenient, for example: `` $HOME\Scripts\Repair-ClaudeDesktop.ps1 `` Run it from an elevated PowerShell terminal: & "$HOME\Scripts\Repair-ClaudeDesktop.ps1" Run it without relaunching Claude Desktop: & "$HOME\Scripts\Repair-ClaudeDesktop.ps1" -NoLaunch

Does not work for me unfortunately, still get the same error afterwards

<img width="352" height="125" alt="Image" src="https://github.com/user-attachments/assets/498e977e-611d-4cff-99a6-34440dc76359" />

Add me to the list of unhappy folks.
FWIW:

• ​CoworkVMService is present (2x) in Task Manager Services, but both are stopped.
• resmon shows nothing.
• Entering taskkill /F /IM claude.exe /T returns: ERROR: The process "claude.exe" not found.

same here , still this bug. tried all, kill powershell,node,python,claude.

FWIW, as a somewhat hacky workaround, I had Cursor create a PowerShell
script that can diagnose and (potentially) repair the condition. Apparently
sometimes a reboot will still be required, but I'm hoping that this will
resolve the simpler lockouts.

On Fri, Aug 28, 2026 at 1:56 AM ma-gu-16 @.***> wrote:

ma-gu-16 left a comment (anthropics/claude-code#42776) <https://github.com/anthropics/claude-code/issues/42776#issuecomment-5449953013> same here , still this bug. tried all, kill powershell,node,python,claude. — Reply to this email directly, view it on GitHub <https://github.com/anthropics/claude-code/issues/42776?email_source=notifications&email_token=AKN2O2EHSBGQ7R47UQOWU735ME3KNA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTKNBUHE4TKMZQGEZ2M4TFMFZW63VHMNXW23LFNZ2KKZLWMVXHJLDGN5XXIZLSL5RWY2LDNM#issuecomment-5449953013>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AKN2O2F4BTSSZ5W2FFZ54E35ME3KNAVCNFSNUABFKJSXA33TNF2G64TZHM4TGNZSGUZTINZVHNEXG43VMU5TIMJZGY4DGNZSHA2KC5QC> . Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS <https://github.com/notifications/mobile/ios/AKN2O2DF5K45XEQALD5NLD35ME3KNA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTKNBUHE4TKMZQGEZ2M4TFMFZW63VHMNXW23LFNZ2KKZLWMVXHJKTGN5XXIZLSL5UW64Y> and Android <https://github.com/notifications/mobile/android/AKN2O2GZRYS7TQ3E6CMFIXT5ME3KNA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTKNBUHE4TKMZQGEZ2M4TFMFZW63VHMNXW23LFNZ2KKZLWMVXHJLTGN5XXIZLSL5QW4ZDSN5UWI>. Download it today! You are receiving this because you commented.Message ID: @.***>