MSIX repair loop left the app unopenable; surfaced two standing defects — CoworkVMService cannot arm SCM recovery (31/60 days), and app logging silently died 4 days ago

## Summary

A Windows package-repair sequence tore the running Claude Desktop app down and left the MSIX package unopenable ("Claude can't be opened — try Advanced options → Repair"). I recovered by re-downloading the installer from anthropic.com.

Investigating it surfaced **two persistent defects that are independent of the incident** and are worth fixing on their own:

1. **`CoworkVMService` cannot configure its own SCM recovery actions** — by its own log message, *"if the service crashes it will not restart until the machine reboots."* This has fired on **31 separate days in the last 60**.
2. **The app's own logging silently stopped on 2026-08-20** and has produced nothing since, through four days of heavy daily use. There is no diagnostic trail for this incident, or for anything else since that date.

## The incident, reconstructed from Windows event logs

All times local (America/New_York), 2026-08-24. Package version **unchanged throughout**: `1.34493.1.0` → `1.34493.1.0`. This was a **repair loop, not an update**.

| Time | Event |
|---|---|
| 12:01:32 | `AppXDeploymentServer` begins `RegisterByPackageFullName` on `Claude_1.34493.1.0_x64__pzs8sxrjxfjjc`; repairs ACLs |
| 12:01:33 | `CoworkVMService` terminated for servicing. Warns: *"failed to disarm SCM recovery actions for this stop; if the stop overruns, the service may be auto-restarted during package servicing"* |
| 12:01:42 | **Second** `RegisterByPackageFullName` on the same version |
| 12:03:28 | **Third** `RegisterByPackageFullName` on the same version |
| 12:03:31 | ❌ `error 0x80070015: Unable to notify pre-launch service for app Claude_pzs8sxrjxfjjc!Claude install/uninstall` |
| 12:04:16 | Windows attempts `Remove` with `PreserveApplicationData` — ❌ **fails twice**, `0x80073CFA` |
| 12:04:16 | `Add` operation from `C:\Users\obrie\AppData\Local\Temp\Claude-2058643347.msix` with `ForceApplicationShutdownOption, ForceUpdate` — **this is my manual re-download from anthropic.com** |
| 12:04:17 | Signature validated, publisher `CN="Anthropic, PBC"` |
| 12:04:27 | `Add` completes successfully |
| 12:04:28 | `CoworkVMService` warns: *"failed to configure SCM recovery actions; if the service crashes it will not restart until the machine reboots: open service: Access denied"* |
| 12:04:29–12:05:39 | All 16 `claude` processes start |

**What I saw on screen**, which matches the ACL-repair and signature-validation steps above: a message about security verification, then the app disappeared. Reopening it produced the "can't be opened, try Advanced options and repair" dialog. I did not use Repair — I reinstalled from the website, which is the 12:04:16 `Add` operation.

**There was no application crash.** No Crashpad dump (`Crashpad\reports\` is empty), no `Application Error` event, no faulting module. The app was terminated by package servicing while running.

## Defect 1 — the service cannot arm its own recovery

`CoworkVMService` logs, verbatim:

> *"Claude VM Service: failed to configure SCM recovery actions; if the service crashes it will not restart until the machine reboots: open service: Access denied"*

and

> *"Claude VM Service: failed to disarm SCM recovery actions for this stop; if the stop overruns, the service may be auto-restarted during package servicing"*

**Frequency: 31 distinct days in the last 60**, first seen 2026-06-26, most recently today. This is chronic, not a side effect of this incident.

The consequence is stated in the message itself: the service's crash-recovery is not configured, so a crash requires a **machine reboot** to recover. The second message additionally implies servicing and the service's own stop can race.

## Defect 2 — logging died silently and nobody would know

The newest file in `%APPDATA%\Claude\logs\` is dated **2026-08-20 19:44**.

The app has been in heavy use every day since — measured by session transcripts written under `~\.claude\projects\`:

```
2026-08-20 : 20 transcript files
2026-08-21 : 68
2026-08-22 : 26
2026-08-23 : 3
2026-08-24 : 3
```

So the app ran constantly for four days and wrote **zero** log output. There is no error, no warning, and no indication in the UI that logging has stopped.

This is what made the present incident un-diagnosable from Anthropic's own artifacts — everything above had to be reconstructed from Windows event logs instead. Any user hitting this has nothing to attach to a bug report.

## Expected behaviour

1. `CoworkVMService` should either successfully configure its SCM recovery actions, or fail loudly at install time rather than warning into a log nobody reads. As shipped, its own log says a crash strands it until reboot.
2. The pre-launch-notify path (`0x80070015`) should not leave the package in an unopenable state. If servicing cannot notify the app, that should be recoverable without a manual reinstall.
3. Application logging should not stop silently. If the log writer dies, that should surface — and it should certainly not stay dead across four days and dozens of sessions.

## What I could not determine

**Why Windows initiated the re-registration at 12:01:32.** There is no preceding Windows Update event, no corruption error, and nothing else in the System or AppXDeployment logs that explains the trigger. I am not going to speculate.

Also worth stating: the `0x80073CFA` removal failure appears **only on this date** in the last 30 days, so the incident itself is a one-off. Defects 1 and 2 are not.

## Environment

- Claude Desktop, MSIX package `Claude_1.34493.1.0_x64__pzs8sxrjxfjjc`, installed 2026-08-21
- Windows 11 Pro 10.0.26200
- Claude Code in the Desktop app; multiple MCP servers; long multi-hour sessions

## Related

Immediately after the app relaunched at 12:04:29, the session auto-resume fired at 12:05:44 and silently no-opped — filed separately as #89265. In practice the two compound: the app is torn down, and the mechanism that should have resumed the interrupted work does nothing.

Start with the CoworkVMService SCM recovery setup and the pre-launch-notify path described in the issue, then inspect the logging behavior associated with %APPDATA%\Claude\logs\. Done means recovery actions are reliably configured, servicing failures do not leave the package unopenable, and logging failure is surfaced instead of remaining silent.

Scritto dal modello di indicizzazione a partire dal testo della issue.