[BUG] Code tab (Windows Desktop App) resolves net use mapped drives to UNC paths via fs.realpath(), causing constant permission prompts

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 using the Code tab in the Claude Windows Desktop App with a project folder
on a drive mapped via net use (e.g. D: → \\server\share), the app internally
resolves it to the UNC path via Node.js fs.realpath() during session startup.
This causes:

1. Session folders in .claude\projects\ to be named using the UNC path

(e.g. --server-share-project-...) instead of the drive letter (D--project-...)

1. Constant permission prompts every session, as the UNC path is treated as

an untrusted/unknown location

The user always selects the folder via the drive letter in the folder picker —
the UNC resolution happens silently inside the app.

What Should Happen?

The path provided by the user (e.g. D:\project) should be used as-is without
resolving through fs.realpath(), or UNC paths resulting from net use mapped
drives should be treated as trusted equivalents of the drive letter path.

Error Messages/Logs

Steps to Reproduce

1. Map a network share via net use: net use D: \\server\share
2. Open Claude Desktop, go to the Code tab
3. Start a new session, select a folder on D:\
4. Observe the session is created under .claude\projects\ with a UNC-based name
5. Observe permission prompts on every session start

Claude Model

Sonnet (default)

Is this a regression?

Yes, this worked in a previous version

Last Working Version

Not sure

Claude Code Version

2.1.83

Platform

Other

Operating System

Windows

Terminal/Shell

Other

Additional Information

Environment

• OS: Windows 11
• App: Claude Desktop App (Code tab) — Windows Store install, version 1.569.0.0
• Drive mapping: net use (SMB/Windows network share)

Related issues
#14403 and #20550 were closed as fixed but the bug persists for net use mapped
drives specifically in the Desktop App Code tab.

Workaround
None available — the Windows Store installation puts the app in a read-only
WindowsApps directory (TrustedInstaller only), so no client-side patch can
be applied.