VSCode extension: session history broken on Windows mapped network drives (realpath divergence)

Description

The VSCode extension fails to find session history for projects opened from Windows mapped network drives (e.g. Y:\, Z:\, Q:\). Sessions created by the CLI are stored correctly but the extension looks in a different folder, so the session selector appears empty or sessions flash briefly then disappear.

Root cause

The CLI and the extension use different realpath implementations that return different results on Windows mapped network drives:

| Function | Result for Y:\crm |
|----------|---------------------|
| fs.realpathSync() (JS impl) | Y:\crm (drive letter) |
| fs/promises.realpath() (native impl) | \\172.16.1.90\nacre.interne\crm (UNC) |

• CLI uses fs.realpathSync() → sanitizes to y--crm → stores sessions in ~/.claude/projects/y--crm/
• Extension uses fs/promises.realpath() (in the listSessions path) → sanitizes to --172-16-1-90-nacre-interne-crm → looks for sessions in ~/.claude/projects/--172-16-1-90-nacre-interne-crm/ → folder doesn't exist

This is a known Node.js behavior: fs.realpathSync() uses a JS implementation that preserves drive letters, while fs/promises.realpath() delegates to the native OS call which resolves mapped drives to their UNC path.

Two variants observed

Variant 1: VSCode provides UNC path directly

Some drives (e.g. Q:\ mapped to \\192.168.8.2\config) are stored as UNC in VSCode's workspace.json:

{ "folder": "file://192.168.8.2/config" }

The extension receives \\192.168.8.2\config as fsPath, so this.cwd is already UNC-based. The CLI always uses the drive letter. Result: different sanitized folder names.

Variant 2: fs.realpathSync vs fs/promises.realpath diverge

Other drives (e.g. Y:\crm, Z:\leximpact_extranet) are stored with the drive letter in workspace.json, but:

• The constructor sets this.cwd via fs.realpathSync() → keeps drive letter
• listSessions() resolves via fs/promises.realpath() → returns UNC path

Sessions load initially (from this.cwd), then listSessions() runs async, finds nothing at the UNC-derived path, and clears the list.

Environment

• Windows 11 Pro
• Network drives mapped via SMB to various NAS/servers
• Claude Code extension v2.1.x+
• Affects multiple drives/servers — behavior is non-deterministic depending on the server, mapping method, and Windows resolver cache state

Current workaround

Create NTFS junctions to bridge the two folder names:

mklink /J C:\Users\<user>\.claude\projects\--172-16-1-90-nacre-interne-crm C:\Users\<user>\.claude\projects\y--crm

This works but must be redone for each new project and can break on extension updates.

Suggested fix

Use the same realpath implementation consistently in both the CLI and the extension. Either:

1. Use fs.realpathSync() (JS implementation) everywhere, or
2. Use fs.realpathSync.native() / fs/promises.realpath() everywhere, or
3. Normalize mapped drive letters to UNC (or vice versa) before sanitizing the project folder name

Option 1 seems simplest since the CLI already uses fs.realpathSync() and it preserves the user-facing drive letter.