[BUG] Windows: VS Code extension hides sessions when drive-letter case in recorded cwd differs from current workspace cwd

Found 1 possible duplicate issue:

1. https://github.com/anthropics/claude-code/issues/34125

This issue will be automatically closed as a duplicate in 3 days.

• If your issue is a duplicate, please close it and 👍 the existing issue instead
• To prevent auto-closure, add a comment or 👎 this comment

🤖 Generated with Claude Code

I don't think this is an exact duplicate. This one appears to be about case insensitivity on Windows, not about UNC/mapped letter mismatch. Please check the attached memory file - there are no UNC paths involved but there are the same paths with different drive letter cases present. Also, this appears to happen not only on mapped network drivers, but also on drives mapped using "subst".

Hi, I'd like to investigate and work on this issue.

Sure. If you want me to do any debugging steps please let me know.

I investigated the repository but couldn't locate the VS Code extension source responsible for session/workspace matching.

Could you point me to the extension code path or relevant files where session cwd comparisons are handled? I'd like to work on a Windows-safe normalization fix for the drive-letter casing mismatch.

Confirming on Windows 11, project on a non-system drive (H:), VSCode extension + CLI.

Root cause: the CLI and the extension normalize the drive letter differently when building the ~/.claude/projects/<key> folder name:

• CLI lowercases it → h--...
• VSCode extension keeps Windows' capital → looks up H--... and matches the on-disk name case-sensitively

So Session history → Local shows empty even though all session .jsonl files exist — the keys just don't match (nothing is lost).

A junction can't bridge them: mklink /J fails with "file already exists" because the FS is case-insensitive and both names are the same folder. The mismatch is purely in the extension's case-sensitive string compare.

Workaround — case-only rename the on-disk folder to match how the workspace opens (two-step, since the FS is case-insensitive):

cd %USERPROFILE%\.claude\projects
ren "h--<encoded-path>" "tmp__rename"
ren "tmp__rename" "H--<encoded-path>"

Suggested fix: use the same drive-letter normalization in CLI and extension, and/or make the project-folder lookup case-insensitive on Windows.

I investigated the repository to work on this issue but couldn't locate the VS Code extension source responsible for session/workspace matching.

I searched for extension manifests (package.json), vscode imports, ExtensionContext, workspaceFolders, globalState, and code related to ~/.claude/projects session lookup, but none of those components appear to exist in this repository.

This makes me think the VS Code extension implementation may live in a separate repository or an internal/private codebase.

If the extension source is available somewhere else, could a maintainer point me to the relevant repository or directory? I'd be happy to investigate and work on a Windows-safe drive-letter normalization fix for the session lookup issue.

Another possible issue is that if the original path has spaces, the spaces are replaced with - (like \).
And so the ~/.claude/projects/<key> folder name can have - to represent either a space or a \.
I imagine it's not easy to reconstruct the path from here.
As an example,
h--folder-name
could come from
h:\\folder name
or
h:\\folder\name

The real issue for me is neither the capitalization of the drive nor the spaces, but #63527 (see full log here)

Independent reproduction on a different mapped drive (W:, an SMB share on a
NAS — Win32_LogicalDisk DriveType 4), Windows 11 Pro, Claude Code 2.1.214, VS
Code extension. Your diagnosis is correct, and the root cause is now well
documented in #75855 and #76994: project paths are used as
case-sensitive keys in ~/.claude.json, while Windows paths are
case-insensitive.

Important caveat on the mapped-drive framing, though: the mapping is not
required. I hit this on a mapped share and on a plain internal NTFS disk
(DriveType 3) and on a cloud-sync client mount. The heaviest oscillation I
recorded is on the local disk, not the network one — 373 lowercase records
against 2348 uppercase for the same folder in a single session.

| drive | DriveType | filesystem | affected |
|---|---|---|---|
| mapped SMB share | 4 (network) | NTFS | yes |
| internal disk | 3 (local) | NTFS | yes |
| cloud-sync client mount | 3 (local) | FAT32 | yes |

