[BUG] Suspicious-path prompt for symlinked project directories cannot be allowlisted (only "Allow once")

Resolved 💬 2 comments Opened Jun 11, 2026 by travis-ray Closed Jun 15, 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?

Environment
Claude Code 2.1.170, Windows 10 Pro 10.0.19045 (desktop app)
Working directory: C:\Sandbox
C:\Sandbox\Bridge-Dev and C:\Sandbox\Bridge are directory symlinks to UNC shares (\\bridge-dev\htdocs and \\photoserver\htdocs)
Problem
Every Edit/Write tool call targeting a file under the symlinked directories triggers a "suspicious Windows path" permission prompt. The dialog only offers "Allow once" — there is no "always allow" option, and no configuration suppresses it. With dozens of edits per session this makes the Edit tool unusable for these repos.

This is a legitimate, common setup: the project root lives on the dev machine, with legacy web roots mounted as junctions/symlinks to network shares so one workspace covers all systems.

What we tried (none suppress the prompt, all verified after full restart)
In ~/.claude/settings.json:

{
"permissions": {
"defaultMode": "bypassPermissions",
"allow": [
"Edit()", "Write()",
"Edit(//bridge-dev/htdocs/)", "Write(//bridge-dev/htdocs/)",
"Edit(C:/sandbox/)", "Write(C:/sandbox/)"
],
"additionalDirectories": [
"C:\\sandbox", "C:\\Sandbox",
"\\\\bridge-dev\\htdocs", "\\\\photoserver\\htdocs",
"//bridge-dev/htdocs", "//photoserver/htdocs",
"C:/sandbox/Bridge-Dev", "C:/sandbox/Bridge"
]
}
}
defaultMode: bypassPermissions — still prompts
Blanket and path-scoped allow rules for Edit/Write — still prompts
additionalDirectories with the symlink path, the resolved UNC target, both slash directions, and both casings — still prompts
The prompt dialog shows the as-typed C:\sandbox\... path, fires regardless of path casing, and offers only "Allow once"

What Should Happen?

Expected
At least one of:

additionalDirectories containing the symlink path or its resolved UNC target should bring the resolved location into scope and skip the suspicious-path heuristic
The prompt should offer "Always allow for this location" so the decision can persist
A documented settings key to trust specific symlink targets
Actual
The symlink-resolution safety check appears to sit above the entire permission system with no escape hatch. The only workaround is bypassing the Edit/Write tools entirely and writing files through shell commands (Bash/PowerShell + node fs scripts), which loses diff previews, file-state tracking, and the safety the permission system is supposed to provide — strictly worse for both safety and UX than an allowlist.

Error Messages/Logs

Steps to Reproduce

Repro
On Windows: mklink /D C:\proj\linked \\someserver\share
Start Claude Code with cwd C:\proj
Add C:\proj, C:\proj\linked, and \\someserver\share to permissions.additionalDirectories; set any allow rules you like; restart
Ask Claude to edit a file under C:\proj\linked\ → suspicious-path prompt with "Allow once" only

Claude Model

None

Is this a regression?

I don't know

Last Working Version

_No response_

Claude Code Version

Claude 1.11847.5 (9692f0) 2026-06-09T17:34:27.000Z

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

Other

Additional Information

_No response_

View original on GitHub ↗

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