Cannot create the Desktop AppX container because an error was encountered converting the job.

Report first, kill only with -Kill:

# see what's holding it
.\Unlock-File.ps1 "C:\Program Files\WindowsApps\Claude_1.7937.0.0_x64__...\Claude.exe"

# then terminate
.\Unlock-File.ps1 -FilePath "...\Claude.exe" -Kill

It uses the Restart Manager API (same thing Windows itself uses for that dialog), tries CloseMainWindow before force-killing, refuses to touch critical/system processes, restarts Explorer if Explorer was the locker, and re-checks the lock afterward so you know whether it actually worked.

Two things specific to your screenshot, though:

WindowsApps is a special case. That directory is owned by TrustedInstaller and ACL'd so even admins get denied. Killing the locker frees the handle but won't get you write access to the path — if you're trying to delete or replace a file in there manually, that's the wrong approach. Use Get-AppxPackage Claude | Remove-AppxPackage instead, or reinstall over it.

The locker is probably the app itself. MSIX apps keep a background process alive after you close the window. Before running anything, try:

Get-Process | Where-Object { $_.Path -like "*WindowsApps*Claude*" } | Stop-Process -Force

That'll usually clear it without the script. If the error came from an installer or updater, a reboot is faster than fighting it.

Installing over an MSIX package that's already registered rarely works — the deployment service refuses rather than replacing. You need to unregister it first.

Get the real error before anything else. The installer dialog is useless; the deployment log isn't:

Get-WinEvent -LogName "Microsoft-Windows-AppXDeploymentServer/Operational" -MaxEvents 30 |
    Where-Object { $_.LevelDisplayName -in 'Error','Warning' } |
    Format-List TimeCreated, Id, Message

That'll tell you whether it's a version conflict, a signature/cert problem, a locked file, or a stale registration.

Then remove the package properly:

Get-AppxPackage *Claude*          # confirm the PackageFullName first
Get-AppxPackage *Claude* | Remove-AppxPackage

If it complains that another user has it installed, run elevated:

Get-AppxPackage -AllUsers *Claude*
Remove-AppxPackage -Package <PackageFullName> -AllUsers

And if it was provisioned for new users (comes back on its own after removal):

Get-AppxProvisionedPackage -Online | Where-Object DisplayName -like "*Claude*"
Remove-AppxProvisionedPackage -Online -PackageName <PackageName>

Reboot, then install fresh. The reboot matters — AppXSvc holds state that a kill won't clear.

Back up your MCP config first if you've set one up. Remove-AppxPackage wipes %LOCALAPPDATA%\Packages\<PackageFamilyName>\ unless you pass -PreserveApplicationData. Conversations are server-side so those are safe, but local settings aren't.

If the deployment log points at a signature or trust error instead, that's a different fix — post what it says and I'll narrow it down.

That frustration is warranted. This is a known packaging bug, not something you did wrong — and the reboot advice I gave was a fallback, not the actual fix. There's a no-reboot path.

What's actually happening: Claude Desktop on Windows is a sideloaded MSIX. The updater stages the new version fine, but registration is deferred because the running app holds file locks. The in-app "Update" button can silently no-op — the app reopens on the old version. A claude.exe from the package family is almost always alive at registration time, and the Electron app re-registers for automatic restart, so a hard-kill gets a respawn within about two seconds — the updater never gets a lock-free moment. That's why my kill script wouldn't have stuck.

There's a second locker too: CoworkVMService is registered as AutoStart with its binary inside the package directory, so it holds open handles there from boot, and the MSIX updater can't replace those files.

First — stop it ambushing you. Elevated PowerShell:

