Windows: app installs/reconfigures CoworkVMService on every launch even though Cowork is disabled for my org, causing "file in use" launch failures

Environment

• Claude desktop app: 1.30096.1.0 (MSIX, Claude_1.30096.1.0_x64__pzs8sxrjxfjjc)
• OS: Windows 11 Enterprise 10.0.26100, corporate-managed device, non-admin user account
• Org policy: Cowork is disabled for my organization (confirmed in-app under Settings)

Symptom
Some mornings, launching the Claude app fails immediately with:

Another program is currently using this file.

The app won't open at all until a full OS restart. No visible claude.exe process is present in Task Manager when this happens, so it isn't a simple leftover foreground process.

Root cause (from Event Viewer)
Despite Cowork being disabled for the org, the app repeatedly installs and starts a service called CoworkVMService (display name "Claude", binary ...\WindowsApps\Claude_1.30096.1.0_x64__...\app\resources\cowork-svc.exe, LocalSystem, auto-start) on launch. Each cycle fails partway:

Service Control Manager (7045): service installed — Claude / cowork-svc.exe / auto start / LocalSystem
CoworkVMService: Claude VM Service starting.
CoworkVMService (Warning): failed to configure SCM recovery actions: open service: Access is denied.
CoworkVMService: Claude VM Service stopped.
Service Control Manager (7040): start type changed from auto start to disabled.

This install → start → access-denied → stop → disable sequence repeated 5 times over ~40 minutes on one morning, each aligned with a failed launch attempt. Only a full reboot cleared whatever was holding the lock; ending user-mode processes did not (none were present to end). The cycle also happens fast enough (within the same second per log timestamps) that it can't be caught/interrupted manually via Task Manager, and ending the service there wouldn't be possible anyway since it runs as LocalSystem under a non-admin account.

Requests

1. Don't attempt to install/reconfigure the Cowork VM service at all when Cowork is disabled for the organization.
2. Make the SCM recovery-config step non-fatal / non-retriggering on "Access is denied" so it can't leave a file locked.
3. Avoid a state where the only recovery from a failed launch is a full OS restart.