[BUG] CLI and VSCode extension compute project session folder from different path normalizations on Windows mapped drives

Preflight Checklist

• [x] I have searched existing issues and this hasn't been reported yet
• [x] This is a single bug report (please file separate reports for different bugs)
• [x] I am using the latest version of Claude Code

What's Wrong?

On Windows, when a VSCode workspace lives on a mapped network drive (via net use or subst) or behind a symlink, the Claude Code CLI writes session files to one folder under ~/.claude/projects/ while the VSCode extension reads from a different folder — although both are derived from the same physical workspace directory. Result: the extension sidebar shows no sessions (or only partial sessions) while the CLI works normally. Sessions are written successfully; they're just invisible to the extension.

Neither side errors out. From each side's own perspective, everything succeeds.

What Should Happen?

CLI and extension should compute the same session-folder name from the same physical workspace directory. Sessions written by the CLI should be visible in the extension sidebar regardless of whether the workspace path goes through a mapped drive, a subst drive, or a symlink.

Error Messages/Logs

Steps to Reproduce

1. On Windows, map a drive letter to a UNC share:

``powershell
net use W: \\server\share\user
``

1. Open W:\project as the VSCode workspace with the Claude Code extension installed.
2. In the VSCode integrated terminal, start a session: claude.
3. Send any prompt to create a transcript.
4. Inspect %USERPROFILE%\.claude\projects\:

• w--project\ exists and contains the new .jsonl.
• If --server-share-user-project\ exists, it's empty.

1. Open the Claude Code sidebar in VSCode — no sessions listed.

Also reproduces when using subst instead of net use, or when the workspace root is reached via a symlinked directory.

Claude Model

Opus

Is this a regression?

I don't know

Last Working Version

_No response_

Claude Code Version

2.1.114 (Claude Code)

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

VS Code integrated terminal

Additional Information

Root cause (inferred)

The ~/.claude/projects/<slug>/ folder name is derived from the workspace path by replacing path separators with dashes. CLI and extension disagree on which string form of the path to use as input:

• CLI: uses the path as reported by the host shell (process.cwd() on Node), which preserves the mapped drive letter → W:\project → slug w--project.
• Extension: the path appears to pass through fs.realpath (or equivalent, likely GetFinalPathNameByHandle on Windows) before the slug is computed. That call dereferences mapped drives to their UNC target → \\server\share\user\project → slug --server-share-user-project.

I don't have extension source access, so the exact call site is inferred. The symptom — two slugs for one physical directory, reliably reproducible — is verified.

Workaround

Create a filesystem junction from the extension-expected slug to the CLI-written slug:

New-Item -ItemType Junction `
    -Path   "$env:USERPROFILE\.claude\projects\--server-share-user-project" `
    -Target "$env:USERPROFILE\.claude\projects\w--project"

Works, but doesn't scale — every affected developer has to do this per project.

Suggested fix

CLI and extension should share a single canonicalization rule. Three options:

1. Neither resolves — both sides use the path exactly as the host reports it. Least invasive; requires the extension to avoid any inadvertent realpath-style resolution.
2. Both resolve — both sides call fs.realpath before slugifying. More robust against symlinks, but changes existing slugs for users on mapped drives (migration needed).
3. Shared helper — factor slug computation into a helper exported from the CLI/SDK, so the extension (and any other consumer) calls the exact same logic. Cleanest long-term fix.

Scope

Not limited to network shares. Reproduces on subst drives and symlinked workspace roots. A milder variant may affect macOS/Linux users with symlinked workspace roots, wherever process.cwd() and realpath(cwd) diverge.