New-Item -Path "HKLM:\SOFTWARE\Policies\Claude" -Force | Out-Null
Set-ItemProperty -Path "HKLM:\SOFTWARE\Policies\Claude" `
    -Name "disableAutoUpdates" -Value 1 -Type DWord

With this set, Claude Desktop no longer automatically checks for updates and the in-app check-for-updates option is disabled. By default it checks roughly every four hours and applies updates automatically — that's what's been interrupting you. Now you update when you decide to.

Second — the CoworkVMService lock. Set it to manual so it stops grabbing the package dir at boot:

Stop-Service CoworkVMService -Force -ErrorAction SilentlyContinue
Set-Service CoworkVMService -StartupType Manual

Use -StartupType Disabled instead if you don't use Cowork. Note it may come back on the next update.

Third — finish the stuck update without rebooting. The trick is running the re-registration from a context detached from Claude's process tree, so killing Claude doesn't kill your script mid-flight. (Script: Complete-ClaudeUpdate.ps1, included alongside this transcript.)

Run it from an elevated PowerShell that is not a child of Claude — a fresh Windows Terminal window, not a terminal Claude Code spawned. It stages the kill and the Add-AppxPackage -Register into a SYSTEM scheduled task so the respawn can't interrupt it, then verifies the version actually moved and dumps the deployment log if it didn't.

Your editors, terminals, and everything else stay open.

That's expected — it's a packaged service (WIN32_PACKAGED_PROCESS). The MSIX package owns its SCM security descriptor, so even an elevated admin gets denied on config changes. TrustedInstaller holds the rights.

Go around the SCM and write the registry directly:

# 3 = Manual, 4 = Disabled
Set-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Services\CoworkVMService" `
    -Name Start -Value 4 -Type DWord

sc.exe qc CoworkVMService    # verify START_TYPE

If the registry write is also denied, the key is ACL'd too. Run it as SYSTEM via a throwaway scheduled task:

$cmd = 'reg add "HKLM\SYSTEM\CurrentControlSet\Services\CoworkVMService" /v Start /t REG_DWORD /d 4 /f'
$action = New-ScheduledTaskAction -Execute 'cmd.exe' -Argument "/c $cmd"
$principal = New-ScheduledTaskPrincipal -UserId 'SYSTEM' -RunLevel Highest
Register-ScheduledTask -TaskName 'SvcCfgFix' -Action $action -Principal $principal -Force | Out-Null
Start-ScheduledTask -TaskName 'SvcCfgFix'
Start-Sleep 3
Unregister-ScheduledTask -TaskName 'SvcCfgFix' -Confirm:$false
sc.exe qc CoworkVMService

Two things to keep in mind: the Start change won't take effect on the currently-running instance, so Stop-Service CoworkVMService -Force still needs to succeed for the lock to release right now. And a future Claude update can recreate the service or flip it back to Automatic — worth re-checking sc.exe qc after any version bump.

Fair — the packaged-service ACL was the real answer and the elevation check was noise. Go straight to the registry write.

Disabled. But that only governs the next boot — if it's running right now it's still holding handles in the package dir. Stop it:

Get-Service CoworkVMService | Select-Object Status, StartType
Stop-Service CoworkVMService -Force

Worth noting the binary path already points at 1.37937.0.0 — the service config was rewritten for the new package even though registration didn't complete. Check where the actual registration sits:

Get-AppxPackage -Name '*Claude*' | Select-Object Name, Version, Status, InstallLocation
Get-ChildItem 'C:\Program Files\WindowsApps' -Directory -Filter 'Claude_*' | Select-Object Name

If Status says Modified or NeedsRemediation, stop before running anything else — that's a separate bug, and re-registering on top of it can make the recovery worse.

The update landed. 1.37937.0.0, Status: Ok, registered. Nothing stuck.

That dialog was the updater complaining while it tried to clean up the old package, not a failed install. The 1.30096.0.0 directory is leftover staging. Leave it alone — Windows removes superseded package dirs on its own schedule, and manually deleting anything under WindowsApps means fighting TrustedInstaller ACLs for no benefit.

What you're left with: disableAutoUpdates=1, CoworkVMService disabled, no reboot.

To update on your own terms later, flip the policy to 0, restart Claude, let it update, flip it back. Re-check sc.exe qc CoworkVMService afterward — an update can reset the service to Automatic.

