VS Code extension Session History and CLI --resume picker show empty for UNC-path workspace, despite no drive-letter/realpath mismatch and working by-ID resume

Preflight Checklist

• [x] I have searched existing issues and this hasn't been reported yet as described (see Related Issues below — related but distinct root cause, explicitly ruled out in Diagnostics)
• [x] This is a single bug report
• [x] I am using the latest version of Claude Code (2.1.220, confirmed current via npm view @anthropic-ai/claude-code version)

What's Wrong?

Both the VS Code extension's Session History panel and the CLI's bare --resume (no session ID) interactive picker fail to list existing, valid sessions for a project whose workspace is opened from a literal UNC network path — even when there is no drive-letter/UNC mismatch and no DFS normalization difference between the path used to write sessions and the path used to look them up. This appears distinct from the drive-letter-vs-realpath bug described in #63527 / #31219 / #14403, since I've explicitly ruled that specific cause out below.

What Should Happen?

Both the VS Code Session History panel and the CLI's bare --resume picker should list all previously saved sessions for the current project — the same sessions that claude --resume <session-id> (explicit ID) successfully loads.

Steps to Reproduce

1. Open VS Code with the workspace folder pointing directly at a UNC path (no drive mapping involved at all).
2. Accumulate several sessions over multiple days via the extension's chat panel (confirmed: 4 .jsonl transcripts under ~/.claude/projects/--<encoded-unc-path>/, one ~840KB from the previous day, others from the current day).
3. In VS Code, open the Claude Code panel and click Session History → only the current/empty session appears; no prior sessions are listed.
4. In the integrated terminal, run bare claude (resolves to the .ps1 shim, not the legacy .cmd), then --resume with no argument → the interactive picker reports no conversations found.

Diagnostics (ruling out the known drive-letter/realpath mismatch)

• node -e "console.log(process.cwd())" run from the exact same shell/cwd returns the literal UNC path unchanged.
• fs.realpathSync(cwd) and the async fs.realpath(cwd) both return byte-for-byte the same UNC string as process.cwd() — no drive-letter substitution, no DFS/namespace normalization difference.
• net use shows zero mapped drives on this machine — a mapped-drive-to-UNC mismatch (the mechanism described in #63527/#31219/#14403) cannot be the cause here.
• CLAUDE_CONFIG_DIR is identical (%USERPROFILE%\.claude) in both the VS Code extension's process environment and the terminal's environment.
• Both the extension and the terminal CLI report the same version (2.1.220).
• The on-disk project directory (~/.claude/projects/--<encoded-unc-path>/) is correctly named and contains valid, current, correctly-sized .jsonl transcripts — sessions are being written to the right place.
• Key finding: resuming a known session by explicit ID works correctly: claude -p --resume <session-id> --output-format json "..." successfully loads the full prior transcript (confirmed via cache_creation_input_tokens matching the transcript's size, a provider: firstParty API call, and a correct session_id echoed back in the result). This proves session storage and by-ID lookup are fully functional.

Conclusion

Since direct by-ID resume works, and cwd/realpath are provably identical with no drive letter in play, the failure is isolated to the session-enumeration/listing logic itself (used by both the VS Code sidebar and the CLI's bare --resume picker) — not to a path-key mismatch between the writer and a reader. This suggests either a second, distinct bug in the enumeration code path for UNC-rooted projects, or a bug that doesn't require the drive-letter precondition previously assumed in #63527/#31219/#14403.

Suggested Investigation

Audit the session-listing code path (the picker/listSessions-equivalent used by both surfaces) for how it handles a project directory whose key is derived from a UNC root with no drive letter at all — it appears to fail to enumerate sessions even when the directory name and cwd/realpath are all in exact agreement.

Is this a regression?

I don't know — this is the first time this machine has needed to list sessions for a UNC-rooted project, so there's no earlier working version to compare against.

Claude Code Version

2.1.220 (Claude Code) (both the VS Code extension and the npm-global CLI report this same version)

Platform

Anthropic API (confirmed via provider: "firstParty" in the by-ID resume test's API response — not Bedrock/Vertex)

Operating System

Windows (10 Pro, build 10.0.19045)

Terminal/Shell

VS Code integrated terminal, PowerShell 5.1 — plus the VS Code extension's own built-in chat panel (non-terminal GUI surface)

Additional Information

• Confirmed no drive letters are mapped on this machine at all (net use returns no entries), so this reproduces on a plain, direct UNC workspace path — not just the mapped-drive scenario described in the related issues.
• Happy to provide extension debug logs (Claude Code: Show Logs) or --debug CLI output if useful for further triage.

Related Issues

• #63527
• #31219
• #14403