[Windows] /resume / session history always empty for projects on mapped network drives — extension and CLI compute different project slugs

Environment

• Claude Code VSCode extension: v2.1.205 (native binary claude.exe 2.1.205, win32-x64)
• OS: Windows 11 Pro (10.0.26200)
• Project location: mapped SMB network drive (Y: → \\server\share), workspace opened as Y:\my-project

Summary

When a project lives on a mapped network drive, the VSCode panel's session history (/resume, past chats) is always empty — only the live session appears — even though all transcripts exist and are perfectly valid. Users understandably conclude their history is lost. It is not: the extension is simply looking in the wrong directory.

Root cause

The CLI and the extension canonicalize the project path differently before slugifying it into ~/.claude/projects/<slug>:

• The CLI writes transcripts under the slug of the raw cwd:

y:\my-project → ~/.claude/projects/y--my-project/ ✅ (all sessions are here)

• The extension's session listing first resolves the cwd with fs.promises.realpath(cwd). In Node, fs.promises.realpath is the native implementation (libuv uv_fs_realpath → GetFinalPathNameByHandle on Windows), which resolves mapped drives to their UNC target — unlike fs.realpathSync/fs.realpath (JS implementation), which keeps the drive letter:

``
> fs.realpathSync('y:/my-project') // JS impl
y:\my-project
> await fs.promises.realpath('y:/my-project') // native impl
\\server\share\my-project
``

The extension therefore looks for sessions in
~/.claude/projects/--server-share-my-project/ — a directory that does not exist → readdir throws → empty session list.

The mismatch is deterministic: reader and writer can never agree for any workspace on a mapped drive, so history appears permanently empty on every launch.

I verified the rest of the pipeline is healthy by replaying the picker's filtering logic (head/tail 64 KB window, entrypoint/sessionKind programmatic filter, isSidechain first-line check, title extraction) against all 19 transcripts of the affected project: 19/19 pass. Only the directory resolution differs.

Steps to reproduce

1. Map a network share: net use Y: \\server\share
2. Open Y:\my-project in VSCode with the Claude Code extension and run a couple of sessions.
3. Observe transcripts being created in %USERPROFILE%\.claude\projects\y--my-project\.
4. Type /resume (or open past chats) in the panel.

Expected: past sessions of the workspace are listed.
Actual: the list is empty (only the currently live session is shown). Terminal claude --resume from Y:\my-project works fine, since the CLI uses the drive-letter slug.

Workaround

An NTFS junction making both slugs point at the same directory:

New-Item -ItemType Junction `
  -Path "$HOME\.claude\projects\--server-share-my-project" `
  -Target "$HOME\.claude\projects\y--my-project"

/resume immediately lists every past session again.

Suggested fix

Use the same canonicalization on the write and read paths. Either avoid the native realpath when deriving the project slug (matching the CLI), or fall back to probing the raw-cwd slug when the realpath-derived slug directory doesn't exist. (Handling both slugs on read would also repair history for users who already have transcripts split across the two forms.)