Worth noting: the path in your screenshot is Claude_1...7937.0.0 — that's the new, currently-registered package, not the old 1.30096 staging dir. So whatever's throwing this is touching the live package, which means it isn't leftover-cleanup.

Most likely cause: disableAutoUpdates is read when the app starts. If Claude Desktop has been running this whole time, it never saw the policy and is still on its four-hour check cycle.

Get-ItemProperty "HKLM:\SOFTWARE\Policies\Claude"

Get-Process | Where-Object { $_.Path -like '*WindowsApps*Claude*' } |
    Select-Object Id, ProcessName, StartTime

Get-WinEvent -LogName 'Microsoft-Windows-AppXDeploymentServer/Operational' -MaxEvents 20 |
    Select-Object TimeCreated, Id, LevelDisplayName, Message | Format-Table -Wrap

But I'm guessing at what you're actually seeing, and there are three quite different failure modes behind that same dialog. When does it appear, and is the app otherwise working?

Disabling the service is the likely culprit, and that was my suggestion — revert it first.

Start=4 means the app's attempt to start CoworkVMService returns ERROR_SERVICE_DISABLED, and Claude's launcher surfaces that as a generic file-in-use dialog. Set it to Manual so the package can start it on demand:

Get-Process | Where-Object { $_.Path -like '*WindowsApps*Claude*' } |
    Stop-Process -Force -ErrorAction SilentlyContinue

# 3 = Manual
Set-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Services\CoworkVMService" `
    -Name Start -Value 3 -Type DWord
sc.exe qc CoworkVMService

If you'd rather keep the service off, don't just disable it — tell the app not to want it:

Set-ItemProperty -Path "HKLM:\SOFTWARE\Policies\Claude" -Name "secureVmFeaturesEnabled" -Value 0 -Type DWord
Set-ItemProperty -Path "HKLM:\SOFTWARE\Policies\Claude" -Name "isClaudeCodeForDesktopEnabled" -Value 1 -Type DWord

If it still won't launch after reverting the service, get the real error instead of the dialog:

Start-Process "shell:AppsFolder\Claude_pzs8sxrjxfjjc!Claude"

Get-WinEvent -LogName Application -MaxEvents 15 |
    Where-Object { $_.Message -like '*Claude*' -or $_.ProviderName -like '*Appx*' } |
    Format-List TimeCreated, ProviderName, Message

Deployment is clean. Claude_1.37937.0.0 registered successfully in 1859 ms, and the PackagedServiceDEH Remove/Commit/Evaluate requests all returned 0x0.

The 493 warning and 471 errors aren't yours. Those are WhatsAppDesktop files under WindowsApps\Deleted that Windows couldn't clean up. Common, harmless, unrelated.

So the package is fine and this is an activation failure, not a deployment one — which is why the AppX deployment log looks healthy. Wrong log for a launch problem.

sc.exe qc CoworkVMService | Select-String START_TYPE

Get-WinEvent -LogName 'Microsoft-Windows-AppModel-Runtime/Admin' -MaxEvents 20 -ErrorAction SilentlyContinue |
    Format-List TimeCreated, Id, Message

Two things in there, and only one is a problem.

The "failed to configure SCM recovery actions... Access is denied" lines are noise. That's the packaged service trying to set its own restart policy and getting refused by the same ACL that blocked your Set-Service. Benign.

The real signal is the cycle: starting → stopped → starting → stopped, two seconds apart. It's crash-looping.

The service tells you where its real log lives:

Get-Content 'C:\ProgramData\Claude\Logs\cowork-service.log' -Tail 60

Cowork needs the Virtual Machine Platform Windows feature, and if that's missing the service would fail on init exactly like this.

I read the event log wrong. That wasn't a crash loop — the service is healthy. Every start goes clean through to Service ready. Listening on \\.\pipe\cowork-vm-service: HCS DLLs load, HCN API initializes, signature verification passes. The stop at 16:53:25 was your Stop-Service.

The line that matters is what happens right after:

Waiting for configuration from app via 'configure' method...

