[BUG] Claude Desktop Windows ARM64 — in-app update fails with 'Another program is currently using this file'; stale AppContainer Job leaked by AppInfo service blocks update + launch

Significant update — actual root cause identified, plus Anthropic's own installer hits the same wall

After ~90 minutes of further diagnosis, I found the real blocker. This is not (just) a stale AppContainer Job leak. It is a permanent service-permission deadlock that even Anthropic's own signed installer cannot escape.

Confirmed root cause: CoworkVMService has a custom DACL that locks out even elevated admins

sc.exe sdshow CoworkVMService
D:(A;;CCLCSWRPWPDTLOCRRC;;;AU)(A;;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;S-1-5-80-1949724575-2387902436-65106593-1201171665-3967308604)
S:(AU;FA;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;WD)

Decoded:

• Authenticated Users (AU) → Start/Stop/QueryStatus/QueryConfig/Interrogate/UserDefinedControl/ReadPermissions only. No DELETE, no WriteDAC, no WriteOwner, no ChangeConfig.
• One specific service SID S-1-5-80-... (a sibling Anthropic-owned packaged service) → full control including DELETE / WriteDAC / WriteOwner.
• SACL audits any Full Access attempts by Everyone.

Result: sc.exe delete CoworkVMService from an elevated admin shell returns OpenService FAILED 5: Access is denied. So does Set-Service -StartupType Manual. The service cannot be removed, reconfigured, or even permanently disabled from any normal admin path.

Service is WIN32_PACKAGED_PROCESS — bound to the AppX package lifecycle

sc.exe qc CoworkVMService
SERVICE_NAME: CoworkVMService
        TYPE               : 210  WIN32_PACKAGED_PROCESS
        START_TYPE         : 2   AUTO_START
        BINARY_PATH_NAME   : "C:\Program Files\WindowsApps\Claude_1.8555.2.0_arm64__pzs8sxrjxfjjc\app\resources\cowork-svc.exe"
        DEPENDENCIES       : staterepository
        SERVICE_START_NAME : LocalSystem

Because it is a packaged-process service, its only legitimate removal path is uninstalling the AppX package. But:

Remove-AppxPackage fails with 0x80073CFA while the service is alive

When the service is running (which it nearly always is — see auto-restart loop below) the package removal fails with HRESULT 0x80073CFA ("Windows cannot remove ... because the PreserveApplicationData flag can only be used on a package that ..."). This is reproducible from both Remove-AppxPackage and Anthropic's own setup binary.

Anthropic's signed Claude Setup.exe hits the same lockout

I downloaded the latest official installer from https://claude.ai/api/desktop/win32/arm64/setup/latest/redirect (signature: Anthropic, PBC via DigiCert, Valid) and ran it elevated. Its log file C:\Users\…\AppData\Local\Temp\ClaudeSetup.log shows the installer's own pre-flight reaching the same dead end:

2026/05/23 09:24:43  WARNING: CoworkVMService already exists (potential conflict)
2026/05/23 09:24:43  Conflicting service: true
2026/05/23 09:26:44  Removing conflicting CoworkVMService...
2026/05/23 09:26:44  WARNING: failed to remove conflicting service:
                     could not open CoworkVMService: Access is denied.
2026/05/23 09:26:44  Removing: Claude_1.8555.2.0_arm64__pzs8sxrjxfjjc
2026/05/23 09:26:44  WARNING: Remove failed for Claude_1.8555.2.0_arm64__pzs8sxrjxfjjc:
                     RemovePackage failed with HRESULT 0x80073CFA
2026/05/23 09:26:44  Removing (user): Claude_1.8555.2.0_arm64__pzs8sxrjxfjjc
2026/05/23 09:26:44  WARNING: Remove failed for Claude_1.8555.2.0_arm64__pzs8sxrjxfjjc:
                     RemovePackage failed with HRESULT 0x80073CFA
2026/05/23 09:26:44  Installing MSIX: ...\Claude-3027507626.msix
2026/05/23 09:26:44  Standard install (not split-account), using AddPackage
2026/05/23 09:26:47  MSIX package installed successfully
2026/05/23 09:26:47  Launching Claude via explorer.exe shell:AppsFolder\Claude_pzs8sxrjxfjjc!Claude

