[BUG] Windows: app won't launch — "Another program is currently using this file" — cowork-svc.exe holds its own image inside the MSIX package

### Preflight Checklist

- [x] I have searched [existing issues](https://github.com/anthropics/claude-code/issues?q=is%3Aissue%20state%3Aopen%20label%3Abug) 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?

After Claude Desktop terminated unexpectedly, it will no longer start. Launching produces a modal error titled with the package path and the message "Another program is currently using this file."

The lock is held by cowork-svc.exe, which runs from INSIDE the MSIX package directory (…\Claude_1.49585.0.0_x64__pzs8sxrjxfjjc\app\resources\cowork-svc.exe) and is registered as an auto-restarting Windows service (CoworkVMService). A running process holds its own image file open, which is exactly what the error reports.

Because the service lives outside the package's app container, Settings → Apps → Claude → Advanced options → Terminate does not release it — Terminate only tears down the package container, not the app's separately-registered service.

Confirmed via Resource Monitor → CPU → Associated Handles, filtered on "claude":

| Image | Type | Handle |
|----------------------------|------|-----------------------------------------------------------|
| cowork-svc.exe | File | C:\ProgramData\Claude\Logs\cowork-service.log |
| svchost.exe (netsvcs -p) | Job | \Container_Claude_1.46388.4.0_x64__pzs8sxrjxfjjc- |

Two distinct problems:

1. Killing cowork-svc.exe by PID is useless — CoworkVMService restarts it immediately under a new PID. Stopping it needs Stop-Service, and Set-Service is refused even from an elevated prompt ("Access is denied"), so the service cannot be disabled by the machine's administrator.
2. An app-container Job object for the PREVIOUS version (1.46388.4.0) is still pinned by svchost long after the update to 1.49585.0.0. The stale container registration appears to survive the upgrade.

What doesn't work:
- Settings → Advanced options → Terminate (doesn't reach the service)
- Settings → Repair (same file-in-use error)
- Killing cowork-svc.exe by PID (service respawns it)
- Remove-AppxPackage -PreserveApplicationData on the stale version — fails 0x80073CFA; that flag is dev-mode only, so there's no documented way to drop a stale version while keeping app data

### What Should Happen?

CoworkVMService / cowork-svc.exe should be stopped as part of app shutdown and package servicing, and stale app-container jobs from a superseded version should be released on upgrade.

At minimum, Terminate should also stop the app's own registered service — as it stands, the one button Windows offers for exactly this situation structurally cannot fix it.

### Error Messages/Logs

```shell
Dialog title: C:\Program Files\WindowsApps\Claude_1.49585.0.0_...
Dialog body: Another program is currently using this file.

Remove-AppxPackage : Deployment failed with HRESULT: 0x80073CFA, Removal failed.
Windows cannot remove Claude_1.46388.4.0_x64__pzs8sxrjxfjjc because the
PreserveApplicationData flag can only be used on a package that was deployed
in development mode.

Set-Service : Service 'Claude (CoworkVMService)' cannot be configured due to
the following error: Access is denied
(from an elevated PowerShell session)
```

### Steps to Reproduce

1. Have Claude Desktop 1.46388.4.0 installed and running on Windows 11.
2. Let it update to 1.49585.0.0 while running.
3. Have the app terminate abnormally.
4. Attempt to relaunch — the error dialog appears instead of the app.
5. Settings → Apps → Claude → Advanced options → Terminate, then relaunch: same error.

Not reliably deterministic, but that's the shape. The persistent state is
visible without reproducing: Resource Monitor → CPU → Associated Handles,
search "claude".

### Claude Model

Opus

### Is this a regression?

Yes, this worked in a previous version

### Last Working Version

1.46388.4.0

### Claude Code Version

1.49585.0.0 (Claude Desktop — not the Claude Code CLI)

### Platform

Anthropic API

### Operating System

Windows

### Terminal/Shell

PowerShell

### Additional Information

Filed here because there is no public Claude Desktop issue tracker in the
anthropics org — please redirect if there's a better home.

Separately: paths under
%LOCALAPPDATA%\Packages\Claude_pzs8sxrjxfjjc\LocalCache\Roaming\Claude\local-agent-mode-sessions\\\skills\…
nest deeply enough to exceed the Windows MAX_PATH limit (260 chars). This
breaks ordinary file tooling against the data directory — Copy-Item and
anything else that isn't long-path aware fails with DirectoryNotFoundException
on the deeper schema files. Worth shortening.

The report names no Claude Code files, tests, or entry points and identifies the failure as Claude Desktop's Windows MSIX package and CoworkVMService. First verify whether this belongs in this repository, then reproduce on Windows 11 using the stated versions and Resource Monitor; done would mean confirming ownership and defining how service shutdown and stale package jobs should be handled during upgrade.

Escrito por el modelo de indexación a partir del texto del issue.