Issue Station
Sign In
Tools hereToolbox

claude-code - 💡(How to fix) Fix Hardcoded UNC path block cannot be bypassed, even with --dangerously-skip-permissions / bypassPermissions mode

Official PRs (…)
ON THIS PAGE

Recommended Tools

×6

Utilities matched from this issue’s tags and category — try them while you read without losing context.

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

Helpful · Quick feedback

Loading…

When the working directory is a UNC path (e.g. \\tsclient\C\..., which is legitimate for Hyper-V VMs using Terminal Services drive redirection), Claude Code prompts for every tool invocation and subdirectory access. bypassPermissions mode, --allow-dangerously-skip-permissions, additionalDirectories, and VSCode's security.allowedUNCHosts all have no effect. The CLI contains a hardcoded check:

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" }};

and a companion check for Bash commands:

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

Root Cause

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" }};

Fix Action

Fix / Workaround

Attempted workarounds (all failed)

  • Directory symlink (mklink /D C:\bz \\tsclient\C\...) — Node/VSCode call realpath before handing CWD to the CLI, so UNC path is restored
  • net use Z: \\tsclient\C — rejected, tsclient isn't an SMB share
  • subst Z: \\tsclient\C — refuses UNC paths by design
  • New-PSDrive -Persist — requires a "remote computer" target
  • Searched the binary for env vars / flags / feature flags to disable the check: none exist

Request

Provide an opt-in escape hatch for trusted UNC hosts — e.g. a CLAUDE_CODE_ALLOW_UNC_HOSTS env var, a permissions.allowedUNCHosts settings entry mirroring VSCode's security.allowedUNCHosts, or a CLI flag. The WebDAV-attack mitigation is reasonable as a default, but should be overridable for users who understand the risk (same pattern as --dangerously-skip-permissions).

Code Example

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" }};

---

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

Summary

When the working directory is a UNC path (e.g. \\tsclient\C\..., which is legitimate for Hyper-V VMs using Terminal Services drive redirection), Claude Code prompts for every tool invocation and subdirectory access. bypassPermissions mode, --allow-dangerously-skip-permissions, additionalDirectories, and VSCode's security.allowedUNCHosts all have no effect. The CLI contains a hardcoded check:

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" }};

and a companion check for Bash commands:

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

Environment

  • VSCode extension anthropic.claude-code-2.1.116-win32-x64
  • Windows 10 guest inside Hyper-V, project accessed via \\tsclient\C\... drive redirect from Windows 11 host
  • VSCode setting security.allowedUNCHosts: ["tsclient"] set (no effect on Claude Code)

Why this is a real use case

The UNC mount is intentional: the project is also mounted via SMB on a Linux server (Oracle EBS r12) so that binary files (Oracle Forms .fmb) can be compiled directly on the server without transfer. Working from a local copy would break that workflow.

Attempted workarounds (all failed)

  • Directory symlink (mklink /D C:\bz \\tsclient\C\...) — Node/VSCode call realpath before handing CWD to the CLI, so UNC path is restored
  • net use Z: \\tsclient\C — rejected, tsclient isn't an SMB share
  • subst Z: \\tsclient\C — refuses UNC paths by design
  • New-PSDrive -Persist — requires a "remote computer" target
  • Searched the binary for env vars / flags / feature flags to disable the check: none exist

Request

Provide an opt-in escape hatch for trusted UNC hosts — e.g. a CLAUDE_CODE_ALLOW_UNC_HOSTS env var, a permissions.allowedUNCHosts settings entry mirroring VSCode's security.allowedUNCHosts, or a CLI flag. The WebDAV-attack mitigation is reasonable as a default, but should be overridable for users who understand the risk (same pattern as --dangerously-skip-permissions).

extent analysis

TL;DR

The most likely fix is to add an opt-in escape hatch for trusted UNC hosts, such as a CLAUDE_CODE_ALLOW_UNC_HOSTS environment variable or a permissions.allowedUNCHosts settings entry.

Guidance

  • Identify the specific UNC paths that need to be allowed and consider adding them to a potential CLAUDE_CODE_ALLOW_UNC_HOSTS environment variable or permissions.allowedUNCHosts settings entry, if implemented.
  • Review the code checks for UNC paths and WebDAV attacks to understand the security concerns and potential risks of overriding these checks.
  • Consider collaborating with the developers of the Claude Code extension to implement the requested opt-in escape hatch, as it would require changes to the extension's code.
  • Evaluate the feasibility of using a different approach, such as mapping the UNC path to a local drive letter using a third-party tool or script, although this may not be possible due to the realpath call.

Example

No code snippet is provided as it would require modifications to the existing codebase, which is not currently possible without the requested changes.

Notes

The current implementation of the Claude Code extension has a hardcoded check for UNC paths, which is designed to prevent potential WebDAV attacks. However, this check may be overly restrictive for certain use cases, such as the one described. Any potential solution would need to balance security concerns with the need for flexibility and customization.

Recommendation

Apply a workaround, such as collaborating with the developers to implement the requested opt-in escape hatch, as the current implementation does not provide a built-in solution to this issue. This would allow users to opt-in to allowing trusted UNC hosts, while still maintaining the default security checks for other users.

Vote matrix · Quick signals

Works
Did the solution work? Tap to confirm.
Easy Fix
Was it a quick fix?
Time Saver
Did it save you time?
Blocking
Was it severely blocking?
Common Issue
Are others likely hitting this too?
Flaky / Intermittent
Is it intermittent?
Verified / Reproducible
Can you reproduce it reliably?
Loading…
#latency issue#model loading#dependency error#configuration error#environment variable

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

Back to top recommendations

TRENDING

claude-code - 💡(How to fix) Fix Hardcoded UNC path block cannot be bypassed, even with --dangerously-skip-permissions / bypassPermissions mode