claude-code - 💡(How to fix) Fix Windows auto-update leaves Claude Code in file-locked state — requires reboot or manual service restart [1 comments, 2 participants]

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.