[BUG] Title: Packaged Windows Service (CoworkVMService) lifecycle intermittently corrupts MSIX package ACLs, causing Claude Desktop launch failures ("another program is using this file")

Preflight Checklist

• [x] I have searched existing issues and this hasn't been reported yet
• [x] This is a single bug report (please file separate reports for different bugs)
• [x] I am using the latest version of Claude Code

What's Wrong?

Title: Packaged Windows Service (CoworkVMService) lifecycle intermittently corrupts MSIX package ACLs, causing Claude Desktop launch failures ("another program is using this file")

Impact

Claude Desktop intermittently fails to launch on Windows, surfacing as a Windows-level file-in-use/access error. The condition is self-healing (Windows' own repair mechanism resolves it, typically within under a second) but requires a failed launch attempt to trigger the fix, producing a visible failure to the user before a retry succeeds.

Environment

• Windows 11, MSIX/AppX package family Claude_pzs8sxrjxfjjc
• Affected versions (confirmed across 3 separate updates): 1.44121.4.0, 1.46388.1.0, 1.46388.2.0
• Observed over a 2-day window (Sep 3–4), 15 confirmed occurrences

Reproduction conditions

Not independently reproducible on demand; occurs intermittently as a side effect of the packaged service's normal lifecycle (see mechanism below). Occurrence density appears to scale with how often CoworkVMService starts/stops — observed clusters of several occurrences within minutes to hours, spread across ordinary app usage (window close, idle timeout) with no unusual user action required.

Proven facts (all evidence gathered locally, read-only, via built-in Windows tools plus Microsoft Sysinternals Handle)

1. No file handle is held on the package. Sysinternals Handle.exe (Microsoft-signed binary, Authenticode-verified), run elevated, both targeted at the CoworkVMService PID and system-wide with a substring search for the package folder name, returned zero matches. This rules out a literal open file handle as the cause of the "in use" error.
2. SCM crash-recovery is not configured and is not the restart mechanism. sc.exe qfailure CoworkVMService returns RESET_PERIOD: 0 with no restart/reboot/run-command action configured.
3. The service is registered with a named-pipe activation trigger, confirmed by direct registry read (HKLM\SYSTEM\CurrentControlSet\Services\CoworkVMService\TriggerInfo\0): Type=20 (SERVICE_TRIGGER_TYPE_NAMED_PIPE_EVENT), Action=1 (start), trigger GUID 1f81d131-3e60-4c76-9860-37334e4ffce3, data \pipe\cowork-vm-service — verified byte-for-byte against the value and matching the app's own AppxManifest.xml (desktop6:TriggerCustom, same GUID and pipe name). This causes SCM to auto-start the service the instant any process attempts to connect to its own pipe, independent of failure/recovery logic.
4. Every service restart re-registers the SCM service entry as a SYSTEM-context operation. System log Event 7040 ("start type changed to disabled") immediately followed by Event 7045 ("A service was installed... Service Name: Claude... Service File Name: cowork-svc.exe... Service Account: LocalSystem"), both under UserId = NT AUTHORITY\SYSTEM (verified via event XML). Observed 20 times (41 raw events) across the sampled window.
5. RegisterByPackageFullName + RepairAppRegistrationOption fires and repairs ACLs. Microsoft-Windows-AppXDeploymentServer/Operational logs this operation (the OS's own launch-triggered self-repair path) twice directly captured in detail, each time immediately logging: "Trying to repair ACLs for ...Claude_1.46388.2.0_x64__pzs8sxrjxfjjc" → "ACLs repaired successfully... Register next time should succeed" → service terminate/reinstall via PackagedServiceDEH → "Deployment Register operation... finished successfully."
6. This ACL-repair event (Id 649) recurs across versions and days: 10 occurrences on 1.44121.4.0 (Sep 3, 1:26–2:33 PM), 2 on 1.46388.1.0 (Sep 4, 11:05–11:10 AM), 3 on 1.46388.2.0 (Sep 4, 5:59–7:20 PM). 15 total.
7. 100% correlation with the service re-registration events: for all 15 ACL-repair timestamps, exactly 2 CoworkVMService/"Claude" SCM events (a 7040+7045 pair) fall within a −2s/+3s window — 15/15.
8. The package's current ACL is stable, not perpetually broken: icacls on the package folder shows 3 non-inherited, package-specific ACEs (a granular BUILTIN\Users grant, the package's own capability SID with RX, a second generic BUILTIN\Users R grant) layered on 7 inherited baseline ACEs (TrustedInstaller, SYSTEM, Administrators, Local/Network Service, Restricted, a second capability SID). This ACL was confirmed intact both immediately after a repair and again roughly an hour later, after further service cycles had occurred — so the defect is intermittent, not a permanently-broken state.
9. The service itself does not need the missing ACEs for its own operation. sc.exe qsidtype CoworkVMService = UNRESTRICTED; sc.exe qprivs returns no required privileges. The service runs as LocalSystem with full inherited access already. The two package-specific ACEs that go missing are what an interactive launch (running under BUILTIN\Users) needs to read the package's own app files — consistent with the observed symptom being a launch failure, not a service failure.
10. Manifest confirms the packaging model. AppxManifest.xml declares restricted capabilities localSystemServices, packagedServices, unvirtualizedResources alongside runFullTrust, plus the windows.service extension (CoworkVMService, StartupType="auto", StartAccount="localSystem", the same named-pipe trigger). This is an uncommon combination — a LocalSystem Windows Service bundled inside an MSIX package with real (non-virtualized) filesystem access.

Ruled out (evidence, not assumption)

• Windows Defender: 169 Operational-log events sampled across the same 32-hour window; none land within minutes of 14 of the 15 ACL-repair timestamps. The one loose proximity (an Event 5007 config-change burst) is explained by Defender's routine periodic definition-update cadence, which recurs many other times throughout the day with no relation to any repair timestamp.
• MDM/Intune: DeviceManagement-Enterprise-Diagnostics-Provider/Admin log sampled; nearest events to any ACL-repair timestamp are 3–18 minutes away — no tight correlation.
• Group Policy: Microsoft-Windows-GroupPolicy/Operational log has zero events in the entire 32-hour window. No GP activity occurred at all, let alone correlated with the repairs.

Suspected mechanism (inference, clearly distinguished from the proven facts above)

The named-pipe trigger causes CoworkVMService to recycle far more frequently than an app's normal update cadence would ever require — effectively on every client idle-disconnect, observed multiple times per hour. Because this packaged-service model couples "service restart" to "package disable → PackagedServiceDEH reinstall → package re-enable" (observed on every cycle, not just version updates), the disable/re-enable path runs orders of magnitude more often for this package than the code path was likely exercised for during typical Store-app testing (which mostly hits this path only on genuine version installs).

We suspect that path is not perfectly idempotent with respect to reapplying the package's non-inherited ACEs across repeated cycling, causing them to intermittently drop (15 of ~20 observed cycles). When that happens, the next interactive launch fails with an access-denied-class error, which Windows' activation stack surfaces to the user and reactively repairs via RegisterByPackageFullName + RepairAppRegistrationOption — always succeeding once triggered, but only after a visible launch failure.

We have not reproduced or inspected the exact OS-internal step that drops the ACEs — that lives inside Windows' AppX servicing implementation and is outside what's inspectable from a client machine.

Requested action

Please investigate whether CoworkVMService's lifecycle needs to recycle (and therefore force a package disable/re-enable cycle) as often as it currently does — e.g., on every idle client-disconnect via the named-pipe trigger — versus only on genuine version updates. Reducing that cycling frequency would remove the repeated exposure to whatever gap exists in the disable/re-enable ACL reapplication, without requiring any change to the ACL-repair mechanism itself. We are not requesting or attempting any local ACL or service-registration modification — this report is scoped to the packaged-service lifecycle design.

What Should Happen?

Please investigate whether CoworkVMService's lifecycle needs to recycle (and therefore force a package disable/re-enable cycle) as often as it currently does — e.g., on every idle client-disconnect via the named-pipe trigger — versus only on genuine version updates. Reducing that cycling frequency would remove the repeated exposure to whatever gap exists in the disable/re-enable ACL reapplication, without requiring any change to the ACL-repair mechanism itself. We are not requesting or attempting any local ACL or service-registration modification — this report is scoped to the packaged-service lifecycle design.

Error Messages/Logs

Steps to Reproduce

Suspected mechanism (inference, clearly distinguished from the proven facts above)

The named-pipe trigger causes CoworkVMService to recycle far more frequently than an app's normal update cadence would ever require — effectively on every client idle-disconnect, observed multiple times per hour. Because this packaged-service model couples "service restart" to "package disable → PackagedServiceDEH reinstall → package re-enable" (observed on every cycle, not just version updates), the disable/re-enable path runs orders of magnitude more often for this package than the code path was likely exercised for during typical Store-app testing (which mostly hits this path only on genuine version installs).

We suspect that path is not perfectly idempotent with respect to reapplying the package's non-inherited ACEs across repeated cycling, causing them to intermittently drop (15 of ~20 observed cycles). When that happens, the next interactive launch fails with an access-denied-class error, which Windows' activation stack surfaces to the user and reactively repairs via RegisterByPackageFullName + RepairAppRegistrationOption — always succeeding once triggered, but only after a visible launch failure.

We have not reproduced or inspected the exact OS-internal step that drops the ACEs — that lives inside Windows' AppX servicing implementation and is outside what's inspectable from a client machine

Claude Model

None

Is this a regression?

Yes, this worked in a previous version

Last Working Version

_No response_

Claude Code Version

latest

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

PowerShell

Additional Information

_No response_