So the installer pivots to a plain AddPackage when it can't do the Remove-then-Add upgrade path — but every subsequent launch attempt still fails with the "Another program is currently using this file" dialog, because the running CoworkVMService keeps a lock on the install folder that Windows trips over during AppX activation.

The chicken-and-egg

1. CoworkVMService can only be removed by uninstalling the AppX package.
2. AppX package can only be removed when CoworkVMService is not running.
3. CoworkVMService is START_TYPE: AUTO_START and auto-restarts within ~30 s of any Stop-Service.
4. The service's DACL blocks Set-Service -StartupType Manual even when elevated, so we can't even disable the auto-restart.

Only an offline path (e.g., reboot before services start, or running from TrustedInstaller / safe mode) can break the loop. From a running user session there is no clean escape.

Userland mitigations that did NOT help

| Attempt | Result |
|---|---|
| Closed leaked AppContainer Job handle (handle64a.exe -c 6EC -p <appinfo pid>) | Job cleared; launch still fails |
| Stop-Service CoworkVMService | Stops, auto-restarts within 30 s |
| Set-Service CoworkVMService -StartupType Manual (elevated) | Access is denied (DACL) |
| sc.exe delete CoworkVMService (elevated) | OpenService FAILED 5: Access is denied |
| Add-AppxPackage -Register <manifest> -ForceApplicationShutdown (elevated) | Returns success; launch still fails |
| Remove-AppxPackage Claude_1.8555.2.0_arm64__pzs8sxrjxfjjc (elevated) | 0x80073CFA |
| Re-install via Anthropic's own signed setup (elevated) | Setup completes with exit 0, but Remove step fails with 0x80073CFA; install pivots to AddPackage; launch still fails with the same dialog immediately on click |

Suggested fixes (revised)

1. DACL on CoworkVMService is too restrictive. It should at minimum grant DELETE | WRITE_DAC | WRITE_OWNER | SERVICE_CHANGE_CONFIG to BUILTIN\Administrators and NT AUTHORITY\SYSTEM, otherwise the installer's own remove-then-add path is unusable, and the user has no recovery path from a corrupted intermediate update state.
2. Setup should hard-fail (not just warn) when it can't remove CoworkVMService, since pivoting to plain AddPackage produces a half-upgraded state where the new AppX is registered but the old service install state is preserved — which is exactly what triggers the recurring "Another program is currently using this file" dialog on launch.
3. Provide an out-of-band recovery tool / Claude-Repair.exe that runs from a TrustedInstaller context (e.g., the way Windows servicing tools do) so users can recover without resorting to safe-mode reboot.
4. The current "Another program is currently using this file" dialog is generic and gives the end user no actionable info. At minimum surface the HRESULT and the package-family-name involved, and ideally detect the CoworkVMService DACL deadlock specifically and produce a targeted error.

Environment (same as opening report)

Surface Pro 11 (Snapdragon, ARM64), Windows 11 Pro 10.0.26200, Claude 1.8555.2.0_arm64__pzs8sxrjxfjjc. The previous-version Job leak (Container_Claude_1.8555.1.0_… held by Appinfo PID 12684) described in the opening report has now been cleared via handle.exe -c, and the launch still fails — confirming it was not the root cause.

I hit what appears to be the same failure mode on Windows x64, not ARM64.

Environment:

• Windows 11, x64
• Claude Desktop package: Claude_1.11187.4.0_x64__pzs8sxrjxfjjc
• Install location: C:\Program Files\WindowsApps\Claude_1.11187.4.0_x64__pzs8sxrjxfjjc
• Previous package observed in AppX deployment logs: Claude_1.11187.2.0_x64__pzs8sxrjxfjjc

User-visible symptom:

• Launching Claude showed the Windows dialog:

Another program is currently using this file.

• The dialog pointed at the C:\Program Files\WindowsApps\Claude_1.11187.4.0... package path.
• Signing out and signing back in fixed it. Reboot was not required, but a new Windows logon session was.

Relevant event log findings:

From Microsoft-Windows-AppModel-Runtime/Admin:

0x80070020: Cannot create the process for package Claude_1.11187.4.0_x64__pzs8sxrjxfjjc because an error was encountered while configuring runtime. [LaunchProcess]

0x80070020: Cannot create the Desktop AppX container for package Claude_1.11187.4.0_x64__pzs8sxrjxfjjc because an error was encountered converting the job.
From Microsoft-Windows-AppXDeploymentServer/Operational:

