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.