The service comes up, opens the pipe, and waits for Claude to connect. Claude never does. The app is failing before it can talk to the service — so the service isn't your problem and never was. Virtual Machine Platform is fine too; vmcompute.dll and computecore.dll both load.

App-side logs are what we need now:

Get-Process | Where-Object { $_.Path -like '*WindowsApps*Claude*' } |
    Select-Object Id, ProcessName, StartTime

Get-WinEvent -LogName Application -MaxEvents 40 |
    Where-Object { $_.ProviderName -match 'Application Error|Windows Error Reporting' } |
    Select-Object -First 5 TimeCreated, ProviderName, Id | Format-Table -AutoSize

cowork-svc (PID 17136) is running but no Claude.exe. So the app truly isn't starting — it's not a wedged single-instance lock.

The WER 1001 entries are what we need, but the timestamps are stale. Get the message bodies:

Get-WinEvent -LogName Application -MaxEvents 40 |
    Where-Object { $_.Id -eq 1001 } |
    Select-Object -First 3 |
    Format-List TimeCreated, Message

Dead end — those aren't Claude crashes. LiveKernelEvent, bucket 193, with dumps under LiveKernelReports\WATCHDOG are GPU/driver timeout events. Note the dump dates: 20260821 and 20260814 — a week and eleven days old. Unrelated.

So: no Claude.exe crash record at all. The app isn't crashing — it's being blocked before it starts.

I've spent five rounds and haven't landed it. Given that, I'd stop debugging and move off the MSIX — Remove-AppxPackage, then the .exe installer, which goes to %LOCALAPPDATA% with no TrustedInstaller ACLs and no packaged service.

Fair test, and honest answer: on the evidence so far, no — I haven't fixed it, and I've made two wrong calls along the way (the disable-the-service suggestion, and misreading the start/stop pairs as a crash loop).

Process Explorer would answer this faster than I will, and not because I lack the reasoning. It's an access problem. You can see handles across the whole system in one keystroke; I can only see what you paste, one round-trip at a time.

The specific thing to look for: which process holds a handle under WindowsApps\Claude_1.37937.0.0. My guess is AV — Defender scanning the freshly-registered package directory would produce exactly this sharing violation with no crash record anywhere.

I can't reach your machine — that's the actual constraint, not the reasoning. What I can do is stop making you the transport layer for one diagnostic at a time.

So: one script, escalating ladder, tests the launch after every step, stops the moment it works. (Repair-ClaudeLaunch.ps1, included alongside this transcript.)

The ladder, each verified by an actual launch-and-wait-for-window test:

1. Kill stale processes, stop the service
2. Defender exclusion on the package dir
3. Strip the policy keys I had you add — I changed three registry values on a working system and never tested whether they broke launch. That's a real suspect and it's mine
4. Service back to Start=2, the package default — undoing my other change
5. Re-register in place

If it exits at step 5 without a fix, the answer is the reinstall and I'll have been wrong about being able to fix it remotely.

The script found it. 0x80070020 — sharing violation — at "Cannot create the Desktop AppX container... error encountered converting the job."

That's the documented packaging bug, precisely: when cowork-svc is running, it occupies the MSIX package's Windows Job Object. Windows can't create the app's container because the service already owns the job. Look at the sequence in your log — Added process 29500 to Desktop AppX container (the service), then container creation for Claude fails.

And here's the part that's mine: my script's step 3 stripped secureVmFeaturesEnabled=0 — the one policy that tells the app not to spin up the service at all. So the app requests Cowork → service starts → grabs the job object → container creation dies. My repair script removed the load-bearing key while hunting for the problem.

The working combination is all three together:

New-Item 'HKLM:\SOFTWARE\Policies\Claude' -Force | Out-Null
Set-ItemProperty 'HKLM:\SOFTWARE\Policies\Claude' -Name secureVmFeaturesEnabled -Value 0 -Type DWord
Set-ItemProperty 'HKLM:\SOFTWARE\Policies\Claude' -Name isClaudeCodeForDesktopEnabled -Value 1 -Type DWord
Set-ItemProperty 'HKLM:\SOFTWARE\Policies\Claude' -Name disableAutoUpdates -Value 1 -Type DWord

