[BUG] Windows x64: "Another program is currently using this file" after crash — no pending update, no usermode handle holder

Preflight Checklist

• [x] I have searched existing issues and this hasn't been reported yet
• [x] This is a single bug report (please file separate reports for different bugs)
• [x] I am using the latest version of Claude Code

What's Wrong?

Summary

On Windows 11 x64, Claude Desktop crashes during normal use and then refuses to
relaunch, showing the dialog "Another program is currently using this file"
pointing at C:\Program Files\WindowsApps\Claude_1.49585.0.0_.... Every
subsequent launch attempt reproduces the dialog.

This differs from the existing reports (#76357, #51847) in two ways:

1. No update is involved. The failure occurs after a crash during normal

use, not when clicking "Relaunch" to apply an update. Get-AppxPackage
reports the installed package as Ok with no pending registration.

1. No usermode process holds the lock. With CoworkVMService confirmed

stopped and zero Claude.exe processes running, the error still fires.

Environment

• OS: Windows 11 x64, build 25H2 (OS Build 26200.9168)
• Claude Desktop: 1.49585.0.0 (MSIX)
• PackageFullName: Claude_1.49585.0.0_x64__pzs8sxrjxfjjc
• Install source: Microsoft Store / MSIX

Steps to reproduce

1. Use Claude Desktop normally.
2. App crashes after a period of use (no update prompt shown, no user action

to update).

1. Attempt to relaunch from the Start menu or taskbar.

Expected

The app relaunches.

Actual

Modal dialog: "Another program is currently using this file", titled with the
WindowsApps package path. Dismissing and retrying reproduces it every time —
each attempt stacks another dialog.

Diagnostics

Immediately after the failure, in an elevated PowerShell session:

PS> Get-Service CoworkVMService | Select Status, StartType
Status  StartType
------  ---------
Running Automatic

PS> Get-Process Claude -ErrorAction SilentlyContinue | Select Id, Path
(no output)

PS> Get-AppxPackage *Claude* | Select Name, Version, PackageFullName, Status
Name   Version      PackageFullName                          Status
----   -------      ---------------                          ------
Claude 1.49585.0.0  Claude_1.49585.0.0_x64__pzs8sxrjxfjjc     Ok

So: the service is running, but no Claude processes exist and the package is
cleanly registered with no update pending.

After forcing the service to Manual and stopping it (see workaround below):

PS> Get-Service CoworkVMService | Select Status, StartType
Status  StartType
------  ---------
Stopped Manual

Launching Claude at this point still produces the same dialog. With the
service stopped and no Claude processes present, no usermode handle holder
remains — which matches the AppContainer job-object analysis in #61635, though
that issue was filed against ARM64.

Reboot allowed Claud to reboot, but after a short while, an hour or so it would crash again and repeat.

Secondary bug: documented workaround fails

The workaround given in #45400 and #76357 does not work as written.
Stop-Service succeeds, but Set-Service is refused even in an elevated
session:

PS> Stop-Service CoworkVMService -Force
PS> Set-Service CoworkVMService -StartupType Disabled
Set-Service : Service 'Claude (CoworkVMService)' cannot be configured due to
the following error: Access is denied
    + CategoryInfo          : PermissionDenied: (System.ServiceProcess.ServiceController:ServiceController) [Set-Service], ServiceCommandException
    + FullyQualifiedErrorId : CouldNotSetService,Microsoft.PowerShell.Commands.SetServiceCommand

The MSIX-installed service carries a security descriptor that doesn't grant
Administrators SERVICE_CHANGE_CONFIG, so SCM refuses the change regardless of
elevation. Because the service has StartupType Automatic with auto-recovery, it
restarts within seconds of Stop-Service, so stopping it alone is not stable.

Writing the startup type directly to the registry does work and bypasses the
SCM permission check:

Set-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Services\CoworkVMService" -Name Start -Value 3
Stop-Service CoworkVMService -Force

The workaround in the existing issues should be corrected to use this, or the
service ACL should grant Administrators config rights.

Suggested fixes

1. Surface the actual lock holder in the error, or at minimum the package full

name and HRESULT. "Another program is currently using this file" is not
actionable when no such program exists.

1. Ensure Claude.exe and CoworkVMService release all package handles on

crash, not only on clean shutdown.

1. Grant Administrators config rights on CoworkVMService, so the documented

recovery steps work without registry edits.

1. Investigate the AppContainer job reference retained by the AppInfo service

(per #61635) on the x64 path as well as ARM64.

Related

• #61635 — same "no usermode handle holder" signature, ARM64
• #76357 — update path, reboot required
• #45400 — update path, service holds locks
• #51847 — reports of the error on close, reboot the only fix

What Should Happen?

Claude code should not crash and be unable to be reboot without a PC restart.

Error Messages/Logs

Steps to Reproduce

1. Boot Claude desktop
2. Wait some time.
3. Crashes and throws the pop-up error.

Claude Model

Opus

Is this a regression?

I don't know

Last Working Version

_No response_

Claude Code Version

1.49585.0.0

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

Windows Terminal

Additional Information

_No response_