Issue Station
Sign In
Tools hereToolbox

claude-code - 💡(How to fix) Fix [BUG] Claude Desktop (Windows/MSIX) — stale file lock on WindowsApps package, only full reboot resolves it [1 comments, 2 participants]

Official PRs (…)
ON THIS PAGE

Recommended Tools

×6

Utilities matched from this issue’s tags and category — try them while you read without losing context.

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

Helpful · Quick feedback

Loading…
GitHub stats
anthropics/claude-code#48787•Fetched 2026-04-16 06:50:58
View on GitHub
Comments
1
Participants
2
Timeline
2
Reactions
0
Author
Rapzone95Rapzone95
Participants
github-actions[bot]github-actions[bot]Rapzone95Rapzone95
Timeline (top)
commented ×1labeled ×1

After Claude Desktop closes (or after an in-app update), a stale file lock remains on the MSIX package executable under C:\Program Files\WindowsApps\Claude_1.2773.0.0_x.... Attempting to reopen the app results in:

"Aktualnie inny program korzysta z tego pliku." / "Another program is currently using this file."

Only a full Windows reboot clears the lock. All other workarounds fail.

Error Message

  1. Error dialog appears: "Another program is currently using this file"
  • #40645 — "File is busy" error after update

Root Cause

Root cause (suspected)

Fix Action

Fix / Workaround

Only a full Windows reboot clears the lock. All other workarounds fail.

Workarounds attempted (all failed)

RAW_BUFFERClick to expand / collapse

Summary

After Claude Desktop closes (or after an in-app update), a stale file lock remains on the MSIX package executable under C:\Program Files\WindowsApps\Claude_1.2773.0.0_x.... Attempting to reopen the app results in:

"Aktualnie inny program korzysta z tego pliku." / "Another program is currently using this file."

Only a full Windows reboot clears the lock. All other workarounds fail.

Environment

  • OS: Windows 11 Pro 10.0.26200
  • Claude Desktop version: 1.2773.0.0 (MSIX / Windows Store install)
  • Install location: C:\Program Files\WindowsApps\Claude_1.2773.0.0_x...

Steps to reproduce

  1. Open Claude Desktop normally
  2. Close it (via X button or system tray → Quit)
  3. Attempt to reopen Claude Desktop
  4. Error dialog appears: "Another program is currently using this file"

Workarounds attempted (all failed)

  • Stop-Service CoworkVMService -Force — service stops but lock persists
  • Stop-Process -Name 'cowork-svc' -Force — process killed but lock persists
  • Restart-Service AppXSvc -Force — MSIX service restarted but lock persists
  • Killing all claude.exe / cowork-svc processes via Task Manager — lock persists
  • Full Windows reboot — resolves the issue ✓

Root cause (suspected)

The Electron/Squirrel updater or CoworkVMService does not fully release its file handle on the .exe before exiting. Windows retains the lock at the kernel level even after the owning process terminates. Since no process owns the handle, it cannot be released without a reboot.

This happens every time Claude Desktop is closed, not only after updates — making normal daily usage extremely disruptive.

Related issues

  • #45896 — Stale file lock after in-app update (closed as "not planned")
  • #42776 — Orphaned process file lock on relaunch
  • #40645 — "File is busy" error after update

Request

Please reopen / re-prioritize this. Closing #45896 as "not planned" is not acceptable when the bug makes Claude Desktop unusable on Windows without rebooting after every session. At minimum, the app should ensure all handles are closed before the process exits, and/or CoworkVMService should be stopped gracefully on shutdown.

🤖 Reported via Claude Code

extent analysis

TL;DR

The most likely fix involves ensuring that the Electron/Squirrel updater or CoworkVMService releases its file handle on the executable before exiting, potentially requiring code changes to handle process termination more gracefully.

Guidance

  • Investigate the Electron/Squirrel updater and CoworkVMService code to identify where file handles are acquired and released, focusing on the termination process.
  • Verify if there are any open issues or pull requests related to file handle management in the Electron or Squirrel libraries that could be relevant.
  • Consider implementing a workaround to stop CoworkVMService more gracefully on shutdown, potentially using a different approach than Stop-Service or Stop-Process.
  • Review the related issues (#45896, #42776, #40645) for any insights or potential fixes that may have been overlooked.

Example

No specific code snippet can be provided without access to the Electron/Squirrel updater or CoworkVMService codebase, but ensuring that all file handles are properly closed before process termination is crucial.

Notes

The issue seems to be related to how Windows handles file locks at the kernel level, and resolving this may require changes to the application's code or its interaction with Windows services.

Recommendation

Apply a workaround to ensure that all file handles are closed before the process exits, as upgrading to a fixed version is not currently an option due to the nature of the issue. This approach may involve modifying the application's shutdown process or interacting differently with Windows services.

Vote matrix · Quick signals

Works
Did the solution work? Tap to confirm.
Easy Fix
Was it a quick fix?
Time Saver
Did it save you time?
Blocking
Was it severely blocking?
Common Issue
Are others likely hitting this too?
Flaky / Intermittent
Is it intermittent?
Verified / Reproducible
Can you reproduce it reliably?
Loading…
#chain error#conversation history#tool integration#LLM response#prompt template

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

Back to top recommendations

TRENDING

claude-code - 💡(How to fix) Fix [BUG] Claude Desktop (Windows/MSIX) — stale file lock on WindowsApps package, only full reboot resolves it [1 comments, 2 participants]