EEXIST: file already exists, mkdir - startup hang when home directory has ReadOnly attribute on Windows
Bug Description
Claude Code v2.1.69 fails to start (hangs indefinitely) and claude auth login fails with:
Login failed: EEXIST: file already exists, mkdir 'C:\Users\<username>'The root cause is that the user's home directory has the ReadOnly attribute set (common in corporate/enterprise Windows environments managed by Group Policy). Claude Code's mkdir with recursive: true throws EEXIST instead of succeeding when the target directory already exists but has the ReadOnly flag.
This is a regression — v2.1.68 works correctly on the same system.
Steps to Reproduce
- On Windows, have a home directory with ReadOnly attribute:
``
attrib C:\Users\<username>
# Shows: R D A C:\Users\<username>
- Run
claudeorclaude auth loginfrom any terminal (PowerShell 5.1, PowerShell 7, Git Bash) - Interactive
claudehangs indefinitely with blank screen claude auth loginprints the OAuth URL then fails withEEXIST: file already exists, mkdir 'C:\Users\<username>'claude auth logoutalso fails withFailed to log out.
What Works
claude --versionworks (exits before hitting the mkdir path)- Downgrading to v2.1.68 resolves the issue completely
- Renaming
~/.claudedoes not help — the error is on the home directory itself, not.claude - Clearing
~/.claude/debug/does not help
Environment
- OS: Windows 11
- Claude Code version: 2.1.69 (broken), 2.1.68 (works)
- Install method: native (
claude.exe) - Shell: Tested in Git Bash (MINGW64), PowerShell 5.1, and PowerShell 7
- Home directory attributes:
ReadOnly, Directory, Archive(set by corporate Group Policy)
Expected Behavior
mkdir with recursive: true should handle existing directories with the ReadOnly attribute gracefully, the same as it handles normal existing directories. This worked in v2.1.68.
Workaround
Downgrade to v2.1.68:
npm install -g @anthropic-ai/claude-code@2.1.68Removing the ReadOnly attribute (attrib -R) from the home directory would also fix it, but is not acceptable in managed corporate environments where this attribute is set by Group Policy.
7 Comments
Found 3 possible duplicate issues:
This issue will be automatically closed as a duplicate in 3 days.
🤖 Generated with Claude Code
Same issue v. 2.1.69
Bug Description
Claude Code v2.1.69 fails to start correctly and hangs on the “_Do you trust the files in this folder?_” prompt when run as a standalone CLI on Windows.
Even after selecting “Yes” and pressing Enter, the prompt never closes and Claude does not proceed. Selecting “No” closes the prompt and exits after a second.
In the logs, Claude repeatedly outputs:
Failed to save config with lock: Error: EEXIST: file already exists, mkdir 'C:\Users\User'The directory C:\Users\User already exists and has full write permissions for the current user, so this error appears to be caused by incorrect handling of EEXIST when calling mkdir on an existing directory during config/lock initialization.
This makes the CLI effectively unusable in this environment, because the trust dialog cannot persist the answer and Claude never gets past startup.
Same issue here, downgrading fixed it, thanks
also, I wish that claude code actually showed the debug log or pointed to, it instead of just freezing. Took me long enough to realize that it even exists and where it is.
New native installations via PowerShell or CMD also hang forever after printing "Setting up Claude Code". Using the above mentioned npm install method worked.
Confirming identical behaviour on corporate Windows 11 with ReadOnly home directory.
$ cmd //c "attrib C:\Users\agroenew"
R C:\Users\agroenew
[ERROR] Failed to save config with lock: Error: EEXIST: file already exists, mkdir 'C:\Users\agroenew'
v2.1.69 hangs indefinitely. v2.1.68 via npm works perfectly. Domain-joined machine, Group Policy managed.
Was having all kinds of issues, Claude found this and we removed read only from project files and now things are working again.
This issue has been automatically locked since it was closed and has not had any activity for 7 days. If you're experiencing a similar issue, please file a new issue and reference this one if it's relevant.