Windows: desktop app force-terminates active sessions — launcher passes ForceTargetApplicationShutdownOption in a repeating repair-register loop

### What's Wrong?

On Windows, the Claude desktop app terminates itself without warning, repeatedly, during an active session. Work in progress is lost.

The cause is not a crash. The app's own launcher — running in the **user's** context, not SYSTEM — calls the AppX deployment API `RegisterByPackageFullName` with:

```
Options: ForceTargetApplicationShutdownOption, RepairAppRegistrationOption
```

`ForceTargetApplicationShutdownOption` is caller-supplied and instructs Windows to terminate the running app to complete the operation. Windows obeys. The app is not dying — it is requesting its own death while the user is mid-session.

This forms a self-sustaining loop: launch → launcher judges the package registration unhealthy → repair with force-kill → app dies → user relaunches → repeat.

Observed **8 times in ~2 hours** on 2026-09-16, every one returning success (`Deployment Register operation ... finished successfully`):

```
11:42:49 · 11:47:43 · 11:57:22 · 12:02:41 · 12:08:07 · 12:10:03 · 12:13:33 · 13:43:21
```

Each cycle logs `Trying to repair ACLs for \\?\C:\Program Files\WindowsApps\Claude_2.110.0.0_x64__pzs8sxrjxfjjc` → `ACLs repaired successfully. Register next time should succeed.` — yet minutes later it needs repairing again.

**This is specific to Claude.** Grouping every repair-register operation on the machine over 7 days by package:

| Count | Package |
|---|---|
| 8 | `Claude_2.110.0.0` |
| 6 | `Claude_1.52386.0.0` |
| 5 | `Claude_1.49585.0.0` |

Zero for every other installed package. It follows Claude across three consecutive versions, so it is neither a corrupted build nor environmental.

Ruled out during diagnosis:
- **A corporate EDR agent (CrowdStrike Falcon)** is present. If it were rewriting `WindowsApps` permissions, other packages would repair too. None ever do.
- **A missing `ALL APPLICATION PACKAGES` ACE** on Claude's package folder — tested and refuted: 7 other packages also lack it and never repair.
- **StateRepository `Error 0x15: misuse` (SQLITE_MISUSE, Event ID 100)** — fires on a ~30-min cadence independent of Claude.

Separately, `C:\ProgramData\Claude\Logs\cowork-service.log` logs on every start and stop:

```
Warning: failed to configure recovery actions (a crashed service will stay down until reboot): open service: Access is denied.
Warning: failed to disarm recovery actions for this stop: open service: Access is denied.
```

`CoworkVMService` is a packaged service (`TYPE : 210 WIN32_PACKAGED_PROCESS`) running as LocalSystem, whose binary lives inside the versioned package folder. A packaged service cannot obtain `SERVICE_CHANGE_CONFIG` on its own SCM entry even as LocalSystem — the DACL is authored by the deployment engine — so these calls can never succeed. Currently harmless (`sc qfailure CoworkVMService` shows `RESET_PERIOD : 0` with no actions configured, so there is nothing to disarm), but it is unconditional log noise on every service transition.

### What Should Happen?

A package-registration repair should never terminate a running session that has active user work. If the launcher determines a repair is needed, it should either defer it to the next cold start, or prompt the user before killing the app — not pass `ForceTargetApplicationShutdownOption` silently.

Secondarily, if the repair genuinely succeeded, it should not be needed again minutes later. The repeat suggests the health check and the repair disagree about what "healthy" means.

### Error Messages/Logs

Dialog shown to the user:

```
C:\Program Files\WindowsApps\Claude_2.110.0.0_x6...
Another program is currently using this file.
```

From `Microsoft-Windows-AppXDeploymentServer/Operational`, Event ID 603:

```
Started deployment RegisterByPackageFullName operation on a package with main parameter
Claude_2.110.0.0_x64__pzs8sxrjxfjjc and Options
ForceTargetApplicationShutdownOption,RepairAppRegistrationOption and 0.
```

Event ID 649, same cycle:

```
Deployment Register operation on Package Claude_2.110.0.0_x64__pzs8sxrjxfjjc:
Trying to repair ACLs for \\?\C:\Program Files\WindowsApps\Claude_2.110.0.0_x64__pzs8sxrjxfjjc
...
ACLs repaired successfully. Register next time should succeed.
```

A related but distinct failure mode was seen on 2026-09-11 under v1.52386, where the same dialog appeared because the register **failed** instead:

```
Event 404: error 0x80073D02: Unable to install because the following apps need to be closed
Claude_1.52386.0.0_x64__pzs8sxrjxfjjc.

Event 638: Packages were not updated because affected apps are still running.
Running apps: {Claude_pzs8sxrjxfjjc!Claude}
```

### Steps to Reproduce

1. Install Claude desktop on Windows 11 (MSIX, package family `Claude_pzs8sxrjxfjjc`).
2. Launch the app and begin a session.
3. Observe the app terminate itself without warning, sometimes preceded by the dialog above.
4. Confirm the cause with PowerShell (no elevation required):

```powershell
Get-WinEvent -LogName "Microsoft-Windows-AppXDeploymentServer/Operational" -MaxEvents 4000 |
Where-Object { $_.Message -match 'Claude' -and $_.Id -in 603,400,404,649 } |
Sort-Object TimeCreated | Select-Object -Last 20 TimeCreated, Id, Message
```

5. Confirm it is Claude-specific rather than environmental:

```powershell
Get-WinEvent -LogName "Microsoft-Windows-AppXDeploymentServer/Operational" -MaxEvents 6000 |
Where-Object { $_.Id -eq 603 -and $_.Message -match 'RepairAppRegistrationOption' } |
ForEach-Object { if ($_.Message -match 'main parameter (\S+?) and Options') { $matches[1] } } |
Group-Object | Sort-Object Count -Descending | Format-Table Count, Name
```

I could not identify a deterministic trigger. The repairs appear to cluster near launch, but I lack launch timestamps for the earlier cycles to confirm that, so treat it as unverified.

### Additional Information

- Desktop app version: `2.110.0.0` (also reproduced on `1.52386.0.0` and `1.49585.0.0`)
- Package family: `Claude_pzs8sxrjxfjjc`
- Windows 11 Home, build 10.0.26200
- Package `Status` reports `Ok` throughout; nothing is left stuck or pending afterwards, and no `.rslc` resiliency files remain
- Impact is bounded to unsaved session state, since sessions are resumable — but the interruption is unpredictable and silent

Machine identifiers (hostname, username, SID) have been redacted.

Start by reproducing the issue with the supplied PowerShell queries and inspect the launcher entry point that calls RegisterByPackageFullName with ForceTargetApplicationShutdownOption and RepairAppRegistrationOption. Trace why the repair repeats after reporting success; done means active sessions are not silently terminated and the repair no longer recurs unnecessarily.

Written by the indexing model from the issue text.