[VSCode] Session history only shows current session on mapped network drive (Windows)

Environment

• OS: Windows 11 Pro 10.0.26200
• VSCode extension: anthropic.claude-code 2.1.119
• Claude CLI: 2.1.119 (bundled native binary)
• Workspace opened as z:\, where z: is a mapped SMB drive (\\192.168.1.2\some_dir)

Summary

The session-history panel in the VSCode extension shows only the currently active session. All prior JSONL sessions on disk are ignored. The CLI (claude --resume in the integrated terminal) correctly lists all of them from the same workspace.

Reproduction

1. On Windows, map a network share to a drive letter: net use z: \\server\share
2. Open that drive as a folder in VSCode (z:\)
3. Start a few Claude Code chats over multiple days
4. Reload VSCode, open the Claude panel → Session history (Local tab)
5. Observed: only the currently active chat is listed
6. In integrated terminal: claude --resume → all sessions listed correctly

Observed on disk

~/.claude/projects/h--/ contains 7 valid <uuid>.jsonl files, each with "cwd": "z:\\" recorded. No sessions are present in any other projects/* directory for this workspace.

Root cause (from reading extension.js 2.1.119)

The CLI and extension compute different project slugs for the same workspace:

• CLI receives cwd: "z:\\" literally (visible in extension log: Spawning Claude with SDK query function - cwd: z:\) and writes JSONL to projects/z--/ (slug = kx("z:\\") = "z--").
• Extension listSessions path:

``js
async function Ao(K) { ...return (await j8.realpath(K)).normalize("NFC") }
function kx(K) { return K.replace(/[^a-zA-Z0-9]/g, "-") }
async function eD4(K,…){ let N = await Rl(K); for (let z of await qx(N)) … }
`
On Windows, fs.promises.realpath("z:\\") for a mapped SMB drive returns the UNC target (\\192.168.1.2\some_dir). That slugs to --192-168-1-2-some_dir, a directory that doesn't exist. listSessions returns []`, and the webview shows only the locally-held active session.

Evidence

• Extension log (Claude VSCode.log) records cwd: "z:\\" for every launch_claude but nothing resembling list_sessions_response with a non-zero count.
• Get-SmbMapping Z: confirms the drive maps to \\192.168.1.2\some_dir.
• Python's os.path.realpath("z:\\") on the same host returns \\\\192.168.1.2\\some_dir, matching the suspected Node behavior.
• Creating a junction mklink /J "%USERPROFILE%\.claude\projects\--192-168-1-2-some_dir" "%USERPROFILE%\.claude\projects\h--" is expected to hide the bug because the slugs then converge on the same storage.

Expected behavior

The extension should list the same sessions the CLI does for the same workspace, regardless of whether the workspace root is a mapped network drive.

Suggested fix

Either:

• Skip realpath resolution in Ao() when the input is a Windows drive root that maps to a UNC path (so slug stays z--), or
• Use the same resolution in CLI and extension (both realpath or neither), so the slug is consistent.

Workaround

For users hitting this now: claude --resume in the integrated terminal works fine, and a junction from the UNC-based slug to the drive-letter slug restores visibility in the extension UI.