Claude Desktop auto-update stops CoworkVMService and kills every long-running process started from a Claude Code session, with no warning, grace period or notification

Summary

On Windows, Claude Desktop's package auto-update stops CoworkVMService, and every long-running process launched from a Claude Code session dies with it — instantly, with no warning, no grace period, and no notification to the session when it resumes. There is no way to stop such work cleanly beforehand or to recover it cleanly afterwards.

This is a different symptom from the existing SCM recovery-action reports (#91195, #91213, #92092, #92379), though it happens on the same service stop path; #91195 notes that the service is restarted during package servicing.

Impact

I run a multi-stage media-processing pipeline driven from a Claude Code session: sixteen background worker loops (encoding, disc ripping, publishing to a NAS, subtitle OCR), each started from the session's tool shells. These are hours-long jobs.

Twice in three days an auto-update ended all of them at once:

| stop | new package | outage before a human noticed |
|---|---|---|
| 2026-09-11 23:22:29 | 1.52386.3.0 | 5 h 22 min |
| 2026-09-14 00:33:56 | 1.52386.6.0 | 6 h 40 min |

Each time:

• All child processes were terminated simultaneously, leaving no orphans (ffmpeg, MakeMKV, Python and PowerShell workers alike). That points to the whole process tree or job being torn down, rather than processes exiting on their own.
• Work in flight was left corrupt. Video encodes killed mid-write left MKV files with no duration or index (ffprobe reports duration: N/A), a 6.2 GB one the most recent time. They sit beside good copies and look complete to any size-based check. An optical disc rip was also lost partway.
• The watchdog died too. The process meant to notice stalls was in the same tree, so nothing raised an alarm.
• Nothing tells the session. When the conversation resumes there is no marker of the gap. The outage was only found hours later, when I asked for a status update.
• No clean shutdown was possible. With no warning there was no chance to drain queues or finish files at a safe boundary.

Evidence

From C:\ProgramData\Claude\Logs\cowork-service.log. Every stop is followed within seconds by a start on a newer package. There were four updates in four days:

2026/09/10 07:13:19  Service stop requested   -> restart on Claude_1.49585.0.0
2026/09/11 19:04:36  Service stop requested   -> restart on Claude_1.52386.0.0
2026/09/11 23:22:29  Service stop requested   -> restart on Claude_1.52386.3.0
2026/09/14 00:33:56  Service stop requested   -> restart on Claude_1.52386.6.0

The most recent occurrence, in full:

2026/09/14 00:33:56.659077 Service stop requested
2026/09/14 00:33:56.674352 Warning: failed to disarm recovery actions for this stop: open service: Access is denied.
2026/09/14 00:33:56.674941 Shutdown signal received...
2026/09/14 00:33:56.674941 [Server] Stopping server...
2026/09/14 00:33:56.674941 [Server] Stopping VM for session <user>:...\Packages\Claude_pzs8sxrjxfjjc\LocalCache\Roaming\Claude...
2026/09/14 00:33:56.675603 [Server] Server stopped
2026/09/14 00:33:56.675603 Service stopped.
2026/09/14 00:33:57.606104 Starting CoworkVMService as Windows service
2026/09/14 00:33:57.685504 [Server]   Service: C:\Program Files\WindowsApps\Claude_1.52386.6.0_x64__pzs8sxrjxfjjc\app\resources\cowork-svc.exe

The System event log has matching CoworkVMService entries at the same timestamps. The machine did not sleep or reboot; uptime was 99.5 hours at the time of writing.

Steps to reproduce

1. In a Claude Code session in Claude Desktop on Windows, start a long-running background process (Start-Process pwsh -File long-job.ps1 -WindowStyle Hidden, or any command run in the background).
2. Leave it running until Claude Desktop applies an update.
3. The process is gone. Nothing in the session says so.

Expected

At least one of:

• Defer the update while a session has live child processes, or ask first ("N background processes are running — update now or later?").
• Stop gracefully: send a termination signal and allow a grace period before a hard kill, so work can finish at a safe boundary.
• Tell the session. On resume, say that the service restarted and that background processes were ended, so the agent and the user know to recover.
• Provide a supported way to run work outside the session's process tree, so that user workloads survive an app update. As things stand, the only workaround is to launch everything through Windows Task Scheduler.

Environment

• Windows 11 Pro 10.0.26200
• Claude Desktop (MSIX), package 1.52386.3.0 → 1.52386.6.0 across the two incidents
• Claude Code running in the desktop app's Code tab