Windows: stuck same-version repair-install loop kills Cowork VM sessions (background agents silently lost)

Summary

The Claude desktop app for Windows (MSIX build) appears stuck in a repeating "repair install" loop that reinstalls the same already-installed version over and over. Each attempt fails (expected, since the app is running) but still tears down and restarts the Cowork VM Service, silently killing any in-progress background agent/tool work.

Environment

• OS: Windows 11 Pro (build 10.0.26200)
• Claude desktop app: v1.24012.9.0 (MSIX, WindowsApps\Claude_1.24012.9.0_x64__...)
• Feature: Cowork VM sandbox (background agents / long tool executions run inside a VM managed by cowork-svc.exe / CoworkVMService)

Symptom

During an active session with long-running background agents (multi-minute web research tasks via the Agent tool), agents are silently killed with no user-facing error. The only signal is a generic "no completion record found ... previous Claude Code process exited" notification. This happened at least 4 times within about an hour of normal use.

Root cause (found in Windows Event Log + C:\ProgramData\Claude\Logs\cowork-service.log)

Microsoft-Windows-AppXDeploymentServer/Operational shows the app repeatedly triggering RepairPackageOperation → downloads the exact same version again from https://downloads.claude.ai/releases/win32/x64/1.24012.9/Claude-<hash>.msix → tries to Register it → fails with AppX error 0x80073D02:

"impossible d'installer, car les applications suivantes doivent être fermées Claude_1.24012.9.0_x64__..." (cannot install because the app must be closed first)

This happened at roughly 21:47, 22:04, 22:39, and 22:44 (4 attempts in ~1h), each time against the identical version number — so this isn't a real version upgrade in progress, it's a repair loop that can never succeed because the running app blocks its own repair.

Despite the failed install, cowork-service.log shows each cycle still disrupts the live session:

[Server] Persistent RPC: connection ended: failed to read length: EOF
[Server] Session ... has no active connections, idle timeout starts
Service stop requested
Shutdown signal received...
Service stopped.
... (about 1 min later)
Starting CoworkVMService as Windows service

A fresh VM session is created afterward, but anything that was running in the torn-down VM (in our case, several background Agent-tool tasks doing web research) is lost, with no clean error surfaced to the user — the parent process just reports the agent as "stopped" with no completion record.

Only one genuine claude.exe "Application Hang" (Event 1002) occurred in the whole session (unrelated, separate incident) — so the repeated disruptions are not the app actually crashing/freezing, they're this repair-loop side effect.

Suggested fix

• Don't retry the repair/repackage step on a short interval while blocked by "app must be closed" — back off much more aggressively, or skip the repair entirely when target version == installed version.
• If a repair/update really is pending, prefer deferring it until the Cowork VM session is idle rather than force-stopping an active VM session mid-task.
• Surface a clear, specific error to the user/CLI when an agent is killed because of this (rather than a generic "process exited"), so it's obvious this isn't a crash.

Happy to share the full cowork-service.log and event log export privately if useful.