VS Code extension 2.1.226: worktree sessions unfindable in history search after reboot (+2 related)

Status Open

Reported on v2.1.226

Maintainer reply None cached

Activity 6 comments · opened Aug 10, 2026

Reporting three distinct, reproducible problems with session recovery in the Claude Code
VS Code extension. They surfaced together after an OS reboot left five previously-open
session tabs blank and unrecoverable through the UI. No data was actually lost — every
transcript was intact on disk — but none of the affected sessions could be found or
reopened through the extension's own history search.

(Paths and worktree names below are anonymized; they are incidental to the bug.)

Environment

Extension: anthropic.claude-code 2.1.226 (win32-x64)
Bundled CLI: 2.1.226
OS: Windows 11 Pro 10.0.26200
Workflow: 5–6 concurrent sessions against one repo, most isolated in git worktrees

under .claude/worktrees/

Date of incident: 2026-08-07 (reboot), diagnosed 2026-08-10

Issue 1 — Sessions run inside a git worktree are unfindable in history search

Sessions started in a git worktree do not appear in either the Local or Web history tab
when searching from the main repository workspace, even by exact title. The transcripts
exist and are complete on disk.

Cause appears to be project-path-hash scoping: a worktree's cwd hashes to its own
directory under ~/.claude/projects/, separate from the main repo's, and the picker does
not widen across them.

Example: worktree worktree-1, session 2028d658-... (redacted), stored
under C--Users-<user>-Documents-<repo>--claude-worktrees-worktree-1 rather than the main
project folder.

This is the most impactful of the three. For a worktree-heavy workflow it means
in-progress work becomes invisible after any reboot, and the only reliable recovery is
manually grepping .jsonl files.

Issue 2 — Web-tab resume attempts a fresh teleport instead of using the existing local session, and fails

For a session with Remote Control enabled, the cloud mirror survived the reboot and
remained fully readable in the Claude mobile app. Reopening that session from the
extension's Web history tab did not recognize that a complete local copy already existed.
It instead attempted a fresh teleport, which failed and left a dead stub:

{"type":"teleported-from","remoteSessionId":"session_01JXkh...","messageCount":0}

The panel then showed:

