VS Code extension: sessions relocated into .claude/worktrees project dirs vanish from history after a reload

Confirming this still reproduces on a newer version — adding a data point since it seems to affect more than just the EnterWorktree-relocated case described above.

Versions: VS Code extension v2.1.270, standalone CLI auto-updated v2.1.210 → v2.1.273 during troubleshooting. Session data last written at v2.1.266.

Setup: Workspace folder is a git worktree (git worktree list confirms it as a linked worktree of a separate main checkout), on branch feat/engine. Workspace path contains non-ASCII characters (Hebrew username segment), e.g. C:\Users\<Hebrew>\...\wt-engine.

Symptom: The VS Code sidebar history panel shows zero sessions for this project — not just one relocated session, but the entire history is empty/unreachable. Developer: Reload Window does not fix it.

Confirmed not a data-loss or sync issue:

The .jsonl transcripts are fully intact under ~/.claude/projects/<sanitized-path>/.
claude --resume (external terminal, same directory) correctly lists and loads the missing sessions by ID.
The same conversation is also correctly accessible via claude.ai web — verified the local .jsonl contains a consistent bridgeSessionId throughout, confirming successful cloud sync.
So the defect is isolated specifically to the VS Code extension's own local session-discovery/listing logic — it's not scanning/matching the on-disk project directory correctly for a worktree workspace, while the CLI picker (which sweeps multiple project-dir variants) and the cloud sync path both handle it fine.

Also noticed the extension's own environment metadata reported to the session flip-flopped between treating the workspace as C: vs c: (drive letter casing) and as "is a git worktree" / "is not a git worktree" across consecutive turns of the same session — suggesting inconsistent path normalization/caching is a likely root cause, matching what's described in #78466.

Happy to share the exact session ID / directory listing if useful for repro.

The transcript has moved under the --claude-worktrees-... project slug, so the conversation is still on disk and claude --resume can reach it. The empty VS Code tab is the extension's session-list projection missing that second slug after reload.

I built BasedGPT/claude-code-session-recovery for this retained-transcript gap. From the checkout, run:

python3 tools/diagnose.py

Follow the command it prints. If it routes to recover_vscode_sessions.py, review the dry run and pass the Flatpak ~/.claude/projects/ and workspace-storage roots if the diagnostic asks for explicit paths. The current public toolkit is tested on Windows and macOS, so treat Linux/Flatpak path discovery as a check rather than assume the cache write is portable. Keep the JSONL files and state.vscdb backed up, and fully close VS Code before any --apply.

Run claude --resume for one of the missing IDs from the repository root, then compare the project slug reported by the diagnosis with the worktree slug. If those match and the panel remains empty, the failure stays in the extension's listing logic; the toolkit can rebuild retained cache entries but it will not change the extension's worktree-union behaviour.

Hope this helps, if my tools are able to help you, would appreciate a ⭐ :)

Hey rel470,

The intact .jsonl files and a working claude --resume list point to a VS Code listing problem rather than missing conversation data. The non-ASCII profile segment and the drive-letter case flip are plausible path-normalisation triggers for the extension deriving a different project key for the worktree.

I built BasedGPT/claude-code-session-recovery for this retained-transcript gap. From the toolkit checkout on Windows, run:

python tools/diagnose.py

Follow the command it prints. If it routes to recover_vscode_sessions.py, use the dry run to compare the project slug in the VS Code cache with the directory containing the transcripts. Fix that path form first: an injected cache entry can be overwritten while the extension is still resolving the other slug. Keep a copy of the transcript and VS Code workspace-storage directories, and fully quit VS Code before any --apply.

The CLI and web checks are useful confirmation that the files and cloud bridge are intact. If the diagnosis still shows a retained-transcript/listing gap after the path forms agree, the cache route can restore entries for the existing files but it will not change the extension's path-normalisation behaviour.

Hope this helps, if my tools are able to help you, would appreciate a ⭐ :)

Same here on Windows 11, extension 2.1.273.

Two sessions started in the main checkout, moved via EnterWorktree (transcripts now under ~/.claude/projects/<slug>--claude-worktrees-<name>/, worktrees still present in git worktree list). Visible in the sidebar while open; after a window reload the extension log shows update_panel_host_session {kind: "restore_declined"} for both and they're gone from the list. claude --resume <id> from the worktree still works.

Workaround (confirmed on Windows, 2.1.273): open the parent folder of the repo as the VS Code workspace instead of the repo itself.

When the workspace root is the git repo, EnterWorktree relocates the transcript to <slug>--claude-worktrees-<name>/ (a relocated record is written) and the sidebar loses it after reload. When the workspace root is a plain non-git parent folder containing the repo, the worktree still gets created under <repo>/.claude/worktrees/<name> but the transcript stays in the workspace's own project dir (only a worktree-state record is written, no relocated) — so the sidebar keeps listing it across reloads.

Cost is an explorer root one level up and Claude starting in the parent cwd. Beats restoring sessions by ID from a terminal.