[BUG] Edit/Write fail with "ENOENT: fchmod" on VM shared-folder drives when the target file already exists

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?

Title: Edit/Write fail with "ENOENT: fchmod" on VM shared-folder drives when the target file already exists

Summary

On drives that are VM shared folders (e.g. VMware HGFS / VirtualBox vboxsf, mounted as Y: and T: on the Windows guest), the Edit and Write tools fail whenever the target file already exists. Creating a new file with Write works. The atomic-write path apparently calls fchmod() to carry over the file's mode bits after writing, and the shared-folder driver rejects that syscall, so the whole operation aborts.

Error

ENOENT: fchmod

Environment

• Host: Windows 11 Enterprise LTSC 2024 (10.0.26100)
• Guest editing target: VM shared-folder drives mounted as Y:\ and T:\
• Local NTFS drive C:\ is NOT affected — all operations succeed there.
• Occurs regardless of session, and regardless of how the file was originally created.

Expected

Edit/Write on an existing file on a shared-folder drive should succeed (as it does on local NTFS), or degrade gracefully when fchmod() is unsupported.

Actual

The operation aborts with ENOENT: fchmod. The dividing line is strictly "does the target file already exist?" — not the session and not how the file was created.

Reproducibility matrix (tested)

| Operation | C: (local NTFS) | Y: / T: (shared folder) |
|---------------------------------------------|-----------------|-------------------------|
| Write - new file | OK | OK |
| Write - overwrite existing file | OK | FAIL (fchmod) |
| Edit - existing file | OK | FAIL (fchmod) |
| Edit - on a file freshly created via Write | OK | FAIL (fchmod) |

Root cause (hypothesis)

The atomic write sequence (write temp file -> copy/preserve permissions -> rename over original) issues fchmod() to preserve the existing file's mode bits. Shared-folder filesystem drivers do not implement fchmod(), so it returns ENOENT and the tool aborts. New files skip this step because there are no pre-existing permissions to preserve, which is why creating a new file works.

Impact

Any workflow that runs Claude Code against sources on a VM shared folder cannot edit existing files at all. This is common when the IDE/build (e.g. Visual Studio) runs on the host and the code is edited from a guest VM. It blocks the core editing loop.

Data safety (observed)

A failed Edit/Write leaves the target file unchanged (no truncation/data loss) and leaves no leftover .tmp file. So it is a hard failure, not a corruption — but it fully blocks editing.

Suggested fix

When fchmod() fails with ENOENT/ENOSYS/EPERM (typical on non-POSIX shared-folder filesystems), treat the permission-preservation step as best-effort: log and continue instead of aborting the whole write. The content write and rename have already succeeded; failing to re-apply mode bits should not fail the operation on filesystems that don't support it.

What Should Happen?

Edit/Write on an existing file on a shared-folder drive should succeed (as it does on local NTFS), or degrade gracefully when fchmod() is unsupported.

Error Messages/Logs

Write(_fchmod_test.txt)
  ⎿  Error: ENOENT: no such file or directory, fchmod


Update(_fchmod_test.txt)
  ⎿  Error: ENOENT: no such file or directory, fchmod

Steps to Reproduce

1. On a VM shared-folder drive (Y:\ or T:\), create a file: Write to Y:\test.txt -> succeeds.
2. Now modify that same existing file with Edit, or overwrite it with Write.
3. The operation fails with ENOENT: fchmod.

Claude Model

Opus

Is this a regression?

Yes, this worked in a previous version

Last Working Version

2.1.179

Claude Code Version

2.1.198

Platform

AWS Bedrock

Operating System

Windows

Terminal/Shell

Windows Terminal

Additional Information

_No response_