Session history is empty for workspaces on mapped network drives (realpath -> UNC breaks project directory mapping)

Environment

• Claude Code VS Code extension 2.1.267 (win32-x64)
• Windows 11 Pro 10.0.26200
• Workspace opened at Z:\MyProject, where Z: is a mapped network drive → \\fileserver\share\MyProject
• (All paths, hostnames and project names in this report are placeholders.)

Summary

With the workspace on a mapped network drive, the session history panel is always empty. Transcripts exist on disk and are written normally. Another project opened on a local drive (C:\work\OtherProject) works fine.

Symptoms

• History panel renders nothing. Sessions briefly flash into view while the panel loads, then disappear once loading completes.
• Extension log shows the list request succeeding with zero results — no error:

[DIAG-listSessions] OK cwd=z:\MyProject count=0 type=list_sessions_response
(the [DIAG-...] prefix is a temporary diagnostic log line I added while investigating.)

Why it looks like "history disappeared"

The webview first renders sessions from its own persisted panel state (log line: update_panel_host_session ... {"kind":"restore_declined","sessionId":"<session-uuid>"}), then the list_sessions_response carrying sessions: [] replaces the list. The backend genuinely returns 0 — this is not a frontend rendering bug.

Root cause

The extension derives the project directory from the absolute cwd:

// extension.js
function IT$($){ let Q = Y0.resolve($ ?? "."), J; try { J = ho.realpathSync(Q) } catch { J = Q } return Y6(J) }
function zL($, Q){ let J = IT$($); /* ... */ return (...) ?? DP(J) }
// DP() encodes the path by replacing every non-alphanumeric character with "-"

On a mapped network drive, realpath resolution can return the UNC form instead of the drive-letter form. On the affected machine:

fs.realpathSync('Z:\MyProject')        -> 'Z:\MyProject'
fs.realpathSync.native('Z:\MyProject') -> '\\fileserver\share\MyProject'

So the extension computes the project directory --fileserver-share-MyProject, while the CLI (a standalone binary, which receives the drive-letter form) writes transcripts to Z--MyProject. The directory the extension reads from does not exist, readdir throws, and the error is swallowed by try{...}catch{} — producing a silent count=0.

Confirmation: creating a directory junction named --fileserver-share-MyProject pointing at Z--MyProject makes the history appear immediately, with no other change. ~/.claude/projects/Z--MyProject/ already contained 11 valid .jsonl transcripts throughout.

Why local drives are unaffected

For local drives realpath is an identity transform, so both sides agree. C:\work\OtherProject works; Z:\MyProject does not. The drive type is the only variable that differs — session files record inconsistent cwd casing in both projects (Z:\MyProject / z:\MyProject and C:\work\OtherProject / c:\work\OtherProject), so casing is not the cause.

Impact

Every workspace on a mapped network drive silently loses its entire session history, with no error surfaced to the user or written to the log.

Suggestions

1. Don't swallow the failure. Log the resolved project directory and the readdir error. The current bare catch{} makes this undiagnosable from the outside.
2. Make the cwd → project-directory mapping agree between the extension and the CLI — either both resolve, or neither. A cheap mitigation: after realpath, map a UNC path back to its drive letter; or fall back to the unresolved path when the resolved directory doesn't exist.
3. Consider warning when 0 sessions found but N transcripts exist on disk.

Workaround

For each affected project, create a junction in ~/.claude/projects from the UNC-encoded name to the drive-letter-encoded name:

$p = "$env:USERPROFILE\.claude\projects"
New-Item -ItemType Junction -Path "$p\--fileserver-share-MyProject" -Target "$p\Z--MyProject"