bypassPermissions mode still prompts for Edit/Write on UNC paths (Windows)

Status Open

Maintainer reply None cached

Activity 4 comments · opened Apr 1, 2026

Description

On Windows 10, bypassPermissions mode does not auto-approve Edit/Write tool calls when the working directory or file paths use UNC paths (\server\share\...). Claude Code always shows the "Do you want to make this edit?" confirmation prompt, even though the file is inside the current working directory.

Repro

Windows 10, Claude Code latest, Git Bash shell
Global settings.json has "defaultMode": "bypassPermissions" and "skipDangerousModePermissionPrompt": true
Launch CC from a UNC path: cd //server/share/project && claude --dangerously-skip-permissions
Ask CC to edit any file in the project

Expected: Edit proceeds without prompting (bypass mode)
Actual: "Do you want to make this edit to file.html?" prompt appears every time

What was tried (none worked)

Adding UNC path to additionalDirectories (both \\server\share and //server/share formats)
Adding "defaultMode": "bypassPermissions" at project level in .claude/settings.local.json
PreToolUse hook returning {"decision":"approve"} — hook fires and returns approve correctly, but CC still prompts
Fresh session (not resumed)
Removing local symlinks that previously pointed to the UNC path

Debug info

PreToolUse hook logging confirms:

permission_mode is "bypassPermissions"
cwd is \\MURKYSERVER\murky\PROJECTS\gram1-web
file_path is \\MURKYSERVER\murky\PROJECTS\gram1-web\site\product.html (inside cwd)
The prompt still appears

Workaround

Using a mapped drive letter (e.g., L:\PROJECTS\project) instead of a UNC path works correctly — bypassPermissions is respected and edits proceed without prompting.

Environment

Windows 10 Home 10.0.19045
Shell: Git Bash
UNC path via SMB to local NAS
Claude Code latest stable channel

View original on GitHub ↗

4 Comments

StayFrosty54 · 3 months ago

This is also the case for windows 11 (25H2). As our team primarily works on shares this is a major headache cause currently..

AndyHaack · 3 months ago

Hitting the same on a different but legitimate Windows setup: Hyper-V VM accessing the host repo via Terminal Services drive redirection (\\tsclient\C\...) — not SMB. None of the documented workarounds apply because tsclient isn't a real SMB share:

net use Z: \\tsclient\C → System error 67 (tsclient is a TS virtual channel, not SMB)
subst Z: \\tsclient\C → refuses UNC paths
mklink /D C:\bz \\tsclient\... → Node calls realpath before passing CWD to the CLI, so the path becomes //tsclient/... again and the check still fires
New-PSDrive → only visible inside the PowerShell process, not to VSCode

So for VM-based development workflows there is no client-side workaround at all — only a CLI-side fix can unblock us.

For maintainer reference, there are two hardcoded checks in the CLI binary that fire before any permission setting is consulted:

// File-path check (Edit / Write / Read)
if (f.startsWith("//") || /DavWWWRoot/i.test(f) || /@SSL@/i.test(f))
  return { allowed: false,
           decisionReason: { type: "other", reason:
             "UNC paths are blocked because they can trigger network requests and credential leakage" }};

// Bash command check
if (FB(q)) return { behavior: "ask",
  message: "Command contains Windows UNC path that could be vulnerable to WebDAV attacks" };

Searched for CLAUDE_CODE_ALLOW_UNC, DISABLE_UNC, tengu_unc, an env var or a CLI flag to opt out — there is nothing. --dangerously-skip-permissions, bypassPermissions mode, additionalDirectories, VSCode security.allowedUNCHosts, and claudeCode.allowDangerouslySkipPermissions: true all have no effect because these checks run before the permission layer.

Would be great to have an opt-in env var (e.g. CLAUDE_CODE_ALLOW_UNC=1) for users who knowingly accept the WebDAV-credential-leak risk on a trusted UNC root.

Deluvio · 2 months ago

I'm facing the same issue

alisson-d-s · 1 month ago