[FEATURE] Allow trusting specific UNC network shares

Preflight Checklist

• [x] I have searched existing requests and this feature hasn't been requested yet
• [x] This is a single feature request (not multiple features)

Problem Statement

Since Claude Code 2.1.292 (VS Code extension, Windows), every Read, Grep and Glob call on a UNC path (\\server\share\...) asks for approval, and there is no way to trust a specific network share:

• the prompt offers no "Yes, and don't ask again" option;
• explicit allow rules such as Read(///fileserver01/www/portal/**) are not honored;
• UNC entries in permissions.additionalDirectories are silently ignored (no startup warning).

A single routine task, such as finding where a function is used across a PHP code base, now triggers dozens of prompts. This is a regression for teams whose code lives on internal file shares.

We also noticed an inconsistency: allow rules like PowerShell(Select-String *) are honored on the same UNC paths and run without a prompt. So arbitrary shell commands can be trusted, but the built-in read-only file tools, which are the safer option, cannot.

Proposed Solution

Provide an explicit, opt-in way to trust specific network locations, for example:

1. Honor explicit Read(//server/share/**) allow rules (and/or additionalDirectories) for UNC paths, as is already done for PowerShell allow rules; or
2. Add a dedicated setting, accepted only in user or managed settings (not project settings, so a repository cannot add it):

``json
"permissions": {
"trustedNetworkPaths": ["\\\\fileserver01\\www", "\\\\fileserver02\\scripts"]
}
``

1. Additionally, offer "Yes, and don't ask again for this share" in the permission prompt.

In any case, emit a startup warning when additionalDirectories or Read/Edit rules contain UNC paths that are ignored.

Alternative Solutions

• Mapping the share to a drive letter (as the docs suggest): it works, since reads on a mapped drive don't prompt. But in our environment drive letters differ between users and machines, and our VS Code workspaces, scripts and documentation all use UNC paths, so switching would cause many other problems.
• Allowing read-only PowerShell commands (PowerShell(Get-ChildItem *), PowerShell(Select-String *), PowerShell(Select-Object *), PowerShell(Get-FileHash *)): this is our current workaround for searches. It removes prompts for searching, but reading a file still requires the Read tool and a prompt. It also pushes Claude toward shell commands instead of the dedicated tools, which seems the opposite of what is intended.
• Approving every prompt: not workable for real tasks.

Priority

Medium - Would be very helpful

Feature Category

Configuration and settings

Use Case Example

A team keeps its code on an internal Windows file share and opens it in VS Code through a UNC path, e.g. \\fileserver01\projects\app. There is no local copy.

Typical task: "Where is function foo() used, and is this file still referenced anywhere?" Claude has to search the whole share, then read the 5–10 matching files. Before 2.1.292 this ran without prompts thanks to explicit allow rules. Now each search and each file read needs a manual click, and the user cannot permanently approve a share they explicitly trust.

Example configuration that used to work (user settings.json):

"permissions": {
  "additionalDirectories": ["\\\\fileserver01\\projects\\app"],
  "allow": [
    "Read(///fileserver01/projects/app/**)",
    "Edit(///fileserver01/projects/app/**)"
  ]
}

Additional Context

• Claude Code VS Code extension 2.1.292 (win32-x64), auto-updated on 2026-10-07; behavior was fine on the previous version.
• Windows 11 Enterprise, Windows PowerShell 5.1.
• Related changelog entry (2.1.292): "Security: Fixed PreToolUse hook approvals and auto mode bypassing the permission prompt for file reads from network (UNC) paths".
• The permissions docs state that UNC shares can no longer be working directories, and that UNC arguments in shell commands prompt because they may send Windows credentials to the host. We understand this concern for arbitrary hosts; our request is only for hosts the user explicitly lists in their own settings.