[BUG] Write Tool Fails with EEXIST on Windows OneDrive Directories (Regression in 2.1.69)
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
- Ensure your working directory is inside an OneDrive-synced folder (e.g. C:\Users\<user>\OneDrive - <Company>\Desktop\<Project>)
- Open Claude Code in that directory
- Ask Claude to write any new file:
- "Create a file called hi_world.txt with the contents Hi World!"
- Claude invokes the Write tool with an absolute path inside the OneDrive directory
- 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.
This issue has 3 comments on GitHub. Read the full discussion on GitHub ↗