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

Open
#95,112 0 comments 0 reactions 0 assignees View on GitHub
area:cowork area:desktop area:installation bug platform:windows
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

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.