VS Code extension: past conversation tabs show titles but empty content / no context on reopen (Windows, mapped network drive)

Summary

On reopening VS Code, past Claude Code conversation tabs reappear in the sidebar with their correct titles, but opening any tab shows an empty conversation body with no preserved context — the assistant doesn't know what was discussed. The session .jsonl files on disk contain complete, intact transcripts (titles, user messages, assistant messages). The extension is reading enough of the file to populate the tab title, but failing to load the message bodies. Restarting VS Code reliably reproduces this. The same workspace re-created on a local drive does not exhibit the bug.

Environment

• Extension version: 2.1.145
• OS: Windows 11 Pro 10.0.26200
• Broken workspace location: a mapped network drive (S:)
• Working comparison: same machine, C:\Temp\Test
• Shell: PowerShell

Reproduction

1. Open a VS Code workspace rooted on a Windows mapped/network drive.
2. Have one or more Claude Code conversations.
3. Close and reopen VS Code.
4. Past conversation tabs reappear in the sidebar with their original titles.
5. Expected: clicking a tab restores the full conversation history and context.
6. Actual: the tab opens with an empty body; the assistant has no memory of prior turns.

Evidence the data is intact

For a broken workspace, %USERPROFILE%\.claude\projects\<project-hash>\ contains multiple *.jsonl files of substantial size (tens to hundreds of KB). Inspecting one file:

"type":"ai-title" entries  → present, correct title (this is what the tab shows)
"type":"user" entries      → 10 entries with full message content
"type":"assistant" entries → 18 entries with full message content

Plus queue-operation, attachment, last-prompt, file-history-snapshot, todo_reminder, deferred_tools_delta, skill_listing, tool_use, tool_result, and thinking entries — none of which appear to be loaded into the restored tab.

Related symptom

/resume in the Claude Code panel also shows an empty session list for the broken workspace. This may be the same root cause manifesting in a second UI surface, or a separate bug.

Ruling out other variables

• Not version/install state: the same extension on the same machine with the same user profile works correctly for a workspace at C:\Temp\Test.
• Not spaces in the path: a test workspace at C:\Temp\Test Folder With Spaces works fine.
• Not missing files / not a hash mismatch: the <project-hash> folder is present and contains the expected *.jsonl files with real conversation content.
• Not just an indexing race: the bug persists across many minutes after VS Code launch; it's not a "wait for files to load" issue.

Likely culprits

The differentiating factor is the drive type. Plausible root causes:

• fs.watch (or chokidar wrapping it) silently failing on SMB / mapped network volumes on Windows, leaving message-body data unloaded.
• Path canonicalization mismatch where the save path uses the drive letter (S:\...) but the load path canonicalizes to a UNC form (\\server\share\...), causing the body-loader to look in a non-existent location.
• An asynchronous load step (loading message bodies after rendering the tab shell) silently erroring on network-FS read latency or locking semantics.

Impact

Users with workspaces on network drives — common in environments with centralized backup — lose access to all prior conversation context every time VS Code restarts. Tabs misleadingly appear to be restored but contain nothing, so the data loss is invisible until the user clicks in.

Workaround

None known within the panel UI.