[BUG] Write Tool Fails with EEXIST on Windows OneDrive Directories (Regression in 2.1.69)

Resolved 💬 3 comments Opened Mar 5, 2026 by gabekole Closed Mar 9, 2026

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?

The Write tool fails with EEXIST: file already exists, mkdir when attempting to create any file inside an OneDrive-synced directory on Windows. The error occurs immediately — the file is never created. This affects the entire working directory since it is located inside OneDrive.

What Should Happen?

Claude should successfully create new files in the working directory, as it did prior to v2.1.69. The directory already exists and is valid — mkdir should silently succeed when the target directory is present.

Error Messages/Logs

Three separate Write attempts, each targeting a different path depth — all fail with the same pattern. The error always references the parent directory of the file being written, not the file itself:

Attempt 1 — writing to <OneDrive>\Desktop\<Project>\subdir\hi_world.txt:


EEXIST: file already exists, mkdir 'C:\Users\<user>\OneDrive - <Company>\Desktop\<Project>\subdir'
Attempt 2 — writing to <OneDrive>\Desktop\<Project>\hi_world.txt:


EEXIST: file already exists, mkdir 'C:\Users\<user>\OneDrive - <Company>\Desktop\<Project>'
Attempt 3 — writing to <OneDrive>\Desktop\hi_world.txt:


EEXIST: file already exists, mkdir 'C:\Users\<user>\OneDrive - <Company>\Desktop'
Attempt 4 — writing to C:\Users\<user>\Desktop\hi_world.txt (non-OneDrive path, same machine):


File created successfully at: C:\Users\<user>\Desktop\hi_world.txt
This confirms the failure is path-specific to OneDrive, not a general permissions issue.

Windows file attributes on affected vs. unaffected directories (via PowerShell Get-Item ... -Force | Select-Object Attributes):


Path                                              Attributes
----                                              ----------
C:\Users\<user>\OneDrive - <Company>\Desktop      ReadOnly, Directory, Archive, ReparsePoint
C:\Users\<user>\OneDrive - <Company>\Desktop\<Project>
                                                  ReadOnly, Directory, Archive, ReparsePoint
C:\Users\<user>\OneDrive - <Company>\Desktop\<Project>\subdir
                                                  ReadOnly, Directory, Archive, ReparsePoint
C:\Users\<user>\Desktop                           Directory, Archive
Every directory under OneDrive carries ReparsePoint. The non-OneDrive Desktop does not — and Write succeeds there.

Node.js mkdirSync({recursive: true}) on the same OneDrive path succeeds, confirming the failure is specific to how claude.exe (Bun v1.3.11) handles it post-2.1.69:


fs.mkdirSync('C:/Users/<user>/OneDrive - <Company>/Desktop/<Project>', {recursive: true});
// Node.js: SUCCESS — no error thrown

fs.realpathSync('C:/Users/<user>/OneDrive - <Company>/Desktop/<Project>');
// 'C:\Users\<user>\OneDrive - <Company>\Desktop\<Project>'
// Path does NOT redirect elsewhere — reparse point stays in-place

Steps to Reproduce

  1. Ensure your working directory is inside an OneDrive-synced folder (e.g. C:\Users\<user>\OneDrive - <Company>\Desktop\<Project>)
  2. Open Claude Code in that directory
  3. Ask Claude to write any new file:
  4. "Create a file called hi_world.txt with the contents Hi World!"
  5. Claude invokes the Write tool with an absolute path inside the OneDrive directory
  6. The tool immediately returns: EEXIST: file already exists, mkdir 'C:\Users\<user>\OneDrive - <Company>\Desktop\<Project>'

Claude Model

Not sure / Multiple models

Is this a regression?

Yes, this worked in a previous version

Last Working Version

2.1.68

Claude Code Version

2.1.69

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

VS Code integrated terminal

Additional Information

Additional Information

The regression was introduced by the v2.1.69 change:

"Fixed symlink bypass where writing new files through a symlinked parent directory could escape the working directory in acceptEdits mode"

Root cause: On Windows, OneDrive sets the ReparsePoint file attribute on every directory it manages. The new symlink bypass fix appears to treat any ReparsePoint directory as a potential symlink escape, causing mkdirSync to throw EEXIST even when the directory legitimately exists and is the intended write target.

This is not a true symlink — fs.realpathSync() returns the same path, confirming the reparse point does not redirect to another location and poses no escape risk.

Suggested fix: On Windows, before blocking a write through a ReparsePoint directory, verify that fs.realpathSync(path) resolves to a location outside the working directory. If it resolves within (as OneDrive reparse points always do), the write should be permitted.

This impacts all Windows users on enterprise/Microsoft 365 environments where OneDrive folder redirection is the default configuration, making the Write tool entirely non-functional in the most common enterprise working directory setup.

View original on GitHub ↗

This issue has 3 comments on GitHub. Read the full discussion on GitHub ↗