[BUG] Permission allowlist / acceptEdits mode ignored when workspace is opened via a UNC network path

Status Open
Reported on v2.1.217
Maintainer reply None cached
Activity 1 comment · opened Jul 22, 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?

When the VS Code extension's workspace root is a UNC network path (\\server\share\...), the permission system does not honor settings.json allow rules or the active permission mode. Every tool call prompts for manual approval, including:

  • Bare, unconditional allow entries ("Edit", "NotebookEdit", "Write") that should not require any path-based matching at all.
  • acceptEdits mode ("Edit automatically" in the extension UI) being active, under which edit-tool calls should never prompt.
  • PowerShell/Bash commands that exactly match existing wildcard allow rules already present in settings.json (e.g. PowerShell(Get-ChildItem *)), verbatim, with no unusual syntax.

Rewriting the offending allow rule in forward-slash/POSIX form (in case of a path-normalization mismatch) did not change the behavior.

What Should Happen?

Tool calls matching an existing allow rule, or covered by the active permission mode (e.g. acceptEdits auto-approving edit-tool calls), should not prompt for manual approval, regardless of whether the workspace root is a local path or a UNC network path.

Error Messages/Logs

Steps to Reproduce

  1. Set up ~/.claude/settings.json (user-level) with, at minimum:

``json
{
"permissions": {
"allow": ["Edit", "Write", "NotebookEdit", "PowerShell(Get-ChildItem *)"]
}
}
``

  1. Open a VS Code workspace whose root is a UNC path, e.g. \\server\share\some-folder.
  2. Set the extension's permission mode to "Edit automatically" (acceptEdits).
  3. Ask Claude to edit any file in the workspace (NotebookEdit or Edit tool call). Observe: a permission dialog appears despite acceptEdits mode.
  4. Ask Claude to run Get-ChildItem "\\server\share\some-folder" in PowerShell. Observe: a permission dialog appears despite the exact matching wildcard rule in settings.json.
  5. Re-run the same two steps, but with the identical folder instead accessed via a net use-mapped drive letter (e.g. net use S: \\server\share, workspace opened at S:\some-folder). Observe: both now proceed silently, with no other configuration changes.

Claude Model

Sonnet (default)

Is this a regression?

I don't know

Last Working Version

_No response_

Claude Code Version

2.1.217 (Claude Code)

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

VS Code integrated terminal

Additional Information

VS Code version:

Version: 1.129.1
Commit: 8a7abeba6e03ea3af87bfbce9a1b7e48fed567b8
Date: 2026-07-17T15:35:09Z
Electron: 42.6.0
ElectronBuildId: 14623276
Chromium: 148.0.7778.280
Node.js: 24.18.0
V8: 14.8.178.38-electron.0
OS: Windows_NT x64 10.0.26200

This is one of two related-but-distinct bugs found while working from a network-share-backed workspace — filed separately per the reporting guidelines. The other (session picker losing track of sessions when the workspace is instead opened via a mapped drive letter) is filed as a separate issue, since switching to a mapped drive is the workaround for this one but trades it for that one.

View original on GitHub ↗

This issue has 1 comment on GitHub. Read the full discussion on GitHub ↗