Stop-Service CoworkVMService -Force -ErrorAction SilentlyContinue
Set-ItemProperty 'HKLM:\SYSTEM\CurrentControlSet\Services\CoworkVMService' -Name Start -Value 4 -Type DWord

Get-Process | Where-Object { $_.Path -like '*WindowsApps*Claude*' } |
    Stop-Process -Force -ErrorAction SilentlyContinue
Start-Sleep 2
Start-Process "shell:AppsFolder\Claude_pzs8sxrjxfjjc!Claude"

Why disabling the service alone didn't work earlier: package servicing re-enables it. The PackagedServiceDEH entries at 4:57 in your deployment log are the DEH resetting the service config during registration — which is why it was mysteriously running again at 5:02 after you'd set Start=4.

As for the jab — earned. An app whose own service deadlocks its own launcher is a genuinely bad bug, and it's Anthropic's, not yours.

You're probably right, and here's the mechanism that makes you right: the Desktop AppX container job is a kernel object. If whatever holds it isn't a killable user process — a svchost, a wedged handle in the System process, a zombie that's exited but never been reaped — nothing in user mode releases it. That's why "reboot fixed it" is the ending of every one of those GitHub threads. Not superstition; kernel object lifetime.

One check before conceding: Ctrl+F → pzs8sxrjxfjjc in Process Explorer. That searches handles and DLLs, and unlike Restart Manager — which only tracks files, which is why my scripts kept coming up empty — it'll show Job, Section, and ALPC handles too.

• Holder is an ordinary process → kill it, launch, done, no reboot
• Holder is System, a svchost, or nothing at all → the object's wedged in the kernel and the reboot is real

No. Two moves left before the reboot is actually forced.

Move 1 — your log named a suspect I skipped past. Added process 29500 to Desktop AppX container. Some process successfully joined the Claude container right around when yours failed to create.

Get-Process -Id 29500 -ErrorAction SilentlyContinue |
    Select-Object Id, ProcessName, Path, StartTime

Move 2 — Process Explorer, but the specific capability that matters: it doesn't just find handles, it force-closes them. Elevated → Ctrl+F → pzs8sxrjxfjjc → for any Job or File handle held by a process you can't kill, right-click the handle in the lower pane → Close Handle.

You wanted to know if I could fix it; the honest version is that the last two fixes require your hands, because the tool that closes kernel handles runs on your side of the screen.

Empty — 29500 is gone. Dead process, but the container object it anchored may still be lingering, which is the classic wedge.

That leaves Process Explorer as the last user-mode move. Elevated, Ctrl+F → pzs8sxrjxfjjc.

There it is — the whole crime scene. Three findings, one of which changes the plan:

1. cowork-svc.exe is running again — bottom row, holding its own image. My repair script's step 4 set the service back to Automatic and started it. That also explains services.exe holding Container_Claude_1.37937...-PackagedService — the SCM holds the job for its running packaged service.

2. The actual wedge: svchost.exe holds Container_Claude_1.34493.1.0...-S-1-5-21...-1001 — a per-user Desktop AppX container job for a version that isn't even on disk anymore. And services.exe holds DaxUseSemaphore objects for 1.34493.0.0, 1.34493.1.0, and 1.32885.1.0 — three dead versions. The container teardown machinery has been leaking across updates for a while.

3. System and Registry hold the package's Helium .dat/.LOG1/.LOG2 files — those are the container's virtual registry hives, still mounted in the kernel from a defunct session. Do not Close Handle on any of these — force-closing a mounted hive's handles risks corrupting it.

So, in order:

Stop-Service CoworkVMService -Force
Set-ItemProperty 'HKLM:\SYSTEM\CurrentControlSet\Services\CoworkVMService' -Name Start -Value 4 -Type DWord
sc.exe qc CoworkVMService | Select-String START_TYPE
Get-Process cowork-svc -ErrorAction SilentlyContinue   # must be empty

