claude-code - 💡(How to fix) Fix [VSCode] Session history only shows current session on mapped network drive (Windows) [1 comments, 2 participants]

Official PRs (…)
ON THIS PAGE

Recommended Tools

×6

Utilities matched from this issue’s tags and category — try them while you read without losing context.

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

Helpful · Quick feedback

Loading…
GitHub stats
anthropics/claude-code#52885Fetched 2026-04-25 06:18:16
View on GitHub
Comments
1
Participants
2
Timeline
5
Reactions
0
Timeline (top)
labeled ×4commented ×1

The session-history panel in the VSCode extension shows only the currently active session. All prior JSONL sessions on disk are ignored. The CLI (claude --resume in the integrated terminal) correctly lists all of them from the same workspace.

Root Cause

Root cause (from reading extension.js 2.1.119)

The CLI and extension compute different project slugs for the same workspace:

Fix Action

Workaround

For users hitting this now: claude --resume in the integrated terminal works fine, and a junction from the UNC-based slug to the drive-letter slug restores visibility in the extension UI.

Code Example

async function Ao(K)   { ...return (await j8.realpath(K)).normalize("NFC") }
  function kx(K)         { return K.replace(/[^a-zA-Z0-9]/g, "-") }
  async function eD4(K,){ let N = await Rl(K); for (let z of await qx(N))}
RAW_BUFFERClick to expand / collapse

Environment

  • OS: Windows 11 Pro 10.0.26200
  • VSCode extension: anthropic.claude-code 2.1.119
  • Claude CLI: 2.1.119 (bundled native binary)
  • Workspace opened as z:\, where z: is a mapped SMB drive (\\192.168.1.2\some_dir)

Summary

The session-history panel in the VSCode extension shows only the currently active session. All prior JSONL sessions on disk are ignored. The CLI (claude --resume in the integrated terminal) correctly lists all of them from the same workspace.

Reproduction

  1. On Windows, map a network share to a drive letter: net use z: \\server\share
  2. Open that drive as a folder in VSCode (z:\)
  3. Start a few Claude Code chats over multiple days
  4. Reload VSCode, open the Claude panel → Session history (Local tab)
  5. Observed: only the currently active chat is listed
  6. In integrated terminal: claude --resume → all sessions listed correctly

Observed on disk

~/.claude/projects/h--/ contains 7 valid <uuid>.jsonl files, each with "cwd": "z:\\" recorded. No sessions are present in any other projects/* directory for this workspace.

Root cause (from reading extension.js 2.1.119)

The CLI and extension compute different project slugs for the same workspace:

  • CLI receives cwd: "z:\\" literally (visible in extension log: Spawning Claude with SDK query function - cwd: z:\) and writes JSONL to projects/z--/ (slug = kx("z:\\") = "z--").
  • Extension listSessions path:
    async function Ao(K)   { ...return (await j8.realpath(K)).normalize("NFC") }
    function kx(K)         { return K.replace(/[^a-zA-Z0-9]/g, "-") }
    async function eD4(K,){ let N = await Rl(K); for (let z of await qx(N))}
    On Windows, fs.promises.realpath("z:\\") for a mapped SMB drive returns the UNC target (\\192.168.1.2\some_dir). That slugs to --192-168-1-2-some_dir, a directory that doesn't exist. listSessions returns [], and the webview shows only the locally-held active session.

Evidence

  • Extension log (Claude VSCode.log) records cwd: "z:\\" for every launch_claude but nothing resembling list_sessions_response with a non-zero count.
  • Get-SmbMapping Z: confirms the drive maps to \\192.168.1.2\some_dir.
  • Python's os.path.realpath("z:\\") on the same host returns \\\\192.168.1.2\\some_dir, matching the suspected Node behavior.
  • Creating a junction mklink /J "%USERPROFILE%\.claude\projects\--192-168-1-2-some_dir" "%USERPROFILE%\.claude\projects\h--" is expected to hide the bug because the slugs then converge on the same storage.

Expected behavior

The extension should list the same sessions the CLI does for the same workspace, regardless of whether the workspace root is a mapped network drive.

Suggested fix

Either:

  • Skip realpath resolution in Ao() when the input is a Windows drive root that maps to a UNC path (so slug stays z--), or
  • Use the same resolution in CLI and extension (both realpath or neither), so the slug is consistent.

Workaround

For users hitting this now: claude --resume in the integrated terminal works fine, and a junction from the UNC-based slug to the drive-letter slug restores visibility in the extension UI.

extent analysis

TL;DR

The issue can be fixed by ensuring consistent slug computation between the CLI and the extension, either by skipping realpath resolution for Windows drive roots or using the same resolution method in both.

Guidance

  • Verify the issue by checking the extension log for cwd: "z:\\" and the absence of list_sessions_response with a non-zero count.
  • To mitigate the issue, create a junction from the UNC-based slug to the drive-letter slug, as described in the Evidence section.
  • Consider modifying the Ao() function to skip realpath resolution when the input is a Windows drive root that maps to a UNC path.
  • Ensure that the same resolution method is used in both the CLI and the extension to maintain consistent slug computation.

Example

No code snippet is provided, as the issue is related to the interaction between the CLI and the extension, and the suggested fix involves modifying the Ao() function or using a junction.

Notes

The issue is specific to Windows and mapped network drives, and the suggested fix may not apply to other operating systems or configurations.

Recommendation

Apply the workaround by creating a junction from the UNC-based slug to the drive-letter slug, as this provides a temporary solution until the underlying issue is addressed.

Vote matrix · Quick signals

Works
Did the solution work? Tap to confirm.
Easy Fix
Was it a quick fix?
Time Saver
Did it save you time?
Blocking
Was it severely blocking?
Common Issue
Are others likely hitting this too?
Flaky / Intermittent
Is it intermittent?
Verified / Reproducible
Can you reproduce it reliably?
Loading…

FAQ

Expected behavior

The extension should list the same sessions the CLI does for the same workspace, regardless of whether the workspace root is a mapped network drive.

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

Back to top recommendations

TRENDING

claude-code - 💡(How to fix) Fix [VSCode] Session history only shows current session on mapped network drive (Windows) [1 comments, 2 participants]