VS Code history panel can't find sessions on a mapped network drive

VS Code extension can't find sessions on a mapped network drive — project-key mismatch (fs.promises.realpath resolves drive letter → UNC). Still repros in v2.1.168 (follow-up to #45424)

Summary

On Windows, when a VS Code workspace lives on a mapped network drive (e.g. Z: → \\server\share), the Claude Code extension's session-history panel is always empty and previous sessions can't be resumed from the UI. The session .jsonl files exist and are intact — the extension just looks for them under the wrong project key.

This is a follow-up to #45424, where this was diagnosed in a comment but the issue was then closed by the stale-bot as inactive (with an invitation to open a new issue). It still reproduces on Claude Code v2.1.168 (CLI and VS Code extension, win32-x64), Windows 11.

Root cause (refined vs #45424)

The extension derives the project key from the workspace folder via await fs.promises.realpath(folder), then encodes it (every non-alphanumeric character → -). The CLI, launched in the integrated terminal, derives its key from the raw terminal CWD, which keeps the drive letter.

The key refinement over #45424 is which realpath variant matters. Measured on a real mapped drive (Z: → \\server\share, Node v24):

input                  : Z:\My Project               =>  Z--My-Project
fs.realpathSync        : Z:\My Project               =>  Z--My-Project              (JS impl — drive letter PRESERVED)
fs.realpathSync.native : \\server\share\My Project   =>  --server-share-My-Project  (native binding — UNC)
fs.promises.realpath   : \\server\share\My Project   =>  --server-share-My-Project  (<-- the extension's actual call)

The native binding (libuv uv_fs_realpath → GetFinalPathNameByHandle) expands the mapped drive to its UNC target; the JS fs.realpathSync does not. So:

• CLI writes sessions under Z--My-Project (drive-letter CWD).
• Extension scans --server-share-My-Project (fs.promises.realpath → UNC).

The two keys never match → the panel is empty. Projects on local drives are unaffected because realpath returns the same path there.

Reproduction

1. Map a network share to a drive letter (Z: → \\server\share).
2. Open a VS Code workspace whose folder is Z:\My Project.
3. Run claude in the integrated terminal and complete a session.
4. Close and reopen the workspace → the session does not appear in the panel.
5. Confirm: the file exists at ~/.claude/projects/Z--My-Project/, but the extension looks in ~/.claude/projects/--server-share-My-Project/ (which doesn't exist).

~/.claude/projects/
  Z--My-Project/                  <- contains the *.jsonl sessions (written by the CLI)
  --server-share-My-Project/      <- ABSENT (the directory the panel scans)

Workarounds

A. Recover existing sessions into the panel — directory junction (reversible, no data moved). Point the extension's expected UNC-form key at the real folder:

New-Item -ItemType Junction `
  -Path   "$env:USERPROFILE\.claude\projects\--server-share-My-Project" `
  -Target "$env:USERPROFILE\.claude\projects\Z--My-Project"

After reloading the window, the panel lists the sessions. New CLI sessions keep landing in the real folder and appear through the junction. (Junctions need no admin; undo by deleting the link with rmdir.)

B. Fix going forward — open the workspace via the UNC path (\\server\share\My Project) instead of the mapped drive letter (per #45424). Then both the CLI CWD and the extension's realpath resolve to the same UNC key. ⚠️ This does not retroactively surface sessions already written under the Z-- key — those still need workaround A.

C. Resume from the CLI — claude --resume in the integrated terminal works regardless, because the CLI keys off the drive-letter CWD (the same key the files are stored under).

Suggested fix

Make both sides agree on the key. Any of:

• Have the extension preserve the drive letter (use JS fs.realpathSync semantics, or skip realpath resolution when the path already refers to a mapped drive on Windows), or
• Apply the identical resolution to the CLI CWD so both produce the same key regardless of how the drive is referenced, or
• Defensive fallback: if the computed project directory is missing but a sibling directory resolves (via the OS) to the same physical location, use it.

Environment

• Claude Code: v2.1.168 (CLI and VS Code extension, win32-x64)
• OS: Windows 11
• Node used for the realpath probe above: v24
• Related: #45424 (closed as inactive; this is the requested follow-up)