Desktop app (Code tab): auto mode classifier returns "no verdict" for Write when the working directory is on a mapped network drive (works in CLI)[BUG]

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?

In the Claude desktop app (Code tab, Windows), when the session's working directory is on a mapped network drive (H:), every Write tool call to a path on that drive fails in auto mode with "The server-side auto mode classifier gave no verdict (it skipped this action)". It is deterministic: the same call fails every time, not an intermittent outage.

The same Write succeeds when:

• the desktop app session's working directory is a local folder (C:\...), even if the target path is on H:
• the same working directory (H:\...) is used from the Claude Code CLI with --permission-mode auto
• the CLI is started from the UNC path of the same share

So the failure is specific to: desktop app + working directory on a mapped network drive + auto mode.

Results (all in auto mode):

| Client | Working directory | Write target | Result |
|---|---|---|---|
| Desktop app | H:\share\project | H:\share\project\test.md | FAIL (no verdict) |
| Desktop app | H:\share\project | H:\share\project\sub\test.md | FAIL (no verdict) |
| Desktop app | H:\share\project | C:\Users\<user>\Documents\x.md | OK |
| Desktop app | C:\Users\<user>\Documents\work | H:\share\project\test.md | OK |
| CLI | H:\share\project | H:\share\project\test.md | OK |
| CLI | \\DirectCloud\<share>\project | UNC path and H: path | OK |

Environment: H: is a mapped drive (net use shows \\DirectCloud\<share>, "Virtual Network Shares CBFS Connect v20", DriveType 4). Resolve-Path returns H:\... unchanged (not a symlink/junction). Drive client versions 4.1.2 and 3.32.3 behave the same.

What Should Happen?

The classifier should return a verdict (allow/deny) for Write regardless of whether the session's working directory is on a mapped network drive, as it does in the CLI.

Error Messages/Logs

The server-side auto mode classifier gave no verdict (it skipped this action), so auto mode cannot determine the safety of Write. This is a hard failure, not a transient one: the check cannot or does not judge this request, so retrying this action will get the same answer. Don't retry it. Continue with other tasks that don't require it; if it is essential, stop and tell the user that auto mode could not evaluate it. Note: reading files, searching code, and other read-only operations do not require the classifier and can still be used.

Steps to Reproduce

1. On Windows, map a network share to a drive letter (here H: -> \\DirectCloud\<share>, a CBFS Connect virtual network share).
2. In the Claude desktop app, start a new Code session with the working directory on that drive (e.g. H:\share\project), permission mode "auto".
3. Ask Claude to create a one-line file with the Write tool at H:\share\project\test.md.
4. The call fails with the "no verdict" error above. Retrying gives the same result.

For comparison:

• Start the desktop session from a local folder (C:\...) and write to the same H: path: it succeeds.
• Start the Claude Code CLI with cd H:\share\project; claude --permission-mode auto and write the same file: it succeeds.

Note: the desktop app refuses to open a UNC path as the working directory ("Network (UNC) paths are not supported here"), so the UNC form cannot be chosen there.

Claude Model

None

Is this a regression?

I don't know

Last Working Version

_No response_

Claude Code Version

Claude desktop app 2.26454.2 (Windows 10.0.26200 x64); Claude Code CLI 2.1.292

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

PowerShell

Additional Information

Desktop app version: 2.26454.2 (Windows 10.0.26200 x64), updated today. Claude Code CLI 2.1.292 used for comparison. Model: claude-sonnet-5-5.

Ruled out:

• File name (an ASCII-only name fails too) and target subfolder
• CLAUDE.md size/content and .claude settings/hooks in the working directory (tested with copies in a local folder, headless)
• Network drive client version (4.1.2 vs 3.32.3)
• Headless claude -p --permission-mode auto did not reproduce it in any condition, but headless runs report "this workspace has not been trusted" and ignore project permission rules, so it is not equivalent to an interactive session.

Related issues:

• #44152 (closed, not planned): the Windows desktop app Code tab resolves net use mapped drives to UNC paths via fs.realpath(). This may be the same root cause: the classifier input may be built from a path that differs between the mapped-drive and UNC forms. Since the desktop app also refuses UNC working directories, users on a share cannot choose the UNC form there.
• #95982, #96067, #97868: same "no verdict" message in other environments (macOS CLI, WSL plan mode, Windows/VS Code). The plan-mode report suggests the classifier matches paths by string. None of these involve the desktop app or network drives.

Workarounds:

• Use the CLI (cd H:\share\project; claude --permission-mode auto)
• Start the desktop session from a local folder
• Use a permission mode other than auto (manual approval)