### 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? Cowork permanently fails to start on Windows 11 because the Claude Desktop MSIX process applies EFS (Encrypting File System) encryption attributes to the

[BUG] Cowork Windows: MSIX container applies EFS encryption to vm_bundles folder on every launch, copyfile for smol-bin.vhdx permanently fails

Status Fixed / completed

Maintainer reply None cached

Activity 7 comments · opened Feb 14, 2026 · closed Aug 25, 2026

Preflight Checklist

[x] I have searched existing issues 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?

Cowork permanently fails to start on Windows 11 because the Claude Desktop MSIX process applies EFS (Encrypting File System) encryption attributes to the vm_bundles\claudevm.bundle directory every time it creates or recreates the folder. The app's startup flow attempts to copy smol-bin.x64.vhdx from the WindowsApps installation directory into this encrypted folder, which fails. The app aborts before ever sending a configure or startVM command to the cowork-svc service.
This is a distinct root cause from the DNS/API reachability issues in #24918, #24962, #24974, #25088, #25155, and #25206. The workspace never reaches the VM boot stage — it fails during initial file preparation.

<html>
<body>
<h2 class="text-text-100 mt-3 -mb-1 text-[1.125rem] font-bold">Root Cause Analysis</h2>
<p class="font-claude-response-body break-words whitespace-normal leading-[1.7]">The Claude Desktop MSIX app container applies NTFS EFS encryption attributes to the <code class="bg-text-200/5 border border-0.5 border-border-300 text-danger-000 whitespace-pre-wrap rounded-[0.4rem] px-1 py-px text-[0.9rem]">vm_bundles\claudevm.bundle</code> directory when it creates it. This was confirmed via <code class="bg-text-200/5 border border-0.5 border-border-300 text-danger-000 whitespace-pre-wrap rounded-[0.4rem] px-1 py-px text-[0.9rem]">cipher</code> showing "E" (encrypted) on the folder. The parent folders (<code class="bg-text-200/5 border border-0.5 border-border-300 text-danger-000 whitespace-pre-wrap rounded-[0.4rem] px-1 py-px text-[0.9rem]">AppData\Roaming</code> and <code class="bg-text-200/5 border border-0.5 border-border-300 text-danger-000 whitespace-pre-wrap rounded-[0.4rem] px-1 py-px text-[0.9rem]">AppData\Roaming\Claude</code>) are <strong>not</strong> encrypted — the encryption is introduced specifically by the MSIX process context when creating the subfolder tree.</p>
<p class="font-claude-response-body break-words whitespace-normal leading-[1.7]">When the app attempts to copy <code class="bg-text-200/5 border border-0.5 border-border-300 text-danger-000 whitespace-pre-wrap rounded-[0.4rem] px-1 py-px text-[0.9rem]">smol-bin.x64.vhdx</code> from WindowsApps into this encrypted folder, Windows tries to encrypt the destination file during the copy, which fails because the necessary EFS certificate context is not available. This copy runs on <strong>every launch</strong> as part of the app's startup flow, meaning manual workarounds are undone each time.</p>
<p class="font-claude-response-body break-words whitespace-normal leading-[1.7]">Additionally, the <code class="bg-text-200/5 border border-0.5 border-border-300 text-danger-000 whitespace-pre-wrap rounded-[0.4rem] px-1 py-px text-[0.9rem]">cldflt</code> (Windows Cloud Files / OneDrive) filesystem filter driver was found to be loaded system-wide (confirmed via <code class="bg-text-200/5 border border-0.5 border-border-300 text-danger-000 whitespace-pre-wrap rounded-[0.4rem] px-1 py-px text-[0.9rem]">fltmc</code>), which may be contributing to the encryption behavior or interfering with file operations, even when OneDrive is not syncing the affected folders.</p>
<h3 class="text-text-100 mt-2 -mb-1 text-base font-bold">Why manual fixes don't persist</h3>
<p class="font-claude-response-body break-words whitespace-normal leading-[1.7]">Through extensive testing, we confirmed that the app deletes and recreates <code class="bg-text-200/5 border border-0.5 border-border-300 text-danger-000 whitespace-pre-wrap rounded-[0.4rem] px-1 py-px text-[0.9rem]">vm_bundles</code> on each launch. The MSIX container re-applies EFS encryption to the new folder, and the copyfile operation for <code class="bg-text-200/5 border border-0.5 border-border-300 text-danger-000 whitespace-pre-wrap rounded-[0.4rem] px-1 py-px text-[0.9rem]">smol-bin.x64.vhdx</code> fails again. This makes all manual interventions (decryption, file pre-staging, junctions) temporary at best.</p>
<h3 class="text-text-100 mt-2 -mb-1 text-base font-bold">Service starts fine — app never configures it</h3>
<p class="font-claude-response-body break-words whitespace-normal leading-[1.7]">By manually launching <code class="bg-text-200/5 border border-0.5 border-border-300 text-danger-000 whitespace-pre-wrap rounded-[0.4rem] px-1 py-px text-[0.9rem]">cowork-svc.exe</code> via PsExec, we confirmed the VM service starts successfully, initializes HCS/HCN, detects the NAT network, and listens on the named pipe. When Claude Desktop connects, it exchanges <code class="bg-text-200/5 border border-0.5 border-border-300 text-danger-000 whitespace-pre-wrap rounded-[0.4rem] px-1 py-px text-[0.9rem]">isGuestConnected</code> and <code class="bg-text-200/5 border border-0.5 border-border-300 text-danger-000 whitespace-pre-wrap rounded-[0.4rem] px-1 py-px text-[0.9rem]">subscribeEvents</code> calls but <strong>never sends a <code class="bg-text-200/5 border border-0.5 border-border-300 text-danger-000 whitespace-pre-wrap rounded-[0.4rem] px-1 py-px text-[0.9rem]">configure</code> or <code class="bg-text-200/5 border border-0.5 border-border-300 text-danger-000 whitespace-pre-wrap rounded-[0.4rem] px-1 py-px text-[0.9rem]">startVM</code> command</strong>. The service log shows:</p>
<div class="relative group/copy bg-bg-000/50 border-0.5 border-border-400 rounded-lg"><div class="sticky opacity-0 group-hover/copy:opacity-100 top-2 py-2 h-12 w-0 float-right"><div class="absolute right-0 h-8 px-2 items-center inline-flex z-10"><button class="inline-flex
items-center
justify-center
relative
shrink-0
can-focus
select-none
disabled:pointer-events-none
disabled:opacity-50
disabled:shadow-none
disabled:drop-shadow-none border-transparent
transition
font-base
duration-300
ease-[cubic-bezier(0.165,0.85,0.45,1)] h-8 w-8 rounded-md active:scale-95 backdrop-blur-md Button_ghost__BUAoh" type="button" aria-label="Copy to clipboard" data-state="closed"><div class="relative"><div class="transition-all opacity-100 scale-100" style="width: 20px; height: 20px; display: flex; align-items: center; justify-content: center;"><svg width="20" height="20" viewBox="0 0 20 20" fill="currentColor" xmlns="http://www.w3.org/2000/svg" class="transition-all opacity-100 scale-100" aria-hidden="true" style="flex-shrink: 0;"><path d="M12.5 3C13.3284 3 14 3.67157 14 4.5V6H15.5C16.3284 6 17 6.67157 17 7.5V15.5C17 16.3284 16.3284 17 15.5 17H7.5C6.67157 17 6 16.3284 6 15.5V14H4.5C3.67157 14 3 13.3284 3 12.5V4.5C3 3.67157 3.67157 3 4.5 3H12.5ZM14 12.5C14 13.3284 13.3284 14 12.5 14H7V15.5C7 15.7761 7.22386 16 7.5 16H15.5C15.7761 16 16 15.7761 16 15.5V7.5C16 7.22386 15.7761 7 15.5 7H14V12.5ZM4.5 4C4.22386 4 4 4.22386 4 4.5V12.5C4 12.7761 4.22386 13 4.5 13H12.5C12.7761 13 13 12.7761 13 12.5V4.5C13 4.22386 12.7761 4 12.5 4H4.5Z"></path></svg></div><div class="absolute inset-0 flex items-center justify-center"><div class="transition-all opacity-0 scale-50" style="width: 20px; height: 20px; display: flex; align-items: center; justify-content: center;"><svg width="20" height="20" viewBox="0 0 20 20" fill="currentColor" xmlns="http://www.w3.org/2000/svg" class="transition-all opacity-0 scale-50" aria-hidden="true" style="flex-shrink: 0;"><path d="M15.1883 5.10908C15.3699 4.96398 15.6346 4.96153 15.8202 5.11592C16.0056 5.27067 16.0504 5.53125 15.9403 5.73605L15.8836 5.82003L8.38354 14.8202C8.29361 14.9279 8.16242 14.9925 8.02221 14.9989C7.88203 15.0051 7.74545 14.9526 7.64622 14.8534L4.14617 11.3533L4.08172 11.2752C3.95384 11.0811 3.97542 10.817 4.14617 10.6463C4.31693 10.4755 4.58105 10.4539 4.77509 10.5818L4.85321 10.6463L7.96556 13.7586L15.1161 5.1794L15.1883 5.10908Z"></path></svg></div></div></div></button></div></div><div class="overflow-x-auto"><pre class="code-block__code !my-0 !rounded-lg !text-sm !leading-relaxed p-3.5" style="color: rgb(234, 236, 240); background: transparent; font-family: var(--font-mono);"><code style="color: rgb(234, 236, 240); background: transparent; font-family: var(--font-mono); white-space: pre-wrap;"><span><span>Waiting for configuration from app via 'configure' method...</span></span></code></pre></div></div>
<p class="font-claude-response-body break-words whitespace-normal leading-[1.7]">This confirms the app's own startup code aborts at the file preparation stage (the smol-bin copyfile) before it ever reaches VM configuration. The service itself is not the problem.</p>
<h2 class="text-text-100 mt-3 -mb-1 text-[1.125rem] font-bold">Extensive Troubleshooting Performed</h2>
<h3 class="text-text-100 mt-2 -mb-1 text-base font-bold">Phase 1: Identifying EFS encryption as the cause</h3>
<div class="overflow-x-auto w-full px-2 mb-6">
Step | Result

