[BUG] VS Code extension session picker loses/fails to persist sessions when workspace is opened via a mapped network drive letter

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?

When a VS Code workspace root is a network share accessed via a net use-mapped drive letter (e.g. S:\..., mapped from \\server\share), the extension's session picker/panel fails to reliably track sessions:

• A brand-new session created in that workspace (message sent, response received, .jsonl transcript confirmed written correctly to disk) shows as completely gone from the picker after closing and reopening it.
• An existing, actively-used session shows a static, non-updating "last accessed" timestamp in the picker (observed stuck at "1h ago" across a ~20+ minute window of continuous activity), despite its .jsonl transcript file's size/mtime confirming it was being written to correctly and continuously in real time.

This is isolated specifically to the VS Code extension's own session-list/picker UI:

• The identical test (new session → message → close → reopen, including a full VS Code restart) performed in a plain local, non-network-backed folder persisted correctly with no issues.
• claude --continue and claude --resume <session-id> run from a terminal in the same mapped-drive workspace directory correctly resumed full session history — confirming the underlying transcript/resume mechanism is intact, and the failure is confined to the extension panel's own session discovery/display layer.
• The identical share accessed via its UNC path instead of the mapped drive letter does not exhibit this problem — sessions persist and resume normally there.

Likely relevant: Claude Code's session storage is keyed by a sanitized string derived from the literal working-directory path (~/.claude/projects/<sanitized-cwd>/...), and VS Code separately treats the UNC path and the mapped-drive-letter path as two distinct workspace identities (confirmed via distinct workspaceStorage/<hash>/workspace.json folder URIs — file://server/share/... vs file:///S:/... — each with its own state.vscdb). The bug appears to be in how the extension populates/reads its session list from this mapped-drive-specific workspace state, not in the underlying .jsonl persistence.

What Should Happen?

Sessions created and used in a workspace opened via a mapped network drive letter should persist and reappear in the session picker exactly as they do for a local folder or a UNC-path workspace — reflecting real-time activity and remaining accessible after closing/reopening the panel or restarting VS Code.

Error Messages/Logs

No error dialog or exception is shown — the session simply does not appear in the picker, or appears with stale metadata. No log output was captured for this (silent UI-state bug).

Steps to Reproduce

1. Map a network share to a drive letter: net use S: \\server\share /persistent:yes.
2. Open a VS Code workspace at S:\some-folder (a subfolder of the mapped share).
3. Start a new Claude Code session in the panel, send a message, receive a response.
4. Confirm a new <session-id>.jsonl file appears under ~/.claude/projects/<sanitized-S-drive-cwd>/ and is non-empty/correctly sized.
5. Close the session tab/panel, then reopen it from the session picker. Observe: the session does not appear, or appears empty/"Untitled" with no history, despite the intact .jsonl file on disk.
6. For an actively-used, longer-running session in the same workspace: observe the picker's "last accessed" timestamp for it does not update over time despite the file continuing to grow (confirmable via file size/mtime).
7. For comparison: repeat steps 2–5 with the workspace instead opened via the UNC path (\\server\share\some-folder) — sessions persist correctly. Also repeat with a workspace on a plain local folder — sessions persist correctly there too, including across a full VS Code restart.
8. For comparison: from a terminal, cd S:\some-folder and run claude --resume <session-id> for the "lost" session from step 5 — this correctly resumes full history, confirming the transcript data itself was never lost.

Claude Model

Sonnet (default)

Is this a regression?

I don't know

Last Working Version

_No response_

Claude Code Version

2.1.217 (Claude Code)

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

VS Code integrated terminal

Additional Information

VS Code version:

Version: 1.129.1
Commit: 8a7abeba6e03ea3af87bfbce9a1b7e48fed567b8
Date: 2026-07-17T15:35:09Z
Electron: 42.6.0
ElectronBuildId: 14623276
Chromium: 148.0.7778.280
Node.js: 24.18.0
V8: 14.8.178.38-electron.0
OS: Windows_NT x64 10.0.26200

This is one of two related-but-distinct bugs found while working from a network-share-backed workspace — filed separately per the reporting guidelines. The other (permission allowlist / acceptEdits ignored on UNC-path workspaces) is filed as a separate issue. Mapping the share to a drive letter is the workaround for that issue, but as this report shows, it trades one problem for the other — there is currently no configuration that avoids both simultaneously for a network-share-backed workspace.

Unrelated but co-occurring during investigation: a Windows kernel bugcheck (0x00000023) and system restart happened while this was being diagnosed, alongside intermittent local-network/Kerberos authentication errors on the machine. No causal link to this specific bug has been established, and it is not believed to be required to reproduce the above — flagging only for completeness in case it's relevant context.