[BUG] Cowork VHDX placement fails with ELOOP on Intel RST VMD Controller 467F — distinct from EXDEV, bash permanently broken since v1.8089.1

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?

Bash workspace has been permanently broken since Cowork v1.8089.1 shipped a new VHDX requiring fresh placement. This is distinct from the EXDEV rename issues (#25476, #25911, #27897, #38316, #38457) and from the cloud provisioning outage resolved May 13. My bash did NOT recover after the May 13 server-side fix — confirmed still broken as of 2026-05-23.

The error is ELOOP (not EXDEV). Same root operation — fs.rename() — different driver, different rejection mechanism, different hardware class.

Root cause confirmed: Intel RST VMD Controller 467F rejects POSIX atomic rename() for cross-directory operations on NTFS. Node.js/Electron surfaces this as ELOOP. CoworkVMService log analysis confirms the VM is never attempted — the app never calls "configure" after ELOOP fires. The temp dir and VHDX are deleted before the error card appears in the Cowork UI, making manual interception impossible.

Key proof this is hardware-specific: bash worked on this machine before v1.8089.1 (VMD is compatible with HCS/WSL2 when VHDX is already placed), and bash did NOT recover after the May 13 server-side fix that resolved the issue for most users.

Anthropic support ticket: ID 215474175581735

What Should Happen?

VHDX placement should succeed. The fix: replace fs.rename() with fs.copyFile() + fs.unlink() as a fallback when any rename-rejection error is encountered (EXDEV, ELOOP, EPERM, or equivalent). This has been requested across multiple threads since 2025 for EXDEV — this report adds ELOOP/Intel RST VMD to the same failure class. A copy operation is not rejected by Intel RST VMD. The copy-then-delete pattern resolves all known rename-rejection variants on Windows regardless of the underlying driver.

Error Messages/Logs

ELOOP: too many symbolic links encountered, rename
'C:\Users\gregb\AppData\Roaming\Claude\vm_bundles\claudevm.bundle\.wvm-tmp-xxx\rootfs.vhdx'
->
'C:\Users\gregb\AppData\Roaming\Claude\vm_bundles\claudevm.bundle\rootfs.vhdx'

CoworkVMService log (C:\ProgramData\Claude\Logs\cowork-service.log) shows:
- Service starts correctly
- App connects via named pipe \\.\pipe\cowork-vm-service
- configure is NEVER called
- VM is NEVER booted
- "VM already stopped, nothing to release" on every shutdown

Steps to Reproduce

1. Install Cowork on a system with Intel RST VMD Controller 467F (common on HP OMEN and similar gaming laptops)
2. Allow Cowork to download and attempt to place rootfs.vhdx
3. Observe ELOOP in %AppData%\Roaming\Claude\logs\cowork_vm_node.log
4. Confirm CoworkVMService never receives configure call via C:\ProgramData\Claude\Logs\cowork-service.log
5. Bash permanently unavailable — every subsequent "reinstall workspace" repeats the same failure

All workarounds attempted and failed:

• Watcher script to copy VHDX before rename: zero-window, temp dir deleted before error appears in UI
• Manually place rootfs.vhdx: app detects inconsistency, deletes file, restarts download
• Python decompression + manual placement: rejected (size mismatch 8.8 GB vs expected 5.27 GB)
• BIOS update F.41 > F.55: no effect
• Intel RST driver update v19.5.0.1037 > v19.5.8.1059: no effect
• D: drive junction: caused 15-minute kernel hang — do NOT suggest for VMD hardware

Claude Model

Sonnet (default)

Is this a regression?

Yes, this worked in a previous version

Last Working Version

Cowork v1.8089.0 (last version before VHDX re-placement was required)

Claude Code Version

Cowork v1.8089.1 (Microsoft Store MSIX — not Claude Code CLI)

Platform

Other

Operating System

Windows

Terminal/Shell

Other

Additional Information

_No response_