Checked AppData\Roaming and AppData\Roaming\Claude with cipher | Both showed "U" (unencrypted)

Checked vm_bundles\claudevm.bundle with cipher | Showed "E" (encrypted) — this was the source of the problem

Manual copy via Command Prompt | Failed: "file could not be encrypted"

Copy as SYSTEM via PsExec (PsExec64.exe -s cmd /c copy) | Failed: same encryption error

robocopy /B /COPY:D (backup mode, data only) | Succeeded — stripped encryption attributes during copy. File copied successfully (36 MB)

Manually decrypting folder via cipher /d then creating sessiondata.vhdx via New-VHD | Initially failed with 0x80071772 (encrypted), succeeded after cipher /d

</div>
<html>
<body>
<h3 class="text-text-100 mt-2 -mb-1 text-base font-bold">Phase 2: Attempting to make the fix permanent</h3>
<div class="overflow-x-auto w-full px-2 mb-6">
Step | Result

cipher /d on destination folders before launch | Claude Desktop recreated folders with encryption on next launch

Pre-creating folder structure and marking unencrypted before launch | Claude Desktop still recreated with encryption

fsutil behavior set disableencryption 1 + full reboot | Did not prevent MSIX container from applying EFS

Junction vm_bundles to AppData\Local to bypass cldflt filter driver | Download succeeded, but MSIX still applied EFS to the junction target. Errors shifted from "could not be encrypted" to "Access Denied"

