[BUG] Cowork (desktop app): mkdir/os.makedirs does not persist to Windows filesystem — virtiofs FUSE_MKDIR not forwarded to Windows host

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?

In the Claude Cowork desktop app (Windows), creating new directories via os.makedirs(), os.mkdir(), or the bash mkdir command appears to succeed inside the VM but the directory is never actually created on the Windows filesystem.

The Cowork app mounts the user's Windows folders into the Linux VM via a virtiofs FUSE driver:

• Windows path: C:\Users\<user>\Downloads
• - VM mount path: /sessions/<session>/mnt/Downloads
• - - Mount type: fuse (rw, default_permissions, allow_other)

When a new subdirectory is created inside the mount:

1. os.makedirs("/sessions/.../mnt/Downloads/NewFolder") returns without error
2. 2. os.stat() on the new path returns a valid inode (the FUSE layer caches it)
3. 3. Any subsequent file write to that path returns [Errno 2] No such file or directory
4. 4. On the Windows side, the directory was never created — it does not exist

When Claude (running in the Cowork VM) calls os.makedirs() or mkdir on a path inside the virtiofs-mounted Windows folder, the directory should be created on the actual Windows filesystem — not just in the FUSE client cache. Subsequent file writes to the new directory should succeed.
Note: Writing files to pre-existing Windows directories works correctly. The bug is isolated to new directory creation.

What Should Happen?

When Claude (running in the Cowork VM) calls os.makedirs() or mkdir on a path inside the virtiofs-mounted Windows folder, the directory should be created on the actual Windows filesystem — not just in the FUSE client cache. Subsequent file writes to the new directory should succeed.

Error Messages/Logs

# mkdir appears to succeed (no error):
$ mkdir /sessions/.../mnt/Downloads/L968_FAA_Prescreen

# os.stat() returns a valid inode — FUSE client cache has it:
$ python3 -c "import os; print(os.stat('/sessions/.../mnt/Downloads/L968_FAA_Prescreen'))"
os.stat_result(st_mode=16877, st_ino=..., st_dev=..., ...)

# But writing a file to the new directory fails:
$ python3 -c "open('/sessions/.../mnt/Downloads/L968_FAA_Prescreen/test.pdf','wb').write(b'test')"
FileNotFoundError: [Errno 2] No such file or directory: '.../L968_FAA_Prescreen/test.pdf'

# Windows Explorer confirms: the folder was never created on the Windows filesystem

Steps to Reproduce

1. Open Claude Cowork desktop app on Windows and start a new session.
2. Grant Claude access to a Windows folder (e.g. Downloads) via the folder picker.
3. Ask Claude to create a new subfolder inside that directory (e.g. "create a folder called TestFolder in Downloads and move these files into it").
4. Claude runs os.makedirs("/sessions/.../mnt/Downloads/TestFolder") — returns no error.
5. Claude attempts to write a file: open("/sessions/.../mnt/Downloads/TestFolder/file.pdf", "wb")
6. Observe: FileNotFoundError: [Errno 2] No such file or directory
7. Check Windows Explorer — TestFolder does not exist in Downloads.

Additional confirmation: os.stat() on the path after mkdir returns a valid inode, proving the directory is cached in the FUSE client layer but was never persisted to the Windows host filesystem.

Note: Writing files to pre-existing Windows directories (folders that already existed before the session) works correctly. The bug is isolated to newly created directories.

Claude Model

None

Is this a regression?

No, this never worked

Last Working Version

_No response_

Claude Code Version

Claude Cowork desktop app (Windows) — version unknown (no claude --version in Cowork)

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

Windows Terminal

Additional Information

This bug affects all Cowork users on Windows. The Cowork desktop app mounts user Windows folders into a Linux VM via virtiofs FUSE. The FUSE layer accepts FUSE_MKDIR and returns success to the client, but never calls CreateDirectory on the Windows host — so the directory only exists in the FUSE client cache, not on disk.

This blocks any AI workflow that requires creating new output folders (e.g. organizing files into a new subfolder, saving generated reports to a new directory, etc.). Writing to pre-existing Windows folders works fine — only new directory creation is broken.

The expected behavior is that mkdir inside the virtiofs mount should be forwarded to the Windows host filesystem. This is a standard virtiofs operation and should work transparently.

Impact: This is a blocker for enterprise/team use cases where users expect Claude to be able to organize files into new folders autonomously, without needing to pre-create every destination directory manually.