Error: Claude Code returned an error result: No conversation found with session ID: 4da1e5e4-...` (redacted

The stub file was created at click time, not at session time. The pre-existing local
session was 5bb26cfc-ee9d-4486-b77a-28461f91ce9b (worktree worktree-2) — confirmed to
be the same conversation by a word-for-word match of its final assistant message against
what the mobile app displayed.

Two requests: resume should prefer an existing local copy when one matches, and a failed
teleport should not leave a zero-message stub that subsequently errors on every open.

The full remote session ID is redacted here but available on request — happy to send it
privately to whoever picks this up, since it should let you trace the failed teleport
server-side.

Issue 3 — Ctrl+W closes the tab instead of widening resume scope

CLI documentation describes Ctrl+W during /resume as widening the picker scope to all
worktrees in the repository. Pressing it inside the extension's panel triggers VS Code's
own close-editor binding and closes the tab, losing the picker. This also removes the only
documented workaround for Issue 1.

Suggested priority

Issues 1 and 3 compound each other: worktree sessions are hidden by default, and the
documented way to reveal them closes the window. Fixing either alone would substantially
improve recovery.

Appendix — full session inventory

All sessions live under ~/.claude/projects/<project-path-hash>/<session-id>.jsonl.
Every transcript below was verified present and complete on disk.

The split is the point: every session run in a worktree was unfindable; every session
run in the main tree was findable. Same machine, same reboot, same history search.

Not findable in history search (all worktree-scoped)

| Worktree | Session ID |
|---|---|
| worktree-1 | 2028d658-... (redacted) |
| worktree-2 | 5bb26cfc-... (redacted) |
| worktree-3 | bdb31635-... (redacted) |
| worktree-4 | 525a59f7-... (redacted) |
| worktree-5 | b2a46199-... (redacted) |

Their project-path hashes take the form
C--Users-<user>-Documents-<repo>--claude-worktrees-<worktree-name>.

Findable in history search (all main-tree)

| Description | Session ID |
|---|---|
| Main-tree session A | ada84ff8-... (redacted) |
| Main-tree session B | dcdea66c-... (redacted) |
| Main-tree session C | 59a549ed-... (redacted) |

Project-path hash c--Users-<user>-Documents-<repo>.

Issue 2 artifacts

| Role | ID |
|---|---|
| Remote/cloud session (still readable in mobile app) | session_01JXkh... (redacted) |
| Zero-message stub created by the failed teleport | 4da1e5e4-9b36... (redacted) |
| Pre-existing complete local copy of the same conversation | 5bb26cfc-... (redacted) |

The stub was written into the main-tree project folder at click time, while the
complete local copy of the same conversation sat in the worktree folder — which may be
why the existing copy was not matched before attempting the teleport.

View original on GitHub ↗

3 Comments

robster7674 · 15 days ago

Hit the same pattern independently, on a different platform and a different trigger — thought it'd be useful corroboration since your report is otherwise unanswered.

Environment

Extension anthropic.claude-code 2.1.226, Linux, VSCodium via Remote-SSH (server-mode install)
Same workflow shape: several concurrent windows/tabs against one repo, some cwd'd into .claude/worktrees/<name>/, most in the plain repo root

Trigger: not a reboot — a routine Remote-SSH reconnect. The client's SSH connection to the box goes silent for a while (confirmed via journalctl: a run of periodic reconnects, then a multi-hour gap with zero reconnect attempts, then reconnect) and every extension-hosted window relaunches its backend processes on the next connect.

What happened: the tab that had been cwd'd into a worktree came back as a brand-new, empty session silently rooted at the main repo path — not an error, not "session not found," just a fresh conversation in place of the old one, as if nothing had ever been there. No crash, no OOM, nothing in the kernel/system journal for that window — ruled that out explicitly before landing on this.

Confirming your "the split is the point" finding, with numbers: on this box there are 18 worktree-scoped session directories total, spread across 3 different repos (~/.claude/projects/*--claude-worktrees-*). Every single one is stale — none has any activity on the day of/after its owning tab's last reconnect. Meanwhile every currently-running claude process right now is cwd'd into a plain repo root, none into a worktree. Same as your appendix table, just a bigger sample and a different OS/trigger — so this isn't reboot-specific or Windows-specific.

The underlying session-directory-is-cwd-scoped mechanism this traces back to looks like #5768. #28769 fixed the CLI's own resume-hint text to include --worktree <name> (v2.1.101), but that only helps the manual claude --resume path — it doesn't touch the VS Code/VSCodium extension silently respawning a tab on reconnect, which is what actually happened here.

Happy to share raw session IDs / directory listings if useful for repro.

robster7674 · 14 days ago

Follow-up from the same reporter — this recurred again today (2026-08-16), with a new twist: it hit a plain repo-root session this time, not a worktree-cwd one, so this isn't exclusively a worktree issue as I first thought.

Also captured, for the first time, direct proof the backend process isn't crashing:

The vanished session's backing claude CLI process was confirmed still alive (17h+ uptime) with its control socket in LISTEN state (ss -xlp / lsof -U) at investigation time — i.e. genuinely reconnectable, not dead.
Its transcript ends cleanly (stop_reason: end_turn, normal index markers) — not a mid-generation kill.
No correlated SSH/network disconnect this time — the tab got silently replaced by a fresh empty session while the connection was otherwise fine, ruling out a network-drop trigger for at least this occurrence.

This points more specifically at the extension's own tab-reattachment logic: on relaunch it isn't finding the still-live backend process for a given tab and spins up a new one instead — independent of cwd type (worktree vs plain) and independent of any network blip.

BasedGPT · 13 days ago

Hey Dleisterlifeloop,

The worktree sessions are still on disk; VS Code is looking in the main-repository session scope while those transcripts live under separate project-path directories.

I built BasedGPT/claude-code-session-recovery for this VS Code session-list case. From the toolkit checkout, run:

python tools/diagnose.py

Follow the exact command it prints. If it routes to recover_vscode_sessions.py, run the printed dry-run command first and review which complete transcripts it would add to the VS Code cache.

Close VS Code fully before applying the cache repair, then restart it. Keep the main-repository and worktree project directories separate: the follow-up report also shows a tab-reattachment failure that can create a fresh session at the repository root, which is a different problem from a missing cache entry.

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

Showing cached comments. Read the full discussion on GitHub ↗