[BUG] Windows service (CoworkVMService) flaps disabled/enabled during MSIX auto-update, blocked by EBUSY on chrome-native-host.exe

Status Open
Reported on v2.1.234
Maintainer reply None cached
Activity 0 comments · opened Aug 19, 2026

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?

Environment: Windows 11, Claude desktop app installed via MSIX (WindowsApps).
Service: "Claude" (CoworkVMService), display name Claude, backed by cowork-svc.exe.

What happens: During app auto-update, the update sometimes gets stuck for 20-40 minutes instead of completing near-instantly. During that window, the Windows service repeatedly toggles between "installed/Automatic" and "disabled" (observed 6 reinstall events in 18 seconds at one point), making the app briefly unusable multiple times per evening.

Root cause found in main.log: repeated errors during the stuck window:

[Chrome Extension MCP] Failed to copy native host binary: Error: EBUSY: resource busy or locked, copyfile 'C:\Program Files\WindowsApps\Claude_<version>_x64__.../app/resources/chrome-native-host.exe' -> '%APPDATA%\Claude\ChromeNativeHost\chrome-native-host.exe'

The native host binary appears to still be locked/in-use when the MSIX update tries to replace it, causing the update transaction to retry repeatedly instead of completing cleanly. This happened 3 times in one evening (2026-08-19), each time self-resolving after 20-40 minutes.

Separately: the underlying Windows service's security descriptor only grants SERVICE_CHANGE_CONFIG to a specific NT SERVICE virtual account, not to Administrators - so no local admin-level workaround (e.g. sc.exe failure recovery actions) is possible to mitigate the flapping while waiting for a fix.

Expected: the update should complete without the app service repeatedly disabling itself, and without holding a lock on chrome-native-host.exe past the point where it needs to be replaced.

What Should Happen?

The app update should complete without the underlying Windows service (CoworkVMService) repeatedly disabling itself, and without holding a lock on chrome-native-host.exe past the point where the MSIX update needs to replace it.

Error Messages/Logs

Steps to Reproduce

This is a background/service-level issue rather than a specific CLI command sequence:

  1. Have the Claude desktop app (MSIX/WindowsApps install) running normally on Windows.
  2. Let the app auto-update trigger in the background (happens periodically; observed 3 times in one evening on 2026-08-19).
  3. Watch %APPDATA%\Claude\logs\main.log during the update window.
  4. When the update gets stuck (not always reproducible on demand - happened when chrome-native-host.exe was still locked), repeated log lines appear:

"[Chrome Extension MCP] Failed to copy native host binary: Error: EBUSY: resource busy or locked, copyfile ... -> ...\chrome-native-host.exe"

  1. In parallel, Windows Event Viewer (System log, Service Control Manager source) shows repeated pairs of event 7045 (service installed) followed immediately by event 7040 (service Claude/CoworkVMService startup type changed from Automatic to Disabled) - up to 6 cycles observed in 18 seconds.
  2. During this window, Get-Service CoworkVMService alternates between Running/Automatic and Disabled/Stopped, and the app is intermittently unusable.
  3. Eventually (20-40 minutes later) the update completes, logged as "[CCD-autoupdate] Disabled: MSIX install" followed by "[updater] App is installed, enabling initial check and auto-updates", and the service stabilizes on Running/Automatic.

Not something I can force on demand - it only manifested when the update transaction hit the file lock. Happy to share the relevant excerpt of main.log if useful.

Claude Model

None

Is this a regression?

Yes, this worked in a previous version

Last Working Version

_No response_

Claude Code Version

2.1.234 (Claude Code)

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

PowerShell

Additional Information

_No response_

View original on GitHub ↗