anthropics / anthropics/claude-code
[BUG] MSIX build: claude.exe / Cowork VM bundle / VM-internal claude binary all fail to land after download — ENOENT on final rename
- Dominant language
- Python
- Stars
- 145k
- Forks
- 23.1k
- PR merge metrics
- PR metrics pending
Description
### Preflight Checklist
- [x] I have searched [existing issues](https://github.com/anthropics/claude-code/issues?q=is%3Aissue%20state%3Aopen%20label%3Abug) 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?
Every download-and-install step in Claude Desktop fails at the final atomic
rename step, 100% reproducible, across three independent components:
1. CLI binary: claude-code\\claude.exe
2. Cowork VM bundle: vm_bundles\claudevm.bundle\{rootfs.vhdx,vmlinuz,initrd}
3. VM-internal Linux binary: claude-code-vm\\claude
Each download completes fully (byte count and hash match the server's
Content-Length/x-goog-hash exactly), but the rename from the temp/decompress
name to the final filename fails with ENOENT every time, on every retry.
### What Should Happen?
The CLI binary, the Cowork VM bundle, and the VM's internal binary should
each download and install successfully so that Claude Code and Cowork work
without manual file placement. At minimum, a failed rename() should fall
back to copyFile()+unlink() rather than failing outright and (for the VM
bundle) triggering an "auto-reinstall" that deletes previously-good files.
### Error Messages/Logs
```shell
[CCD] Download attempt 1/3 failed at land_rename (ENOENT) Error: ENOENT: no such file or directory, rename 'claude-code\2.1.271\claude.exe.decompress.tmp' -> 'claude-code\2.1.271\claude.exe'
[error] [download] VM download failed: ENOENT: no such file or directory, rename 'vm_bundles\claudevm.bundle\rootfs.vhdx.zst..partial' -> 'vm_bundles\claudevm.bundle\rootfs.vhdx.zst'
[error] [ClaudeCodeManager-VM] Download attempt 1/3 failed at land_rename (ENOENT) Error: ENOENT: no such file or directory, rename 'claude-code-vm\2.1.271\claude.decompress.tmp' -> 'claude-code-vm\2.1.271\claude'
[Bundle:status] rootfs.vhdx origin missing
[downloadVM] Dropping stale rootfs.vhdx cache (no origin)
[warn] rootfs.vhdx origin missing, redownloading...
[VM:steps] download_and_sdk_prepare failed (10338ms): Download failed. Check your internet connection and try again.
[VM:start] Auto-reinstalling workspace after startup failure
[deleteVMBundle] Deleted rootfs.vhdx
[deleteVMBundle] Deleted .rootfs.vhdx.origin
```
### Steps to Reproduce
1. Install Claude Desktop as the MSIX/Windows Store package on Windows 11
(PackageFullName Claude_2.110.0.0_x64__pzs8sxrjxfjjc in this case).
2. Sign in and open a session that needs the Claude Code CLI binary (any
"Code" feature), or start a Cowork session (needs the VM bundle).
3. Observe the download complete (progress reaches 100%, matches expected
byte count) then immediately fail with an ENOENT rename error as shown
above.
4. Retry any number of times — fails identically every time, including
after a full uninstall + reinstall and a full wipe of the relevant
AppData folders.
Root cause (best guess from logs, no source access): the app logs the
"logical" path under %APPDATA%\Roaming\Claude\..., but the physically real
location for an MSIX-packaged process is the virtualized per-package path
%LOCALAPPDATA%\Packages\\LocalCache\Roaming\Claude\...
This matches several other open issues describing MSIX AppData
virtualization interfering with fs.rename() (see Related Issues).
Workaround that got everything working on this machine: download each file
directly to its real physical path, decompress straight to the final
filename (skipping the temp+rename step entirely), and place the correct
marker file next to it:
- claude-code\\.verified — SHA256 hex of the compressed .zst
- vm_bundles\claudevm.bundle\.{rootfs.vhdx,vmlinuz,initrd}.origin — leading
dot required; content is the 40-char bundle version string, not a file
hash
- claude-code-vm\\.verified — same convention as the CLI binary
Happy to share the exact commands/hashes used if helpful.
### Claude Model
None
### Is this a regression?
I don't know
### Last Working Version
1.34493.1.0
### Claude Code Version
2.1.271 (Claude Code CLI); Claude Desktop 2.110.0.0 (MSIX)
### Platform
Anthropic API
### Operating System
Windows
### Terminal/Shell
Other
### Additional Information
Related issues describing the same MSIX rename/EXDEV failure family:
#27897, #30584, #36642, #38316, #42119, #38457, #30875, #47343, #89850,
#90354, #48362
Also separately noticed: the app's own settings autosave
(config.json.journal -> config.json) hits the identical rename failure —
config.json never gets created at all on this machine, only its journal.
Not blocking, but suggests the bug is general to the app's atomic-write
pattern, not just the downloader.
Contributor guide
No contributing guide indexed for this repository
Research direction
Start by reproducing the download failure in the MSIX/Windows Store package and trace the land_rename paths named in the logs, including downloadVM and ClaudeCodeManager-VM. Also inspect the config.json.journal to config.json rename, then verify that failed renames no longer prevent installation or trigger deletion of valid VM files.
Written by the indexing model from the issue text.
Assessment
- Domain
- operating-systems
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Active
- Clarity
- Mostly clear
- Newbie friendliness
- 48/100