[BUG] Cowork VM does not respect Windows Known Folder redirections — tasks fail when user folders are on a separate drive
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?
Environment
- OS: Windows 11 Home
- Claude Desktop: v1.1348.0.0 (Microsoft Store install)
- Subscription: Pro
- User profile path:
C:\Users\Will Clary - Known Folders (Documents, Downloads, etc.): Redirected to
D:\WMClary\
Cowork tasks fail with "Session VM process not available. The session may not be fully initialized" when attempting to access user folders (Downloads, Documents, etc.) that have been redirected from the default C:\Users\<user> location to a separate drive (D:\WMClary\).
The VM starts successfully — network connects, API is reachable, startup completes in ~9 seconds. Task processes spawn and are confirmed, but are then SIGTERM'd after ~17 seconds with no useful work done.
The root cause appears to be that the VM's Plan9/VirtioFS share mounts only map C:\Users\Will Clary\... paths and do not follow Windows Known Folder redirections. The mounted C: drive user folders are empty because all actual user data lives on D:.
What Should Happen?
Should:
The VM should resolve Windows Known Folder redirections (via the shell folder registry keys or SHGetKnownFolderPath) and mount the actual target paths, not just the default C:\Users\<user> locations.
Actual Behavior:
The VM mounts only C:\Users\<user> paths. Tasks that access Downloads, Documents, etc. find empty directories because the real data is on D:. The task process gets SIGTERM'd.
Error Messages/Logs
PS> [Environment]::GetFolderPath('UserProfile')
C:\Users\Will Clary
PS> [Environment]::GetFolderPath('MyDocuments')
D:\WMClary\Documents
The Windows shell folder registry keys at `HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\User Shell Folders` point Documents, Downloads, etc. to `D:\WMClary\...`, but the VM only mounts paths under `C:\Users\Will Clary`.
### VM starts successfully (`cowork_vm_node.log`)
2026-04-09 12:06:23 [info] [VM:start] Beginning startup, bundlePath=C:\Users\Will Clary\AppData\Roaming\Claude\vm_bundles\claudevm.bundle
2026-04-09 12:06:24 [info] [VM:steps] vm_boot completed (327ms)
2026-04-09 12:06:30 [info] [VM] Network status: CONNECTED
2026-04-09 12:06:32 [info] [VM] API reachability: REACHABLE
2026-04-09 12:06:32 [info] [VM:start] Startup complete, total time: 9028ms
### Task spawns but fails (`cowork_vm_node.log`)
2026-04-09 12:11:39 [info] [Spawn:create] id=7a506c6a-f4d0-4c24-a15c-d216fe8319f6 name=gracious-zen-bell cmd=/usr/local/bin/claude args=... --resume cbf6ca1b-2547-48ba-8ed6-b3ce4eb7c5fa ...
2026-04-09 12:11:39 [info] [Spawn:vm] id=7a506c6a-f4d0-4c24-a15c-d216fe8319f6 Spawn succeeded in 72ms
2026-04-09 12:11:56 [info] [CoworkVMProcess:7a506c6a-f4d0-4c24-a15c-d216fe8319f6] kill called with signal: SIGTERM
2026-04-09 12:11:56 [info] [Process:7a506c6a-f4d0-4c24-a15c-d216fe8319f6] Exited, code=0, signal=null, duration=17247ms, oom=false
Mount configuration shows only C: paths with 11 mounts: `outputs, .claude, .claude/skills, .local-plugins, [plugin caches], .cowork-lib, .cowork-perm-req, .cowork-perm-resp, uploads`
### Filesystem extension error (`main.log`)
2026-04-09 12:06:26 [error] Failed to cache extension update ant.dir.ant.anthropic.filesystem@0.2.1: ENOENT: no such file or directory, open 'C:\Users\Will Clary\AppData\Roaming\Claude\Extensions Update Cache\ant.dir.ant.anthropic.filesystem\dist\path-utils.js'
Steps to Reproduce
- Set up a Windows machine with user profile on C: and Known Folders (Documents, Downloads, etc.) redirected to a separate drive (D:)
- Install Claude Desktop
- Open Cowork and run any task that accesses user folders
- Task fails with "Session VM process not available"
Claude Model
Opus
Is this a regression?
I don't know
Last Working Version
_No response_
Claude Code Version
v1.1348.0.0
Platform
Anthropic API
Operating System
Windows
Terminal/Shell
PowerShell
Additional Information
This is a common setup for users with SSD (C:) + HDD/secondary SSD (D:) configurations. The VM mount logic should either:
- Read the Known Folder redirections and mount the actual target paths
- Mount additional drives that contain redirected folders
- Follow NTFS junction points / symlinks if present
Related Issues
This is distinct from the Hyper-V / VM service startup issues reported in #25206, #27801, #29428, etc. — the VM itself starts and runs fine. The issue is specifically with drive/path mapping.
This issue has 2 comments on GitHub. Read the full discussion on GitHub ↗