Uninstall + reinstall with junction pre-staged | Same result — EFS applied to junction target

Copying smol-bin to intermediate C:\Temp via robocopy, then to destination | Intermediate copy succeeded, but copy from temp to destination failed with Access Denied even after takeown and icacls /grant

WSL2 cp from temp to destination | Permission denied

Windows Explorer drag-and-drop from temp to destination | Access Denied

</div>
<html>
<body>
<h3 class="text-text-100 mt-2 -mb-1 text-base font-bold">Phase 3: Confirming the service is not the problem</h3>
<div class="overflow-x-auto w-full px-2 mb-6">
Step | Result

Manually launched cowork-svc.exe via PsExec64.exe -s | Service started successfully, HCS/HCN initialized, named pipe listening

Opened Claude Desktop with service pre-started | App connected, exchanged isGuestConnected/subscribeEvents calls, but never sent configure or startVM

Checked cowork_vm_node.log | Log shows "Module loaded successfully" and then nothing — no [VM:start] Configuring Windows VM service... line ever appears

</div>
</body>
</html>
</body>
</html>
<h3 class="text-text-100 mt-2 -mb-1 text-base font-bold">Additional observations</h3>
<ul class="[li_&]:mb-0 [li_&]:mt-1 [li_&]:gap-1 [&:not(:last-child)_ul]:pb-1 [&:not(:last-child)_ol]:pb-1 list-disc flex flex-col gap-1 pl-8 mb-3">
<li class="whitespace-normal break-words pl-2">The app logs "All files ready" even when <code class="bg-text-200/5 border border-0.5 border-border-300 text-danger-000 whitespace-pre-wrap rounded-[0.4rem] px-1 py-px text-[0.9rem]">smol-bin.vhdx</code> and <code class="bg-text-200/5 border border-0.5 border-border-300 text-danger-000 whitespace-pre-wrap rounded-[0.4rem] px-1 py-px text-[0.9rem]">sessiondata.vhdx</code> are missing from the bundle directory</li>
<li class="whitespace-normal break-words pl-2">The app never creates <code class="bg-text-200/5 border border-0.5 border-border-300 text-danger-000 whitespace-pre-wrap rounded-[0.4rem] px-1 py-px text-[0.9rem]">sessiondata.vhdx</code> (known issue from #24962 and #24974)</li>
<li class="whitespace-normal break-words pl-2"><code class="bg-text-200/5 border border-0.5 border-border-300 text-danger-000 whitespace-pre-wrap rounded-[0.4rem] px-1 py-px text-[0.9rem]">fltmc</code> shows <code class="bg-text-200/5 border border-0.5 border-border-300 text-danger-000 whitespace-pre-wrap rounded-[0.4rem] px-1 py-px text-[0.9rem]">cldflt</code> (OneDrive Cloud Files filter) loaded system-wide, even though OneDrive is only syncing <code class="bg-text-200/5 border border-0.5 border-border-300 text-danger-000 whitespace-pre-wrap rounded-[0.4rem] px-1 py-px text-[0.9rem]">C:\Users\<user>\OneDrive</code></li>
<li class="whitespace-normal break-words pl-2">After disabling EFS and using junctions, errors shifted from encryption-related to Access Denied, suggesting a secondary MSIX container filesystem virtualization issue</li></ul>
</body>
</html>

What Should Happen?

Expected Behavior

The MSIX app container should create vm_bundles without EFS encryption attributes
The copyfile operation for smol-bin.x64.vhdx should succeed
sessiondata.vhdx should be created automatically
The app should proceed to send configure and startVM to the cowork-svc service

Suggested Fix
The MSIX package or the app's folder creation logic should explicitly prevent EFS encryption on the vm_bundles folder. Possible approaches:

Call DecryptFile() or SetFileAttributes() to clear encryption after folder creation
Use CreateDirectory with attributes that exclude EFS inheritance
Copy smol-bin.vhdx using raw byte streams rather than filesystem copy (bypasses EFS)
Add cipher /d as a step in the workspace setup pipeline
Detect EFS on the target folder and handle it gracefully

Error Messages/Logs

Failed to start Claude's workspace
UNKNOWN: unknown error, copyfile
'C:\Program Files\WindowsApps\Claude_1.1.3189.0_x64__pzs8sxrjxfjjc\app\resources\smol-bin.x64.vhdx'
-> 'C:\Users\<user>\AppData\Roaming\Claude\vm_bundles\claudevm.bundle\smol-bin.vhdx'

Steps to Reproduce

Install Claude Desktop v1.1.3189.0 from Microsoft Store (MSIX) on Windows 11
Ensure Hyper-V is enabled
Open Claude Desktop and switch to the Cowork tab
Observe "Failed to start Claude's workspace" copyfile error

Claude Model

Opus

Is this a regression?

No, this never worked

Last Working Version

_No response_

Claude Code Version

Claude Desktop v1.1.3189.0

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

WSL (Windows Subsystem for Linux)

Additional Information

<html>
<body>
<h2 class="text-text-100 mt-3 -mb-1 text-[1.125rem] font-bold">Environment</h2>
<ul class="[li_&]:mb-0 [li_&]:mt-1 [li_&]:gap-1 [&:not(:last-child)_ul]:pb-1 [&:not(:last-child)_ol]:pb-1 list-disc flex flex-col gap-1 pl-8 mb-3">
<li class="whitespace-normal break-words pl-2"><strong>OS:</strong> Windows 11 (Build available on request)</li>
<li class="whitespace-normal break-words pl-2"><strong>Claude Desktop Version:</strong> v1.1.3189.0 (Microsoft Store / MSIX)</li>
<li class="whitespace-normal break-words pl-2"><strong>Architecture:</strong> x64</li>
<li class="whitespace-normal break-words pl-2"><strong>Hyper-V:</strong> Enabled, vmcompute and vmms services running</li>
<li class="whitespace-normal break-words pl-2"><strong>OneDrive:</strong> Installed, syncing only <code class="bg-text-200/5 border border-0.5 border-border-300 text-danger-000 whitespace-pre-wrap rounded-[0.4rem] px-1 py-px text-[0.9rem]">C:\Users\<user>\OneDrive</code>, but <code class="bg-text-200/5 border border-0.5 border-border-300 text-danger-000 whitespace-pre-wrap rounded-[0.4rem] px-1 py-px text-[0.9rem]">cldflt</code> filter driver loaded system-wide</li>
<li class="whitespace-normal break-words pl-2"><strong>EFS:</strong> Attempted system-wide disable via <code class="bg-text-200/5 border border-0.5 border-border-300 text-danger-000 whitespace-pre-wrap rounded-[0.4rem] px-1 py-px text-[0.9rem]">fsutil behavior set disableencryption 1</code> — did not prevent MSIX from applying encryption</li>
<li class="whitespace-normal break-words pl-2"><strong>VPN:</strong> None</li>
<li class="whitespace-normal break-words pl-2"><strong>Antivirus:</strong> Windows Defender only (no McAfee or third-party AV)</li>
</ul>
<h2 class="text-text-100 mt-3 -mb-1 text-[1.125rem] font-bold">Tools Used During Investigation</h2>
<div class="overflow-x-auto w-full px-2 mb-6">
Tool | Purpose
cipher | Check/remove EFS encryption attributes

PsExec64.exe (Sysinternals) | Run commands and cowork-svc.exe as SYSTEM

robocopy /B /COPY:D | Copy files bypassing ACLs and stripping encryption

New-VHD (Hyper-V PowerShell) | Create dynamic VHDX for VM session disk

fsutil behavior set disableencryption 1 | Attempt system-wide EFS disable

fltmc | Identify filesystem filter drivers

mklink /J | Create NTFS junction to redirect vm_bundles

compact /u /s /a /i | Remove NTFS compression attributes

</div>
<hr class="border-border-200 border-t-0.5 my-3 mx-1.5">

</body>
</html>

View original on GitHub ↗

7 Comments

github-actions[bot] · 6 months ago

Found 1 possible duplicate issue:

https://github.com/anthropics/claude-code/issues/25362

This issue will be automatically closed as a duplicate in 3 days.

If your issue is a duplicate, please close it and 👍 the existing issue instead
To prevent auto-closure, add a comment or 👎 this comment

🤖 Generated with Claude Code

ashaykubal · 6 months ago

This issue is not a duplicate because the root cause analysis here clearly points out that the installer attempts to copy the smol-bin image from scratch every time + even with EFS disabled and the required files manually added to vm_bundles, Claude's MSIX container actively applies encryption every time it attempts the copy. these 2 things combined means that the installation and setup never completes.

rangingicon · 6 months ago

I have been trying to find a work around for a week.

Update — Bug persists in v1.1.3363.0 (2026-02-17)

Confirming this issue remains unresolved after updating to the latest version.

Version: Claude_1.1.3363.0_x64
Date tested: 2026-02-17
Error: Identical — errno: -4094, UNKNOWN: unknown error, copyfile

Log excerpt from `cowork_vm_node.log`:

[VM:start] Copying smol-bin.x64.vhdx to bundle:
C:\Program Files\WindowsApps\Claude_1.1.3363.0_x64__pzs8sxrjxfjjc\app\resources\smol-bin.x64.vhdx
->
C:\Users\user\AppData\Roaming\Claude\vm_bundles\claudevm.bundle\smol-bin.vhdx

[VM:start] Startup failed: Error: UNKNOWN: unknown error, copyfile
errno: -4094
code: 'UNKNOWN'
syscall: 'copyfile'

New observation in this version:

The app install path appears to have shifted to the A:\ drive letter (A:\WindowsApps\Claude_1.1.3363.0_x64__pzs8sxrjxfjjc\...) in the stack trace, while the source path in the copy operation still references C:\Program Files\WindowsApps\. This may be worth investigating as a contributing factor.

Version history confirming persistence:

| Version | Result |
|---|---|
| 1.1.2685 | ❌ Failed — errno -4094 |
| 1.1.2998 | ❌ Failed — errno -4094 |
| 1.1.3149 | ❌ Failed — errno -4094 |
| 1.1.3363 | ❌ Failed — errno -4094 |

System context:

Windows 11 Pro
NTFS with EFS (Encrypting File System) enabled
AppData\Roaming folder has EFS encryption inheritance active
Hyper-V enabled
coworkScheduledTasksEnabled: false in preferences (Cowork errors are non-blocking for current workflow)

The app's self-repair logic has also stopped attempting reinstalls (Skipping auto-reinstall (already attempted once)), so it is no longer recovering on its own.

Happy to provide additional diagnostic info if helpful.

LucaPiovano · 6 months ago

EXDEV: cross-device link not permitted on Windows 11 25H2 (MSIX) - still unfixed in v1.1.4328.0

Environment

OS: Windows 11 Pro 25H2, Build 26200.7840 (KB5077181, Feb 10 2026)
Claude Desktop: v1.1.4328.0 (Microsoft Store / MSIX package)
CPU: 11th Gen Intel i7-11850H (16 cores)
RAM: 128 GB
Hyper-V: Enabled
Domain-joined: Yes

Problem

Cowork workspace fails to start. The app downloads rootfs.vhdx (~2.2GB compressed) successfully, but then fails when trying to move it from %TEMP% to the MSIX-virtualized %APPDATA% path using fs.rename():

[error] [download] VM download failed: EXDEV: cross-device link not permitted,
  rename 'C:\Users\<user>\AppData\Local\Temp\wvm-xnNKKW\rootfs.vhdx'
  -> 'C:\Users\<user>\AppData\Roaming\Claude\vm_bundles\claudevm.bundle\rootfs.vhdx'

Both paths are on the same C: drive (NTFS). The EXDEV error occurs because the MSIX sandbox virtualizes %APPDATA% to C:\Users\<user>\AppData\Local\Packages\Claude_pzs8sxrjxfjjc\LocalCache\Roaming\Claude\, and the MSIX filesystem driver treats %TEMP% and the virtualized path as different devices.

The app retries indefinitely, downloading ~2.2GB each time and failing on rename every ~60 seconds.

Additional issue: CoworkVMService won't start

The Windows service "Claude" (CoworkVMService) fails with "ERROR_INVALID_FUNCTION" on every start attempt:

Event Log: Servizio Claude terminato con l'errore specifico del servizio: Funzione non corretta.

Root cause

Node.js fs.rename() calls Windows MoveFileW, which does not support cross-device moves. The MSIX container's filesystem virtualization makes the source (%TEMP%) and destination (virtualized %APPDATA%) appear as different volumes, even though they're physically on the same drive.

Suggested fix

Replace fs.rename() with a cross-device-safe implementation:

async function safeMove(src, dest) {
  try {
    await fs.promises.rename(src, dest);
  } catch (err) {
    if (err.code === 'EXDEV') {
      await fs.promises.copyFile(src, dest);
      await fs.promises.unlink(src);
    } else {
      throw err;
    }
  }
}

Or use fs-extra.move() / move-file which handle EXDEV automatically.

Workarounds attempted (all failed)

| Workaround | Result |
|---|---|
| Clean reinstall with admin rights | Same EXDEV error |
| NTFS junction from bundle dir to %TEMP% | MSIX sandbox returns ENOENT (doesn't follow junctions) |
| Manual file copy + EFS decryption (cipher /d) | Hyper-V can read files, but MSIX app can't read .origin metadata → triggers re-download |
| Pre-staging files in bundle directory | App re-encrypts directory with EFS on every launch, .origin files unreadable |
| fsutil behavior set disableencryption 1 | MSIX still applies EFS |
| Update to v1.1.4328.0 | Same EXDEV error, no code change for fs.rename() |

Related issues

#25814 — MSIX container applies EFS encryption to vm_bundles on every launch (assigned to @MarshallOfSound)
#25476 — EXDEV when TEMP is on a different drive (closed as invalid, but same root cause)
#24962 — Missing sessiondata.vhdx, wrong DNS, no NAT on Win 11 Home

Logs

<details>
<summary>cowork_vm_node.log (last download cycle)</summary>

2026-02-26 12:36:25 [info] [Bundle:status] rootfs.vhdx missing
2026-02-26 12:36:25 [info] [warm] No warm file found for rootfs.vhdx at current version
2026-02-26 12:36:25 [info] [cache] No cached compressed file for rootfs.vhdx
2026-02-26 12:36:25 [info] rootfs.vhdx not found, downloading...
2026-02-26 12:36:25 [info] Downloading rootfs.vhdx...
2026-02-26 12:37:20 [info] rootfs.vhdx.zst checksum validated
2026-02-26 12:37:21 [error] [download] VM download failed: EXDEV: cross-device link not permitted,
  rename 'C:\Users\<user>\AppData\Local\Temp\wvm-xnNKKW\rootfs.vhdx'
  -> 'C:\Users\<user>\AppData\Roaming\Claude\vm_bundles\claudevm.bundle\rootfs.vhdx'

</details>

<details>
<summary>CoworkVMService event log</summary>

2026-02-26 12:33:41 - Servizio Claude terminato con l'errore: Funzione non corretta.
2026-02-26 12:31:09 - Servizio Claude terminato con l'errore: Funzione non corretta.

</details>

SgtMorgan · 5 months ago

Additional impact: disabling EFS to work around this bug breaks the entire Windows MSIX deployment stack
I hit this exact EFS bug with Cowork on a non-C: drive (G:\WindowsApps). Following troubleshooting advice, I ran fsutil behavior set disableencryption 1 to prevent the MSIX container from applying EFS to vm_bundles.
This fixed the Cowork smol-bin copy — but it completely broke all MSIX package staging system-wide. Every Add-AppxPackage call fails with:
HRESULT: 0x80073CF9
error 0x8007177E: Failure to get staging session
certutil -error 0x8007177E decodes to ERROR_VOLUME_NOT_SUPPORT_EFS — the MSIX staging engine requires EFS to be enabled to create staging sessions, even for packages that have nothing to do with encryption.
This means:

No Store app installs or updates
No MSIX packages of any kind can be deployed
An in-place Windows repair install does NOT fix it (the registry flag persists)
The only fix is fsutil behavior set disableencryption 0 + reboot

I spent several hours and multiple in-place repair installs before identifying this via certutil -error. The error message gives no indication that EFS is involved.
The workaround of installing Claude to C: instead of a secondary drive avoids the EFS bug entirely, but users who prefer apps on non-OS drives are stuck.
Environment: Windows 11 Pro 25H2 (26200.8037), Claude Desktop 1.1.6041.0 (MSIX), G: drive is NTFS with default settings.
Suggestion: The app's file copy for smol-bin.vhdx should strip EFS attributes (data-only copy as others have suggested), and the troubleshooting docs should explicitly warn against disabling EFS as a workaround since it has catastrophic side effects on the MSIX stack.

Pablo-6th · 5 months ago

Hi @MarshallOfSound — I can confirm this bug is still present as of the latest release.

Environment

OS: Windows 11 Pro, Version 25H2, Build 26200
Claude Desktop: v1.1.4498+ (latest)
Subscription: Max plan
Hyper-V, Virtual Machine Platform, Windows Hypervisor Platform, WSL: all enabled

Status
Cowork has never successfully started on this system. The EFS copyfile failure occurs on every launch — the vm_bundles\claudevm.bundle directory is re-created with encryption applied by the MSIX container each time, undoing any manual workaround.

Related issues confirming this persists

#25362 — smol-bin.vhdx copy fails with EFS error (Feb 12)
#25911 — EXDEV rename failure, same root cause (Feb 13)
#30584 — EXDEV on rename confirmed in v1.1.4498 (Mar 3)
#31703 — smol-bin copy failure still occurring in v1.1.4498 (Mar 3)

The fix proposed across these issues — replacing the internal copyfile with a data-only copy equivalent to robocopy /COPY:D, and using copyFile + unlink as a fallback when fs.rename() fails with EXDEV — has been confirmed by multiple users as theoretically sound but has not yet been implemented in any shipped version.

I've submitted debug logs via the Cowork error dialog and raised this with support (ref: issues #25362, #25814, #25911, #27897, #29848, #30584, #31703). As a Max plan subscriber who invested in upgrading to Windows 11 Pro specifically to meet Cowork's Hyper-V requirements, this has been an ongoing blocker since launch.

Please could you confirm whether a fix for the EFS/EXDEV copy failure is on the roadmap, and if there is any ETA or workaround that survives app restarts? Thank you.

eedvaarts · 5 months ago

Additional report: EXDEV on non-EFS system — pure MSIX sandbox boundary issue

Environment

OS: Windows 11 Pro 25H2 (Build 26200.7840)
Claude Desktop version: 1.1.4498 (MSIX install)
CPU: x64
Hyper-V: Enabled (vmms Running/Automatic)
vmcompute: Running / winnat: Running / HNS: Running
EFS: NOT present — cipher confirms "U" (unencrypted) on vm_bundles folder
Subscription: Max plan

Why this matters

This report demonstrates that the EXDEV bug is NOT limited to EFS-encrypted systems. On this machine, both paths are on C:\ with no EFS, no reparse points, no symlinks, no junction points, and no filesystem filter drivers (fltMC confirmed clean after uninstalling HitmanPro Alert). The MSIX sandbox virtualization alone is sufficient to cause the EXDEV error.

Error

EXDEV: cross-device link not permitted, rename 
'C:\Users\User\AppData\Local\Temp\wvm-XXXXXX\rootfs.vhdx' -> 
'C:\Users\User\AppData\Roaming\Claude\vm_bundles\claudevm.bundle\rootfs.vhdx'

The 9GB download completes and checksum validates successfully every time. The rename always fails.

Confirmed NOT the cause

EFS: cipher shows "U" (unencrypted) on vm_bundles and all parent folders
Different drives: both TEMP and APPDATA confirmed on C:\ (same volume GUID)
Reparse points: fsutil confirms none on AppData, AppData\Local, AppData\Local\Temp, or AppData\Roaming
Volume mount points: none inside C:\Users (verified via mountvol and Win32_Volume)
AppLocker: Test-AppLockerPolicy shows AllowedByDefault for cowork-svc.exe
Windows Defender: No threat detections for Claude or cowork
HitmanPro Alert: Uninstalled and rebooted — no change
Google Drive filter driver: Not present in fltMC output
TEMP env var redirect: Setting TEMP permanently to AppData\Roaming\ClaudeTemp at user level has no effect — MSIX container ignores user env vars

Exhaustive troubleshooting performed

Multiple full uninstalls and clean reinstalls of Claude Desktop
Deleting all AppData (Packages\Claude_*, AppData\Roaming\Claude, AppData\Local\Claude, .claude)
Enabling Windows features: Containers, HypervisorPlatform, VirtualMachinePlatform, Hyper-V (all confirmed Enabled)
Manually copying rootfs.vhdx + rootfs.vhdx.zst to bundle destination after download — Claude reports "origin missing" and re-downloads
Computing SHA1 of rootfs.vhdx.zst and writing .rootfs.vhdx.origin manually — Claude still fails to boot

Conclusion

The EXDEV is caused purely by MSIX filesystem virtualization treating AppData\Local\Temp and AppData\Roaming as separate filesystem devices, regardless of EFS status. Implementing copyFile() + unlink() as a fallback when fs.rename() fails with EXDEV would resolve this case.

[BUG] Cowork Windows: MSIX container applies EFS encryption to vm_bundles folder on every launch, copyfile for smol-bin.vhdx permanently fails

Preflight Checklist

What's Wrong?

What Should Happen?

Error Messages/Logs

Steps to Reproduce

Claude Model

Is this a regression?

Last Working Version

Claude Code Version

Platform

Operating System

Terminal/Shell

Additional Information

7 Comments

Update — Bug persists in v1.1.3363.0 (2026-02-17)

Log excerpt from cowork_vm_node.log:

New observation in this version:

Version history confirming persistence:

System context:

EXDEV: cross-device link not permitted on Windows 11 25H2 (MSIX) - still unfixed in v1.1.4328.0

Environment

Problem

Additional issue: CoworkVMService won't start

Root cause

Suggested fix

Workarounds attempted (all failed)

Related issues

Logs

Additional report: EXDEV on non-EFS system — pure MSIX sandbox boundary issue

Environment

Why this matters

Error

Confirmed NOT the cause

Exhaustive troubleshooting performed

Conclusion

Related Claude Code issues

Browse by topic

Log excerpt from `cowork_vm_node.log`: