[BUG] [Cowork] Windows: smol-bin.vhdx copy fails with "The specified file could not be encrypted" on NTFS with EFS support

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 fails to start every time with the following error:

Failed to start Claude's workspace
UNKNOWN: unknown error, copyfile 'C:\Program Files\WindowsApps\Claude_1.1.2685.0_x64__pzs8sxrjxfjjc\app\resources\smol-bin.vhdx' -> 'C:\Users\e\AppData\Roaming\Claude\vm_bundles\claudevm.bundle\smol-bin.vhdx'
Restarting Claude or your computer sometimes resolves this. If it persists, you can reinstall the workspace or share your debug logs to help us improve.

The root cause is that the app's internal file copy operation triggers an EFS (Encrypting File System) error on the .vhdx file. This occurs even though:

• EFS encryption is not enabled on the destination folder
• No EFS group policy exists (HKLM\SOFTWARE\Policies\Microsoft\Windows NT\EFS does not exist)
• Paging file encryption is disabled (EncryptPagingFile = 0)
• The "Encrypt contents to secure data" checkbox is unchecked on the destination folder

The NTFS volume simply reports "Supports Encrypted File System" as a filesystem capability, which appears to be enough to trigger the issue during the app's copy operation.

What Should Happen?

Cowork workspace should start successfully. The smol-bin.vhdx file should copy from the app resources to the VM bundle directory without triggering EFS-related errors.

Error Messages/Logs

Error invoking remote method '$eipc_message$_ab0dd6f4-eb6c-4f1b-9344-4ca2b306795c_$_claude.web_$_CustomPlugins_$_listMarketplaces': Error: UNKNOWN: unknown error, copyfile 'C:\Program Files\WindowsApps\Claude_1.1.2685.0_x64__pzs8sxrjxfjjc\app\resources\smol-bin.vhdx' -> 'C:\Users\e\AppData\Roaming\Claude\vm_bundles\claudevm.bundle\smol-bin.vhdx'

Steps to Reproduce

Reproduction Steps

1. Install Claude Desktop v1.1.2685.0 on Windows 11 Pro x64
2. Ensure Hyper-V is enabled and SVM Mode is active in BIOS
3. Open Claude Desktop and switch to Cowork tab
4. Attempt to start any task
5. Error occurs during workspace initialization when copying smol-bin.vhdx

Verification & Troubleshooting Performed

Manual copy with PowerShell fails with the same error:

Copy-Item "C:\Program Files\WindowsApps\Claude_1.1.2685.0_x64__pzs8sxrjxfjjc\app\resources\smol-bin.vhdx" "C:\Temp\smol-bin.vhdx" -Force
# Error: "The specified file could not be encrypted"

Manual copy to ANY destination fails:

Copy-Item "C:\Program Files\WindowsApps\...\smol-bin.vhdx" "C:\Temp\smol-bin.vhdx" -Force
# Same error — not destination-specific

Robocopy with data-only flag SUCCEEDS:

robocopy "C:\Program Files\WindowsApps\Claude_1.1.2685.0_x64__pzs8sxrjxfjjc\app\resources" "C:\Temp" smol-bin.vhdx /COPY:D /DCOPY:T
# 100% success — file copies correctly

Other checks performed:

• Source file exists: Test-Path returns True
• Destination folder exists: Test-Path returns True
• cipher /d on destination folder — no effect
• Running as Administrator — no effect
• Deleting vm_bundles folder and relaunching — error recurs
• fsutil behavior query encryptpagingfile → Disabled
• fsutil fsinfo volumeinfo C: → "Supports Encrypted File System" (standard NTFS capability)

Claude Model

Opus

Is this a regression?

I don't know

Last Working Version

_No response_

Claude Code Version

Claude 1.1.2685 (f39a62) 2026-02-10T19:42:56.000Z

Platform

Claude Desktop

Operating System

Windows

Terminal/Shell

PowerShell

Additional Information

• This error persists across reboots and full reinstalls
• The file is successfully placed by robocopy, but the app re-attempts its own copy on each launch and fails again
• Chat and Code tabs function normally — only Cowork is affected

The app's internal file copy mechanism should strip file attributes/encryption flags during the copy operation. Using a method equivalent to robocopy /COPY:D (data-only copy) instead of a standard file copy would resolve this issue. The robocopy approach has been confirmed to work on this system.