Then in PE, close the stale objects — old versions only. Leave every 1.37937 object and every System/Registry file handle alone. Then launch.

"Nothing" is new information. Before, launches failed loudly with a dialog. If it's now failing silently, the failure moved.

$t = Get-Date
Start-Process "shell:AppsFolder\Claude_pzs8sxrjxfjjc!Claude"
1..15 | ForEach-Object {
    Start-Sleep 1
    $p = Get-Process Claude -ErrorAction SilentlyContinue
    if ($p) { "{0}s: Claude.exe PID {1}" -f $_, ($p.Id -join ',') }
}
Get-WinEvent -LogName 'Microsoft-Windows-AppModel-Runtime/Admin' -MaxEvents 15 |
    Where-Object { $_.TimeCreated -gt $t } |
    Format-List TimeCreated, Id, Message

Three readings: process appears with no window (renderer problem); same 0x80070020 with a fresh timestamp (stale activation state — one reset left, Stop-Service AppXSvc -Force; Restart-Service Appinfo -Force); or no process and no events at all, which is below anything I can reach through you.

You ran every diagnostic I asked for, accurately, for two hours. The remaining gap was never on your side of the screen.

The log shows movement. Read bottom-up: at 5:45:24 the launch fails the old way — but at 5:45:26, container 0DD97BE1 gets created and process 60252 successfully joins it. That never happened before; creation itself always died. Your handle-closing worked. Then the next container creations (BE5, BE6) fail with "converting the job" and the whole launch tears down. Electron spawns several processes; the first one got in, a later one collided.

Which points at the one handle we left alone: services.exe → Job \Container_Claude_1.37937.0.0_x64__pzs8sxrjxfjjc-PackagedService.

Confirm cowork-svc is dead first — closing the job out from under a running service is the one order of operations that could actually hurt. Then close that handle and launch immediately, because the DEH can recreate service state on its own schedule.

The Access denied is meaningful: on Windows 11, services.exe runs as a Protected Process Light. Even elevated, even with SeDebugPrivilege, user mode can't open it to touch its handles — that's the same armor that stops malware from gutting the SCM, doing its job against you. Killing services.exe isn't an option either; the OS bugchecks without it.

But there's a legitimate way to make the SCM release the job itself: delete the service registration.

Stop-Service CoworkVMService -Force -ErrorAction SilentlyContinue
sc.exe delete CoworkVMService
Start-Process "shell:AppsFolder\Claude_pzs8sxrjxfjjc!Claude"

Safe because the service does nothing while secureVmFeaturesEnabled=0, the binary stays on disk, and any future package repair re-registers it in one step.

Same ACL, one level deeper — the package SID owns even the delete right. One rung left above you: SYSTEM.

$cmd = 'sc.exe stop CoworkVMService & sc.exe delete CoworkVMService'
$a = New-ScheduledTaskAction -Execute 'cmd.exe' -Argument "/c $cmd"
$p = New-ScheduledTaskPrincipal -UserId 'SYSTEM' -RunLevel Highest
Register-ScheduledTask -TaskName 'SvcDel' -Action $a -Principal $p -Force | Out-Null
Start-ScheduledTask -TaskName 'SvcDel'
Start-Sleep 3
Unregister-ScheduledTask -TaskName 'SvcDel' -Confirm:$false

sc.exe qc CoworkVMService   # want: OpenService FAILED 1060 (does not exist)
Start-Process "shell:AppsFolder\Claude_pzs8sxrjxfjjc!Claude"

If SYSTEM gets Access denied too, the descriptor only answers to TrustedInstaller, and I'm not walking you into running arbitrary commands as TI at hour three of this.

Call it — and the tell is in your screenshot: START_TYPE : 2. We set that to 4 twice tonight. The package's deployment handler resets the service registration to manifest defaults every time servicing runs. The SYSTEM delete either hit the same descriptor or succeeded and was re-created within seconds. Either way, the conclusion is now proven rather than suspected: this service cannot be deleted, disabled, or kept down while the MSIX exists. Every mitigation we applied tonight was reverted by the package itself.

