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):

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

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

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.