[BUG] Claude Code not starting with corrupted path
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?
When trying to access claude code in powershell (or cmd) it gives below error message:
Error message: Claude Code could not start: EUNKNOWN: unknown error, stat '\\c\Users\Admin\jnkresearch.com\JNK - IR Folder - Documents'
Claude Code version: 2.1.168
Microsoft Windows NT 10.0.26200.0
Powershell version
Major Minor Build Revision
----- ----- ----- --------
5 1 26100 8521
What Should Happen?
Claude code should be accessible in desktop app and execute my routines and react to prompts.
Error Messages/Logs
Steps to Reproduce
error in cmd or ps returns
PS C:\Users\Admin> claude
Claude Code could not start: EUNKNOWN: unknown error, stat '\\c\Users\Admin\OneDrive - jnkresearch.com\SharedData'
followed all steps in online help and referred me to here. i am not a programmer/coder. pls keep it simple for me. THX!
Claude Model
Opus
Is this a regression?
Yes, this worked in a previous version
Last Working Version
_No response_
Claude Code Version
2.1.168
Platform
Anthropic API
Operating System
Windows
Terminal/Shell
PowerShell
Additional Information
below is the settings.json
4 Comments
i tried again and checked on API keys as well:
PS C:\Users\Admin> claude
Claude Code could not start: EUNKNOWN: unknown error, stat '\\c\Users\Admin\OneDrive - jnkresearch.com\SharedData'
PS C:\Users\Admin> claude --print "run the jnk-morning-brief"
PS C:\Users\Admin> claude auth status
{
"loggedIn": true,
"authMethod": "claude.ai",
"apiProvider": "firstParty",
"apiKeySource": "ANTHROPIC_API_KEY",
"email": "mjacobs@signalpoint.ai",
"orgId": "c15216c8-c02c-4406-a1b2-9fca8cf8dd78",
"orgName": "mjacobs@signalpoint.ai's Organization",
"subscriptionType": "max"
}
PS C:\Users\Admin> ANTHROPIC_API_KEY
ANTHROPIC_API_KEY : The term 'ANTHROPIC_API_KEY' is not recognized as the name of a cmdlet, function, script file, or
operable program. Check the spelling of the name, or if a path was included, verify that the path is correct and try
again.
At line:1 char:1
Found 3 possible duplicate issues:
This issue will be automatically closed as a duplicate in 3 days.
🤖 Generated with Claude Code
Symptom match and root cause found (Windows, silent exit 0 from claude --print)
Environment: Windows 11, Claude Code 2.1.168 (native install), PowerShell, Max subscription, auto-update channel "latest".
Symptom identical to this issue: claude --print "say hello" exits code 0 with zero output, even with --debug. --version and --help work. Debug log initializes normally and ends silently shortly after "Git remote URL: null" (in our case, immediately after "Policy limits: Applied new restrictions successfully").
Root cause in our case: permissions.additionalDirectories in ~/.claude/settings.json contained Git-Bash-style paths, e.g. //c/Users/Admin/JNK_AgentState. Windows treats a leading // as a UNC path (server named "c"), and startup dies silently when these load at user scope. Likely the same family as #60025 (UNC additionalDirectory) and possibly the root-resolution regression noted in #64518.
Supporting evidence from isolation testing:
claude --setting-sources project,local --print works; user scope fails (same asymmetry reported in #60025)
Fresh CLAUDE_CONFIG_DIR works
Temp config-dir bisect: credentials only, .claude.json, and plugins all pass; adding settings.json fails; the same settings.json with additionalDirectories rewritten from //c/... to C:/... passes
The same entries worked until approximately June 5, 2026. With auto-updates on "latest", a release in the June 5-6 window appears to have turned previously tolerated //c/ paths fatal. Suggest checking changes to path-root resolution in releases between 2.1.160 and 2.1.168
Fix/workaround: rewrite additionalDirectories entries to C:/... form.
Request: startup should fail fast with a validation error naming permissions.additionalDirectories (and normalize or reject //drive/ style paths) instead of exiting 0 with no output. The silent exit cost us three days of scheduled-task downtime before diagnosis.
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.