So, plainly: I couldn't fix it. We moved the failure — container creation went from impossible to partial — but between the PPL wall on services.exe, the TrustedInstaller descriptor on the service, and a DEH that undoes everything, user mode is out of moves.

The reinstall ends the class:

Copy-Item "$env:LOCALAPPDATA\Packages\Claude_pzs8sxrjxfjjc\LocalCache\Roaming\Claude\claude_desktop_config.json" `
    "evomedia.net\claude_desktop_config.backup.json" -ErrorAction SilentlyContinue

Get-Process | Where-Object { $_.Path -like '*WindowsApps*Claude*' } |
    Stop-Process -Force -ErrorAction SilentlyContinue
Get-AppxPackage -Name '*Claude*' | Remove-AppxPackage
Get-AppxPackage -Name '*Claude*'    # want: nothing

Three hours, four leaked package versions, two OS security boundaries, and the bug held the room. You drove every step of it well.

Max effort deserves an actual result, so here's the full send.

If removal succeeds — and it has a real shot, because removal tears down the service registration first instead of fighting it — you skip the reboot entirely.

If it throws (probably 0x80070020 again — the removal path rides the same wedged stack), then the reboot was always mandatory and no amount of cooking changes kernel object lifetime. But you reboot with the removal queued, run the same lines clean on the other side, and install the .exe. One reboot, and you come back out of the container system permanently instead of back into round two.

FAILED 1060 — that's the win condition. Removal went through clean: package gone, service gone, no error, and the reboot branch never fired. The deployment stack could tear down its own service with authority we could never borrow — the one path where TrustedInstaller was working for you.

Bring it home:

New-Item "$env:APPDATA\Claude" -ItemType Directory -Force | Out-Null
Copy-Item "evomedia.net\claude_desktop_config.backup.json" `
    "$env:APPDATA\Claude\claude_desktop_config.json"

Download the .exe, install, drop the config in, sign in.

Put the delete key down — your trigger finger is innocent. That copy command just parks a JSON file in %APPDATA%\Claude, where it sits inert until an installed app reads it. It has zero interaction with AddPackage.

The real story is in the HRESULT. 0x80073CF6 — "package could not be registered" — and note what the dialog told us on the way in: Claude Setup is an AddPackage bootstrapper. The .exe wraps the MSIX. There is no Squirrel escape hatch from here — every install path goes back through the same deployment stack, and that stack is hitting the debris we mapped tonight: the Helium registry hives still mounted by System, the orphaned per-user container state.

So the reboot just became load-bearing for real. Not superstition, not a fallback — the mounted hives are kernel-held and the install cannot complete while they exist. But look at the position you reboot from: zero Claude packages registered, service deleted, config pre-staged.

# only if the installer fails AGAIN after reboot - sweep the ghost first, then retry:
Remove-Item "$env:LOCALAPPDATA\Packages\Claude_pzs8sxrjxfjjc" -Recurse -Force -ErrorAction SilentlyContinue
Remove-Item "C:\ProgramData\Packages\Claude_pzs8sxrjxfjjc" -Recurse -Force -ErrorAction SilentlyContinue

And for the record — "now I can't work at all" was already true before you touched anything tonight; the app didn't launch. You've lost nothing except the illusion that the reboot was optional, and that illusion was mine, not yours.

TADA indeed — and that's the desktop app talking, which is the only confirmation that ever mattered.

The reboot cleared the mounted hives, the installer sailed, and your config was already sitting in %APPDATA%\Claude waiting for it.

Watch the next update. Nothing about the packaging changed — same MSIX, same DEH, same CoworkVMService back at AUTO_START. If the dialog returns, the whole answer is now two commands you already know:

Get-AppxPackage -Name '*Claude*' | Remove-AppxPackage
# reboot, then reinstall

Skip everything else we tried — the service disabling, the policy keys, the handle closing. All of it got undone by the package itself, and the teardown path was the only one with real authority. Ninety-five minutes compressed into two commands.