[BUG] Windows: folder picker silently rejects folders on virtual drives (ShareFile) - native realpath fails with ERROR_UNRECOGNIZED_VOLUME

What's Wrong?

On Windows, the desktop app's folder picker silently refuses any folder located on a virtual
drive whose volume does not answer GetFinalPathNameByHandleW — ShareFile for Windows (drive S:)
is one such case.

The native folder dialog opens, I select the folder, the dialog closes — and nothing happens.
No error, no toast, no log entry. The folder is simply never selected, so there is no way to tell
whether the app is broken, my install is broken, or the click did not register.

Folders on C:, on Google Drive (G:, Cloud Files API) and on a mapped network drive (T: → UNC)
are all accepted from the same dialog, on the same machine, in the same session.

This is specific to the desktop app: the CLI has no such restriction — running claude from a
terminal whose working directory is on the ShareFile drive works fine, and once a session is open,
Read/Write/Edit/Grep/Glob operate on that drive without any problem. So the folder is perfectly
usable; only the picker rejects it.

What Should Happen?

Either of these would resolve it, in order of preference:

1. Accept the folder. The path is a real, readable directory. Node's JS fs.realpathSync

resolves it correctly on this volume — only fs.realpath.native / fs/promises.realpath fail.
Falling back to the JS implementation when the native one fails would make these drives work.

1. At minimum, show an error. UNC paths already get an explicit message

("Network (UNC) paths are not supported here."). A failure to canonicalize the selected path
returns silently instead, which is indistinguishable from a no-op and impossible to diagnose
from the UI.

Error Messages/Logs

None — that is the core of the report. Nothing in the UI, and %APPDATA%\Claude\logs stays empty.

The underlying OS failure, measured on the same machine (GetFinalPathNameByHandleW via
CreateFileW + FILE_FLAG_BACKUP_SEMANTICS):

C:\Users\<user>   OK -> \\?\C:\Users\<user>
G:\               OK -> \\?\G:\                      (Google Drive)
T:\               OK -> \\?\UNC\<server>\<share>      (mapped network drive)
S:\               FAILS, GetLastError = 1005          (ERROR_UNRECOGNIZED_VOLUME)
S:\Favoris        FAILS, GetLastError = 1005          (ShareFile)

Same split through Node (v22, same machine):

S:\Favoris   fs.realpathSync(p)          -> OK, "S:\Favoris"
S:\Favoris   fs.realpathSync.native(p)   -> ERR UNKNOWN
S:\Favoris   fs/promises.realpath(p)     -> ERR UNKNOWN (errno -4094)
G:\          all three                   -> OK

So the volume is fully readable; it just does not implement the final-path API that the native
resolver relies on.

Steps to Reproduce

1. On Windows, install a client that mounts a virtual drive not backed by a recognized volume —

ShareFile for Windows 25.9.2.0 mounts S: here. (Any volume where
GetFinalPathNameByHandleW returns error 1005 will do.)

1. In the desktop app, start a new session and open the folder picker.
2. Navigate to any folder on that drive and confirm the selection.
3. The dialog closes and nothing happens — no folder selected, no error shown.

For comparison, selecting a folder on C: or on Google Drive in the same dialog works.

Related, and probably the same code path: passing such a path programmatically instead of using
the dialog fails too, but at least reports The requested directory could not be resolved.
So the resolution step is shared; only the picker swallows the failure.

Additional Information

• Not an encoding issue: S:\Favoris (plain ASCII, no accents) fails exactly like paths

containing accented characters.

• Not a permissions issue: the drive is readable from the app's own child processes.
• An NTFS junction does not work around it — mklink /J C:\local S:\folder still resolves

through to the S: volume and fails identically.

• ShareFile is not in the recognized cloud-provider list (OneDrive, SharePoint, Box, Dropbox,

GoogleDrive, iCloud, ProtonDrive, Nextcloud, pCloud, Egnyte, Tresorit), but that is not the
cause — the failure happens earlier, at path canonicalization, before any provider lookup.

• Practical impact: work stored on ShareFile cannot be opened in the desktop app at all. The CLI

is the only workaround, which defeats the purpose for users who want the desktop app.

Versions

• Desktop app: 1.40609.0 (bundled CLI 2.1.247)
• OS: Windows 10 Pro, build 19045
• ShareFile for Windows: 25.9.2.0