Deployment Register operation with target volume C: on Package Claude_1.11187.4.0_x64__pzs8sxrjxfjjc ... finished successfully.

Moving package folder ... Claude_1.11187.2.0_x64__pzs8sxrjxfjjc to ... WindowsApps\Deleted\Claude_1.11187.2.0...
So the package registration appeared successful, but subsequent launch failed while creating/converting the Desktop AppX container/job.

Cowork findings:

CoworkVMService was registered as:

SERVICE_NAME: CoworkVMService
TYPE: 210 WIN32_PACKAGED_PROCESS
START_TYPE: AUTO_START
BINARY_PATH_NAME: "C:\Program Files\WindowsApps\Claude_1.11187.4.0_x64__pzs8sxrjxfjjc\app\resources\cowork-svc.exe"
SERVICE_START_NAME: LocalSystem
Restart Manager initially reported CoworkVMService / cowork-svc.exe holding:

C:\Program Files\WindowsApps\Claude_1.11187.4.0_x64__pzs8sxrjxfjjc\app\resources\cowork-svc.exe
Stopping the service did not resolve the issue:

Stop-Service CoworkVMService -Force
Get-Service CoworkVMService
# Status: Stopped
Claude still failed to launch with the same 0x80070020 / Desktop AppX container error.

Attempts that did not fix it:

# Stop common shell/AppX host processes
Get-Process RuntimeBroker,ApplicationFrameHost,SearchHost,StartMenuExperienceHost,ShellExperienceHost -ErrorAction SilentlyContinue | Stop-Process -Force

# Stop Claude service/helper
Stop-Service CoworkVMService -Force

# Re-register package
$pkg = Get-AppxPackage Claude
Add-AppxPackage -DisableDevelopmentMode -Register (Join-Path $pkg.InstallLocation 'AppxManifest.xml')

# Launch registered app
Start-Process 'shell:AppsFolder\Claude_pzs8sxrjxfjjc!Claude'
Direct launch also failed:

$pkg = (Get-AppxPackage Claude).InstallLocation
Start-Process -FilePath (Join-Path $pkg 'app\Claude.exe')
Result:

The process cannot access the file because it is being used by another process.
Additional note: even from an elevated Administrator PowerShell, changing the startup type of CoworkVMService was denied:

Set-Service CoworkVMService -StartupType Disabled
# Access is denied

sc.exe config CoworkVMService start= disabled
# [SC] OpenService FAILED 5: Access is denied.
The service security descriptor did not appear to grant normal Administrators service config rights.

Conclusion:

This strongly matches the stale AppContainer/Desktop AppX job theory. In this x64 case, no normal process cleanup or package re-registration fixed launch. CoworkVMService was involved and did hold the packaged service executable at one point, but after it was stopped the failure persisted, suggesting the remaining blocker was stale Windows AppX/container/job state in the current logon session.

Confirmed workaround:

Sign out of Windows and sign back in.
Claude launched successfully afterward.
This supports the idea that the reliable fix is clearing the Windows user logon session / AppX container state, not merely killing cowork-svc.exe.

Same issue.

Closing for now — inactive for too long. Please open a new issue if this is still relevant.

Root cause found via first-party logs: silent "stealth update" self-triggers, then fails to relaunch — no user action involved at all

Windows 11 x64, Claude Desktop 1.44121.4.0 (MSIX, Claude_pzs8sxrjxfjjc). This is a distinct trigger from what's described elsewhere in this thread — not a click on "Restart to update" or an in-app prompt. The app was sitting idle (I was away from the keyboard) and updated/quit itself entirely on its own, then never came back.

Sequence, reconstructed from main.log (%LOCALAPPDATA%\Claude\logs\main.log) and cowork-service.log (C:\ProgramData\Claude\Logs\), same machine, correlated timestamps:

main.log:
05:17:29  [updater] Checking for updates
05:17:30  [updater] Found an update, downloading
05:17:48  [updater] Update downloaded and ready to install { releaseName: 'Claude 1.44121.4' }
05:18:03–05:18:47  (normal Code session runs, completes successfully)
05:27:49  [updater] Staged version 1.44121.4 is still current (latest: 1.44121.4, lastTarget: null)
05:28:47  [stealth-update] Triggering stealth update after idle timeout
05:28:47  [popout-restore] Saving 0 session popout(s) for next launch
05:28:47  [stealth-relaunch] Saved z-order anchor / navigation history
05:28:47  beforeQuitForUpdate handler fired, going down for update
05:28:47  Windows session ending (close-app) - quitting the app
          <log ends here — no further entries, ever>

