[BUG] CoworkVMService (cowork-svc.exe) blocks Windows desktop app self-update, requiring full PC reboot

### 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?

## What happened
Every time the Windows desktop app auto-updates, the update either fails outright
or leaves the app unable to relaunch with "이 파일을 다른 응용 프로그램에서
사용 중입니다" (this file is being used by another program). Only a full PC
reboot lets the app open again.

### What Should Happen?

## Root cause (found via Windows Event Log + service inspection)
The desktop app registers a packaged Win32 service, `CoworkVMService`, running
`cowork-svc.exe` as LocalSystem, pointed at the versioned install path:

\```
C:\Program Files\WindowsApps\Claude_[version]_x64__pzs8sxrjxfjjc\app\resources\cowork-svc.exe
\```

Because this is a genuine Windows Service (not a child process of the app),
closing the app window does NOT stop it. When the MSIX auto-updater tries to
replace the package's files, it can't — the old version's cowork-svc.exe is
still running and has its own binary locked.

Microsoft-Windows-AppXDeploymentServer/Operational log shows this recurring
across multiple separate update attempts (Sept 9, 11, 12, 14):
- Warning (Id 658), repeated: "Marking package {new version} for deferred
registration because {Claude_1.49585.0.0_x64__pzs8sxrjxfjjc} is still running."
- Hard failure on 2026-09-12 (Id 404/401/419):
"AppX Deployment operation failed ... error 0x80073D02: 다음 앱을 닫아야
하므로 설치할 수 없습니다. 앱: Claude_1.49585.0.0_x64__pzs8sxrjxfjjc."

Note the SAME old version (1.49585.0.0) is flagged as "still running" across
all four attempts spanning 5 days, even though the actual installed/running
version had already moved past it by then — this is not a one-off regression,
it reproduced across every single update in that window regardless of which
version was shipping. That suggests the deployment mechanism doesn't
distinguish stale state from actually-active processes, or the packaged
service was never being stopped cleanly at that version's own update,
leaving a persistent block that then affects every subsequent update.

## Expected behavior
The installer/updater should stop `CoworkVMService` before attempting to
replace the package's files (and restart it against the new version's path
afterward), so updates complete without requiring a manual service stop or
a full system reboot.

## Environment
- Windows desktop app (MSIX/AppX package), current version at time of report: 1.52386.6.0
- Service: CoworkVMService, TYPE=WIN32_PACKAGED_PROCESS, START_TYPE=AUTO_START,
SERVICE_START_NAME=LocalSystem, DEPENDENCIES=staterepository

### Error Messages/Logs

\```shell
# Microsoft-Windows-AppXDeploymentServer/Operational

2026-09-12 12:16:23 PM Error Id 404
AppX Deployment operation failed for package Claude_1.52386.3.0_x64__pzs8sxrjxfjjc with error 0x80073D02.
The specific error text for this failure is: 오류 0x80073D02: 다음 앱을 닫아야 하므로 설치할 수 없습니다.
앱: Claude_1.49585.0.0_x64__pzs8sxrjxfjjc.

2026-09-12 12:16:23 PM Error Id 401
Deployment Register operation with target volume C: on Package Claude_1.52386.3.0_x64__pzs8sxrjxfjjc
from: (AppxManifest.xml) failed with error 0x80073D02.

2026-09-12 12:16:23 PM Error Id 419
error 0x80073D02: Unable to install because the following apps need to be closed
Claude_1.49585.0.0_x64__pzs8sxrjxfjjc.

2026-09-14 05:07:04 AM Warning Id 658
Marking package {Claude_1.52386.6.0_x64__pzs8sxrjxfjjc} for deferred registration
because {Claude_1.49585.0.0_x64__pzs8sxrjxfjjc} is still running.

# Same Warning 658 (same stale version 1.49585.0.0) also seen on:
# 2026-09-09, 2026-09-11, 2026-09-12 — one occurrence per update attempt.

# Service registration confirming the blocker, captured after the app became
# unusable post-update:
PS> Get-CimInstance Win32_Service -Filter "Name='CoworkVMService'" | Format-List
Name : CoworkVMService
DisplayName : Claude
PathName : "C:\Program Files\WindowsApps\Claude_1.52386.6.0_x64__pzs8sxrjxfjjc\app\resources\cowork-svc.exe"
StartMode : Auto
State : Running
StartName : LocalSystem
\```

### Steps to Reproduce

1. Install/run the Windows desktop app (MSIX-packaged build) and leave it
running normally — do not reboot the PC for several days. This lets the
background `CoworkVMService` (cowork-svc.exe) stay alive under its
currently-installed version's path the whole time.
2. Let the app auto-update (or trigger a manual update check) while the PC
is still in that un-rebooted state, so the OLD version's CoworkVMService
process is still running at the moment Windows tries to deploy the new
package.
3. Observe one of two outcomes in
Event Viewer > Applications and Services Logs >
Microsoft-Windows-AppXDeploymentServer > Operational:
a. Warning (Event ID 658): "Marking package {new version} for deferred
registration because {old version} is still running."
b. Hard failure (Event ID 404/401/419), error 0x80073D02:
"Unable to install because the following apps need to be closed:
{old version}."
4. After the update attempt finishes (or appears to), try to relaunch the
Claude app from the Start Menu / taskbar / desktop shortcut.
5. Observe the app fails to open and shows: "이 파일을 다른 응용
프로그램에서 사용 중입니다" (this file is being used by another
program), or the app simply does not launch at all.
6. Confirm CoworkVMService is still running the OLD version's binary at
this point:

\```
Get-CimInstance Win32_Service -Filter "Name='CoworkVMService'" |
Select-Object PathName, State
\```

PathName still points at the pre-update versioned folder
(`Claude_[old version]_x64__pzs8sxrjxfjjc\app\resources\cowork-svc.exe`),
State = Running.
7. Confirm the app remains unusable until a full PC reboot — no combination
of quitting the app, killing its GUI process, or re-launching it clears
the lock, because CoworkVMService is an independent LocalSystem service,
not a child process of the app's main window.
8. Reboot the PC. On next boot, the app launches normally and
CoworkVMService now points at the new version's path — confirming the
stuck old-version service was the blocker.

Note: this is timing-dependent on how long the PC has been running since
its last reboot relative to when an update is pushed — it reproduced for us
across 4 separate auto-update attempts over 5 days (Sept 9, 11, 12, 14) with
the same stale version (1.49585.0.0) flagged as "still running" each time,
suggesting it is not a rare race but the normal outcome whenever an update
lands on an un-rebooted machine.

### Claude Model

Sonnet (default)

### Is this a regression?

No

### Last Working Version

N/A — not a version-specific regression. Reproduced identically across every
update attempt we observed (1.49585.0.0 → 1.52386.0.0 → 1.52386.3.0 →
1.52386.6.0), so there isn't a "last working version" to point to — this
looks like a longstanding gap in how the packaged CoworkVMService is
stopped/restarted during self-update, not something that broke recently.

### Claude Code Version

2.1.220

### Platform

Anthropic API

### Operating System

Windows

### Terminal/Shell

Windows Terminal

### Additional Information

_No response_