Windows auto-update leaves Claude Code in file-locked state — requires reboot or manual service restart

Resolved 💬 3 comments Opened Apr 22, 2026 by JohnMoccia Closed Apr 26, 2026

Environment

  • OS: Windows 11 Pro, build 10.0.26200
  • Claude Code: desktop + CLI, auto-update enabled
  • Shell: Git Bash
  • Terminal usage: daily, multiple sessions per day

Behavior

When Claude Code auto-updates on Windows, the update installs successfully but Claude Code does not relaunch automatically. After the update completes:

  • Clicking the Claude Code desktop icon or Start-menu shortcut triggers the Windows "Open with..." app picker instead of launching the app.
  • Claude Code is not listed in the "Open with" picker — there is no app to select that resolves the launch.
  • Running claude from a terminal also fails.
  • A full Windows reboot is the only thing that restores normal launching. After reboot, the app works fine until the next auto-update.

This has happened on every auto-update in the past ~2 weeks. It's a recurring productivity hit for daily CC users on Windows.

Expected behavior

After an auto-update, Claude Code should relaunch automatically (or at minimum, the next manual click should launch it cleanly — no reboot required).

Reproduction

  1. Be on Windows 11 with Claude Code installed and auto-update enabled.
  2. Use Claude Code until the in-app update prompt appears.
  3. Accept the update and let it install.
  4. Try to launch Claude Code via desktop icon, Start menu, or terminal.

Actual: Windows "Open with" dialog appears. App unusable until reboot.

Workaround (no reboot needed)

Running this in an admin PowerShell restores CC to a launchable state in ~5 seconds:

Stop-Service CoworkVMService -Force -ErrorAction SilentlyContinue
taskkill /F /IM "claude.exe" 2>$null
taskkill /F /IM "cowork-svc.exe" 2>$null
Start-Sleep 2
Set-Service CoworkVMService -StartupType Automatic
Start-Service CoworkVMService

This suggests the root cause is CoworkVMService holding an exclusive file lock on the CC binary during the MSIX package swap, leaving the new binary in a state Windows can't execute until the lock is released or the machine reboots. Stopping the service before the update, or killing it + restarting after, resolves the lock.

Suggested fix paths

  • Have the auto-updater stop CoworkVMService (and any child processes) before the MSIX swap, then restart it after.
  • Or: wait for all CC file handles to release before marking the update complete + attempting relaunch.
  • Or: if the updater can't reliably do this, surface a clear error to the user ("The update completed but Claude Code could not relaunch — please run the attached unstick script") instead of leaving them stuck at an "Open with..." dialog with no app to pick.

Frequency

Happens on every auto-update since ~mid-April 2026. Multiple users on Windows seem to hit this based on GitHub issue search.

Happy to provide logs if there's a specific log path to grab. Thanks.

View original on GitHub ↗

This issue has 3 comments on GitHub. Read the full discussion on GitHub ↗