So this is unlikely to be a network-drive issue at all — it looks like the
general case-sensitivity bug in #75855, which mapped-drive users happen to
notice because they are more likely to have drive letters that differ in case
between surfaces. Same for #63527 and #76205, possibly.

Confirming with transcript-level evidence, since this issue currently rests on
inference.

The casing genuinely does alternate, as you suspected. It isn't random,
though — it flips with shell tool use. One ~6-hour session:

'w:\'   680 records
'W:\'   346 records

78 transitions between the two, each following a shell tool call. The extension
supplies a lowercase baseline (VS Code lowercases drive letters in folder URIs);
any Bash or PowerShell call reports the true on-disk casing back. Verified by
running a single PowerShell call and watching the uppercase count go 61 → 63.

The result is two entries in ~/.claude.json for one folder:

| field | W:/ | w:/ |
|---|---|---|
| hasTrustDialogAccepted | True | False |
| hasCompletedProjectOnboarding | True | absent |
| lastSessionId | present | absent |

Useful thing to know: your sessions are not lost. You mentioned never
getting them back into the VS Code UI. The transcripts are intact — both
identities write into the same on-disk directory, because Windows collapses
the two slug spellings. So the file is sitting in the exact directory the picker
reads, correctly ai-titled, and simply isn't offered because the lookup is
scoped by the case-sensitive key.

You can resume any of them directly by ID:

claude --resume <session-id>

Session IDs are the .jsonl filenames under ~/.claude/projects/<slug>/. That
sidesteps the picker entirely.

Worth checking your retention window too — transcripts age out (30 days by
default), so sessions hidden long enough may be genuinely gone rather than just
hidden. Anything still on disk is recoverable by ID.

On my machine 4 of 12 project keys are case-collision duplicates, and the
earliest lowercase session in my logs is 2026-04-06, so this has been quietly
running for months.

Still present in 2.1.220 (win32-x64). Confirmed the mechanism by inspecting the
bundle — note the title is slightly off: there is no cwd comparison involved.

fetchSessions() in extension.js (minified, line 265) derives the project bucket
name from the workspace path with a sanitizer that preserves letter case, then
reads exactly that one directory and never compares any recorded cwd:

function Zge(e){ let t = e.replace(/[^a-zA-Z0-9]/g,"-"); ... }  // case preserved
function nu(e){ return ci.join(bFt(), Zge(e)) }                 // projects\<sanitized>
async fetchSessions(){
  let t = nu(this.projectRoot);
  try { r = await readdir(t) } catch { return [] }               // silent empty result
}

So the same folder maps to two different buckets depending on the reported case:

k:\21_IoT\20_Tab5\Display_Tab5  ->  projects\k--21-IoT-20-Tab5-Display-Tab5  (exists)
K:\21_IoT\20_Tab5\Display_Tab5  ->  projects\K--21-IoT-20-Tab5-Display-Tab5  (missing)

The catch { return [] } swallows the ENOENT, so the UI shows an empty list with no
indication that a non-existent directory was read — this is what makes it look like
data loss.

Two separate symptoms worth distinguishing: the bucket mismatch is all-or-nothing
(whole list empty), whereas a single session missing while older ones remain
visible points to the static list cache (keyed on the directory) needing a reload.
The reload-window behaviour described in the original report fits the latter.

Also affected on this machine: k: is a mapped subdirectory of C:, so opening the
same folder through its real path produces a third independent bucket
(C--Users-...-Display-Tab5) with its own sessions.

Suggested fix: normalize the drive letter when computing the bucket name, and/or fall
back to a case-insensitive lookup under ~/.claude/projects. At minimum, surface the
ENOENT instead of returning an empty list silently.

Workaround for anyone landing here: the sessions are intact and still reachable with
claude --resume <session-id> (the CLI does not use this list).