cowork-service.log, same instant:
05:28:47.524  [Server] Persistent RPC: connection ended: failed to read length: EOF
05:28:47.524  [Server] Session Mike:...LocalCache\Roaming\Claude has no active connections, idle timeout starts
05:28:47.635  Service stop requested
05:28:47.643  Warning: failed to disarm recovery actions for this stop: open service: Access is denied.
05:28:47.644  Shutdown signal received... Server stopped. Service stopped.
05:28:48.739  Starting CoworkVMService as Windows service
05:28:48.830  Warning: failed to configure recovery actions (a crashed service will stay down until reboot): open service: Access is denied.

CoworkVMService then cycles stop→restart 5 times over the next 10 minutes (05:28:47, 05:33:06, 05:33:26, 05:35:11, 05:38:33), each restart logging the same "Access is denied" recovery-config warning (this specific warning is chronic and present on literally every service start going back to when this log began — unrelated to this incident, but worth noting as a standing bug of its own: the packaged service's DACL doesn't grant itself permission to configure its own SCM failure-recovery policy).

The critical failure: main.log has zero entries after 05:28:47. The app's own self-relaunch-after-update path (stealth-relaunch) never completed. I did not touch the keyboard between the quit and discovering the problem — the "Another program is currently using this file" dialog pointing at Claude_1.44121.4.0_... was already on screen, unprompted, when I next looked at the machine. This was Desktop's own automatic post-update relaunch failing silently in the background, not a manual launch attempt colliding with anything.

Confirmed non-destructive recovery: sign-out/sign-in (not a full reboot) reliably clears it. Full details of the diagnostic process (Procmon captures, Reliability Monitor, Appinfo service isolation via System Informer) available if useful — kept this comment to the log evidence to stay actionable.

Suggested fix direction: the stealth-update path should verify the app actually came back up after beforeQuitForUpdate, and retry or at least surface a notification if the relaunch didn't happen — right now a failed silent update just leaves the app dead with no visible symptom until the user manually tries to open it and hits a confusing generic Windows file-lock dialog.

Same issue on x64, Intune-managed corporate laptop — occurring almost daily

Adding an x64 data point to the ARM64 reports above, with matching event log evidence.

Environment

• Claude Desktop (MSIX) on Windows 11, x64, corporate Intune-managed laptop
• Standard (non-admin) user for daily work
• Frequency: almost every day — appears to trigger on each in-app update while the app/service is running

Symptoms

• On update, dialog: C:\Program Files\WindowsApps\Claude_<version>... — "Another program is currently using this file."
• App is then unlaunchable until the session is recycled. Seen across multiple update hops

(1.49585.0.0 → 1.52386.0.0 → 2.110.1.0 and others).

What does NOT help (tried repeatedly)

• Ending cowork-svc.exe and all Claude.exe processes in Task Manager
• Stop-Service CoworkVMService -Force (service shows Stopped; relaunching Claude restarts it and the same dialog reappears)
• Killing processes before relaunch in any order

What DOES help

• Full Windows restart (my daily workaround so far)

Event log — matches the stale AppContainer Job diagnosis
Microsoft-Windows-AppModel-Runtime/Admin, both logged at the moment of a failed launch (2026-09-17 11:18:36):

• Event 215 (Keywords: DesktopAppXContainer):

0x80070020: Cannot create the Desktop AppX container for package Claude_2.110.1.0_x64__pzs8sxrjxfjjc because an error was encountered converting the job.

• Event 208 (Keywords: DesktopAppXProcess, one second later):

0x80070020: Cannot create the process for package Claude_2.110.1.0_x64__pzs8sxrjxfjjc because an error was encountered while configuring runtime. [LaunchProcess]

This reproduces the kernel Job-object failure described in the OP on x64, not just ARM64. On a fleet of managed corporate machines a daily reboot-to-update is a real productivity cost, so a fix in the updater (stop CoworkVMService and helper processes, verify the old container Job is gone before applying the MSIX) would be much appreciated.