[BUG] History Sessions lost in Vscode plugin

Found 3 possible duplicate issues:

1. https://github.com/anthropics/claude-code/issues/8667
2. https://github.com/anthropics/claude-code/issues/3313
3. https://github.com/anthropics/claude-code/issues/8519

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

#8667 seems related, not sure if it is the same issue. no further solutions.

<img width="2142" height="706" alt="Image" src="https://github.com/user-attachments/assets/f5a3f0e1-e3ca-41af-bcd6-b6c8eac1476c" />

I have confirmed that this is an issue with the symbolic link. As shown in the image, my working directory ~/projects/dma-size/ is actually a symbolic link pointing to /mnt/projects/dma-size/. The plugin did not handle the symbolic link correctly and treated ~/projects/dma-size/ as the actual directory. However, the CLI and backend correctly used /mnt/projects/dma-size/.

when I use /mnt/projects/dma-size/ instead of ~/project/dma-size/ as vscode workspace path, all will be ok

<img width="565" height="428" alt="Image" src="https://github.com/user-attachments/assets/aa05e1aa-23e4-4740-94d7-b8305868906c" />

I have confirmed that this is an issue with the symbolic link. As shown in the image, my working directory ~/projects/dma-size/ is actually a symbolic link pointing to /mnt/projects/dma-size/. The plugin did not handle the symbolic link correctly and treated ~/projects/dma-size/ as the actual directory. However, the CLI and backend correctly used /mnt/projects/dma-size/.

This seems to be the correct fix for now. i was having the same issue, as my working folder was being opened via a symlink (~/repositories/project), but was able to resolve it by opening the working folder in vs code using its actual location (/mnt/data/repositories/project). This allowed me to regain access to the conversation history (and also fixed having to re-login to claude over and over again)

I take that back. Restoring sessions is completely unreliable, no matter if using a symbolic link path for project. Simply stopping and restarting vscode and I have no way to recover/resume my current session.

Serious issue

my pc sometimes crash or if pc is overall unexpectedly turned off ilose some history on some conversations i just see Warmup messages and claude dont remember any prevuious context then

I have had this issue since restarting VSCode too - no symlinks, and session history properly resumes in the CLI.

Hi I'm also having this issue,

I'm running vs code on macOS 15,
Claude Code Version: 2.0.30

Version: 1.105.1 (Universal)
Commit: 7d842fb85a0275a4a8e4d7e040d2625abbf7f084
Date: 2025-10-14T22:33:36.618Z
Electron: 37.6.0
ElectronBuildId: 12502201
Chromium: 138.0.7204.251
Node.js: 22.19.0
V8: 13.8.258.32-electron.0
OS: Darwin arm64 24.3.0

Is this a common issue?

I also have the issue, restarting new instance of VS Code Client (connect to Dev Container remotely), do not restore previous conversation.

VS Code Clouse Code Extention 2.0.31
Version: 1.105.1 (system setup)
Commit: 7d842fb85a0275a4a8e4d7e040d2625abbf7f084
Date: 2025-10-14T22:33:36.618Z
Electron: 37.6.0
ElectronBuildId: 12502201
Chromium: 138.0.7204.251
Node.js: 22.19.0
V8: 13.8.258.32-electron.0
OS: Windows_NT x64 10.0.26100

VS Code Client is on Windows 11. VS Code Server is on Container on Remote System running CentOS Stream 10 (CLI only) via Dev Container: Attach to running Container.

We have this bug, or a variant of it.

• Our org settings are in /etc/claude-code/manage-settings.json (see the "enterprise managed settings" documentation)
• When you run the VS Code extension, it writes history to /etc/claude-code/projects/. I'm not sure if this is intentional or not. It seems a little odd.
• If you close and resume with a new VS Code extension, it doesn't see that history
• The CLI with claude --resume _does_ see the history in /etc/claude-code/projects/
• If we do cp -R /etc/claude-code/projects ~/.claude/ to copy the history to ~/.claude/, and run the VS Code extension, it sees the history and you can resume the conversation.

The problem - for us anyway - is that the extension is _writing_ history to /etc/claude-code/projects/ but is not _reading_ history from that location.

Does anyway else have this variant of the problem?

i'm surprised there has been no response to this bug. it seems the problem is related to opening a folder/project in vscode via a symlink vs. opening it using the full (actual) path. (symlink: /home/user/repositories/project vs. path: /mnt/data/repositories/project)

using a symlink always results in lost conversation history. closing vs code, restarting vscode and cc extension will NOT find the previous conversation - there is no resume history.

whereas using the full path results in having a resume history.

please fix this.

I am having the same problem here. Is there any update on this

Hi Claude team! can you please fix this issue? it's seems like it's taking too long already still the issue persists.. This makes it very hard to iterate on the past conversations.. Thanks!

The 0 response fro the maintainer is disgustingly unprofessional!! Until now, 2 months after ticket is opened, this is still not even have any assignee. I started regretting using this tools.

This problem seems to be getting even worse with the new updates — can someone please help here? All my session history seems to now be lost

Ran into this problem. I use the VS Code extension on a project hosted on WSL.

Found this solution :

• Open the extensions logs by opening the command palette Ctrl+Shift+P then look for Claude Code: Show Logs.
• Inside the logs, look for Claude extension trying to open the related project, you will find the path it tries to open. Copy it.
• In your terminal, ls ~/.claude/projects, then find the folder with you project name (it should not be named differently from what Claude tries to open)
• Move this folder to the location you copied from the logs

Example :
In the logs, I found something like -home-me-myproject
In ~/.claude/projects, I found something like -mnt-d-debian-myproject
I mv ~/.claude/projects/-mnt-d-debian-myproject ~/.claude/projects/-home-me-myproject

After what, close you VS Code, then open it again code .. Conversations are back.

in my case it's because of the directory permission, the not working claude projects directory has 700 drwx------@
while the working claude projects directory has 755 drwxr-xr-x@

so changing the directory permission fix this problem in my case

I see several workarounds mentioned, but they all require terminal/manual steps.

The root cause is that history.jsonl exists but the UI doesn't persist it in the sidebar. I ran into this constantly and ended up building a VSCode extension that auto-syncs the JSONL files to a searchable sidebar:

https://marketplace.visualstudio.com/items?itemName=agsoft.claude-history-viewer

It works alongside the official extension - just reads the same files Claude Code writes to. Might save some folks the manual grep/jq workflow.

<img width="506" height="236" alt="Image" src="https://github.com/user-attachments/assets/4bdb81e0-da46-4843-87a2-e26c5305a27c" />

Same issue

This is a similar problem to #14088

I'm using vscodium in flatpak on ubuntu 25.10

lrwxrwxrwx 1 jk jk 14 Nov 15 11:15 /home/jk/NAME -> /mnt/@/NAME/

2026-01-07 11:28:42.900 [warning] Failed to load sessions from /home/jk/NAME/NAME-worker-js: Error: ENOENT: no such file or directory, scandir '/home/jk/.claude/projects/-home-jk-NAME-NAME-worker-js'

So when writing to .claude/projects the vscode extension uses the fully resolved absolute path of '/mnt/@/SUBVOLUME/..projects..'

But when attempting to load the same project it looks for the unresolved /home/USER/SYMLINK_TO_SUBVOLUME/... to look up the history and finds nothing.

This is a very simple bugfix - you must lookup data at the same place you decided to store it.

I had to beat claude up a bit before I could get it to see this error
I've spent 3 hours on it

after some more prompting, claude came up with this workaround:

#!/bin/bash
# Auto-sync Claude Code project directories for symlinked workspaces
# This handles the /home/jk/NAME -> /mnt/@/NAME symlink issue

PROJECTS_DIR="$HOME/.claude/projects"

# Find all -mnt---NAME-* directories
for mnt_dir in "$PROJECTS_DIR"/-mnt---NAME-*; do
    if [ -d "$mnt_dir" ]; then
        # Extract the project name after -mnt---NAME-
        basename=$(basename "$mnt_dir")
        project_name="${basename#-mnt---NAME-}"

        # Create corresponding -home-jk-NAME- symlink if it doesn't exist
        home_link="$PROJECTS_DIR/-home-jk-NAME-$project_name"

        if [ ! -e "$home_link" ]; then
            ln -s "$mnt_dir" "$home_link"
            echo "Created symlink: $home_link -> $mnt_dir"
        else
            echo "Already exists: $home_link"
        fi
    fi
done

echo "Done syncing project paths"

{
  "hooks": {
    "on_start": {
      "command": "$HOME/.claude/sync-project-paths.sh",
      "description": "Sync Claude Code project directory symlinks for /home/jk/SYMLINK -> /mnt/@/PROJECTS_SUBVOLUME"
    }
  }
}

I'm also experiencing this issue.

Environment:

• OS: Ubuntu (Linux 6.8.0-90-generic)
• VSCode: Remote SSH connection (vscode-server)
• Claude Code Extension: 2.0.75

Behavior:

• Sessions exist in ~/.claude/projects/<project>/ (52 .jsonl files with content)
• CLI claude --resume works correctly and shows all sessions
• VSCode sidebar "Past Conversations" panel is empty
• Reloading VSCode window doesn't help

Workaround: Using claude --resume <session-id> from external terminal.

This confirms the issue persists in the latest version (2.0.75) on Linux with SSH remote connections.

I am seeing this as well, on macOS 15.7 with extension version 2.1.3.

Changing the permissions fixed the problem for me: https://github.com/anthropics/claude-code/issues/9258#issuecomment-3652433013

in my case it's because of the directory permission, the not working claude projects directory has 700 drwx------@ while the working claude projects directory has 755 drwxr-xr-x@ so changing the directory permission fix this problem in my case

Same issue, root cause and fix here:
MacOs Sonoma 14.8.1, VSCode 1.107.1, claude code extension 2.1.7
Doing chmod 755 ~/.claude/projects/* made previous chats show up again.

Solucionado:
1) abrir Git bash.
2) Ir a la carpeta .claude
3) Colocar: chmod -R 755 ~/.claude/projects/*
4) Reiniciar IDE, en mi caso, Antigravity.
5) ¡El historial ya apareció!

Regarding the Claude Code extension for VS Code on Windows, I discovered that the existence of the .claude folder within the project was the root cause of Claude failing to locate the root directory. After deleting the .claude folder from the project, the issue was resolved.

<img width="408" height="224" alt="Image" src="https://github.com/user-attachments/assets/87c8619b-072f-4b60-bbb2-ebd907c52f67" />

This keeps happening and it is genuinely painful. You build up hours of context with Claude, then poof — the history is gone after an update or extension restart.

The root cause is that the VS Code extension manages session state differently from the CLI, and updates can sometimes disrupt the local storage.

A few things that help:

1. Regularly use /resume from the CLI to verify your sessions are accessible outside the extension
2. Keep your CLAUDE.md updated so critical context survives session loss
3. Use Mantra as a safety net — it watches your Claude Code session files independently and maintains its own index. Even if the VS Code extension loses track of sessions, Mantra still has the full history browsable and searchable.

Losing session history should never happen, but until it is fixed, having an external backup of your session state is worth the peace of mind.

I asked Claude to dig into this issue.

TLDR: the vscode plugin reads only the first 64KB of each .jsonl conversation file to find a summary. If your first message is of large size (or has embedded images like in my case), it can easily pass the 64kb limit. When that happens, the plugin can't parse the message and silently hides the conversation from the list. Forked conversations inherit the same problem since they copy the full history. However the conversations still exist (you can access them through command line).

Quick workaround: you can ask Claude Code itself to shrink the embedded images in the .jsonl files. You lose the original screenshots but all text and conversation history is preserved, and the conversations show up in the plugin again.

Root cause found for a significant portion of "sessions lost" reports

I've done a deep-dive into the VS Code extension source code and found a concrete, reproducible bug that causes sessions to silently disappear from the "Past Conversations" list. This likely explains many of the reports in this thread.

Affected version: Claude Code VS Code Extension v2.1.63 (latest, darwin-arm64)

The bug: 64KB head buffer truncation in fetchSessions()

The fetchSessions() method in extension.js reads each .jsonl session file to extract a title for the session list. It reads only the first 64KB (fK = 65536) and last 64KB of each file:

var fK = 65536;
async function FW(z) {
    let v = Buffer.allocUnsafe(fK);
    await U.read(v, 0, fK, 0);  // only first 64KB
    // ...
}

It then tries to extract a session title from three sources:

let q = uK(tail, "customTitle") || uK(tail, "summary") || LW(head);
if (!q) return null;  // session silently dropped

The problem: The VS Code extension itself injects large IDE context into the first user message — <ide_opened_file>, <ide_selection>, <system-reminder>, CLAUDE.md contents, auto-memory files. This routinely makes the first type:"user" JSON line 100KB–1MB+, far exceeding the 64KB buffer. LW() receives truncated JSON, JSON.parse() fails silently, and the session becomes permanently invisible.

Evidence: 7 sessions affected in one project

| First user line size | Visible in UI? | Content type |
|---|---|---|
| 1,008 KB | ❌ Hidden | IDE context + user text |
| 372 KB | ❌ Hidden | IDE context + user text |
| 114 KB | ❌ Hidden | IDE context + user text |
| 65–400 KB (×4) | ❌ Hidden | IDE context + user text |

No images attached. The inflation comes entirely from the extension's own context injection. Simply having a few files open in the IDE + CLAUDE.md + auto-memory is enough to exceed 64KB.

History of this bug

This is actually the third iteration of the same class of bug:

| Version | Buffer | Fix | Path |
|---|---|---|---|
| < v2.1.47 | 16KB | Fixed by @ashwin-ant (b757fc9) | CLI /resume |
| v2.1.47+ | 64KB | ← current | CLI /resume |
| All versions | 64KB | ⚠️ Never fixed | VS Code extension fetchSessions() |

The v2.1.47 fix increased the CLI buffer from 16KB to 64KB, but the VS Code extension already had 64KB and was never addressed. The extension's first messages are inherently larger than CLI's (due to IDE context injection), making this a more severe issue.

Suggested fix

Write a small metadata line early in the .jsonl (2nd–3rd line, after queue-operation):

{"type":"session-meta","summary":"First 200 chars of user prompt...","created":"..."}

This guarantees LW() always finds parseable content within 64KB, regardless of message size. Minimal change, no buffer increase needed.

Current workaround

Manually append to the tail of the .jsonl:

{"type":"summary","summary":"Description","leafUuid":"<last-uuid>"}

This works via uK(tail, "summary"), but is fragile — the extension keeps appending data that can push the summary outside the 64KB tail window.

Related issues

• #29088 — same root cause (64KB buffer), reported with images
• #26140, #25920, #25721 — the 16KB variant, fixed in v2.1.47
• #22215 — different bug (cross-project cache contamination)

---

@ashwin-ant The 16KB→64KB fix in v2.1.47 resolved the CLI path but didn't touch the VS Code extension's FW() / fetchSessions(). The extension's own IDE context injection makes the first user line routinely exceed 64KB — no images needed. Still present in v2.1.63.

@hackyon-anthropic This is in extension.js — fK = 65536 constant. The most robust fix would be writing a lightweight metadata header early in the .jsonl rather than increasing the buffer.

cc @chrislloyd @vbhavsar

Still experiencing this on macOS (Darwin 25.3.0), VSCode 1.109.5, Claude Code 2.1.50 (VSCode extension with UI, not terminal).

What happens: During a lengthy conversation, if I accidentally close the chat tab and reopen it from the conversation dropdown, the conversation loads in a much older state -- missing a significant portion of recent messages. The experience is inconsistent: sometimes it recovers partially, sometimes it reverts far back.

Key detail: The .jsonl session files appear intact on disk, so this seems like a UI persistence/deserialization issue rather than data loss.

There are at least 5 open duplicates of this (#12872, #12908, #12114, #29017, #29736) spanning 3+ months with no maintainer response on any of them. This is clearly a widespread, reproducible issue affecting users across all platforms. Would appreciate this getting triaged and assigned.

cc @OctavianGuzu @chrislloyd

Experiencing the same issue on Windows 11 + VS Code extension. 30+ conversation JSONL files present on disk under ~/.claude/projects/ but the dropdown shows zero history. Was working fine until ~a week ago. Extension version 2.0.12.

FIX IT! If claude didn't crash continuously and you had to restart VS Code, it wasn't a problem, but it crashes, doesn't finish tasks and loses the context and doesn't even read the history even if it EXISTS in .claude/Projects.

I have stopped using VSCode entirely because of this bug. It's simply not reliable and you WILL loose work

Same issue, please fix it ASAP

Same issue - its appalling nothing has been fixed here

I'm on windows 11 + WSL2 and from time to time, when i reload/close+reopen the vs code, my last conversation that i was having with claude dissapears from the session history dropdown... ;/

The issue still persists in the latest Claude Code for VS Code release (version 2.1.86).
I am working across multiple machines running Windows 11 and have not been able to resume any of my coding sessions for several months.
Unless users work continuously on the same project without interruption or PC restart, the inability to resume sessions represents a major limitation. This should be treated as a critical bug and addressed as soon as possible!

If your VS Code workspace is located on a mapped network drive under Windows 11, you may want to try the workaround in #38186
It worked for me.

I've mapped 12 root causes and built a repair toolkit. Who else is working on this?

I've been running ~320 sessions over 3 weeks on a production documentation project. The session management failures cost me irreversible data loss, dozens of hours of manual repair, and forced me to build an entire infrastructure layer just to keep working.

I'm sharing everything I've found because Anthropic clearly isn't fixing this. Zero staff responses on any session management issue. Zero. The bot closes duplicates which fragments engagement below triage thresholds. So let's help each other.

What I've confirmed (12 root causes, verified in extension.js)

| # | What's broken | Why it matters |
|---|---|---|
| 1 | sessions-index.json stopped being written (~v2.1.31) | Session discovery falls back to filesystem scan, which is flaky |
| 2 | fetchSessions() reads only first/last 64KB of each JSONL | Sessions >128KB are silently dropped. My sessions go up to 57MB. |
| 3 | Cross-project cache contamination | Opening another workspace can corrupt your session list |
| 5 | CLI deletes session files on auto-update | Irrecoverable data loss. Set cleanupPeriodDays: 99999 NOW if you haven't. |
| 6 | No sort in broadcastSessionStates() | Sidebar order is Map insertion order, not chronological |
| 9 | deserializeWebviewPanel passes void 0 | Tab restore after crash shows blank because session ID is lost |
| 11 | state.cache wiped to [] on crash | Extension can list sessions but can't load any of them |
| 12 | Bulk lastRequestEnded timestamp stamping on every load | Every restart destroys your sidebar ordering. All sessions get the same timestamp. |

(Full list of all 12 with evidence in the linked diagnostic below.)

What I built to work around it

Fix scripts (bash, macOS, should be adaptable):

• patch-extension.sh — auto-finds active extension version, patches buffer 64KB→512KB. Must re-run after every extension update.
• recover-dropped-sessions.sh — finds sessions on disk that are missing from the sidebar, injects them into the cache
• sort-sessions.sh — re-sorts model.cache by created date (extension overwrites this on next load, but at least it's correct until then)
• fix-titles.sh — resolves UUID-only labels from JSONL custom-title entries
• fix-title-overwrite.sh — detects last-prompt pushing custom-title outside the tail read window, re-appends it. Run on a 2-minute timer via launchd.
• full-repair.sh — runs everything in sequence (--dry-run first)
• com.alison.claude-backup.plist — launchd agent for 30-minute automatic state.vscdb snapshots

Hook-based guardrails (because Claude itself also causes data loss):

• Pre-edit context gate — blocks Claude from editing files it hasn't read
• Session collision detection — warns when parallel sessions are touching the same files
• Circuit breaker — stops Claude after 3 consecutive failures instead of letting it dig deeper
• PreCompact checkpoint — writes structured checkpoint before context compaction in long sessions

What I still can't fix

• Bulk timestamp reset on load (root cause #12) — no user-side fix. Every restart scrambles your sidebar.
• No folders, no custom ordering, no pinning — the sidebar is a flat list sorted by a timestamp that gets destroyed on every load. No extension I've found solves this.
• Patches die on every extension update — there's no hook to auto-re-apply them.
• sessions-index.json not written — needs an Anthropic code change.

What I want to know from you

1. Has anyone found a way to prevent the bulk timestamp reset? This is the most destructive daily annoyance.
2. Is anyone auto-re-applying patches after extension updates? I'm running the patch manually after each update. There must be a better way.
3. Does anyone have session folders or custom ordering working? I've tried 4 extensions, none do it.
4. What community tools am I missing? I'm using ccmanager, claude-history-viewer, mcp-claude-context-continuity. What else exists?

Happy to publish the full toolkit as a standalone repo if people want to use and contribute to it. Right now it lives in my working project.

The canonical diagnostic (283 lines, architecture diagram, all 12 root causes with evidence, hackable paths, full script reference) is available if anyone wants it — just reply here.

Disclosure: The above comment was co-written with Claude Code (the product being complained about). The root cause analysis, fix scripts, and hook system were built collaboratively across ~320 sessions. The irony is not lost on me.

Update: I've published the full toolkit as an open repo:

DeveloperAlly/claude-code-survival-toolkit

9 fix scripts, 7 governance hooks, full canonical diagnostic (283 lines with architecture diagram), and a community research doc cataloguing 82 data-loss issues, 50+ session issues, every third-party tool and workaround I could find.

Everything is documented with usage instructions. Scripts are bash/macOS but should be adaptable. Hooks are Node.js, zero LLM cost.

If you're dealing with any of this, please:

• :+1: this issue to get it above triage threshold
• Star the repo if the tools help you
• Open issues/PRs on the repo with your own workarounds, root causes, or platform adaptations (Linux/Windows especially)
• Share any tools or approaches I've missed

We shouldn't have to build this. But here we are. Let's at least share the work.

Windows 11 users with VS Code workspaces on mapped network drives: You can use the workaround in #38186 while waiting for an official fix from Anthropic.

Now, after I start a new session:

1. Go to the %USERPROFILE%\.claude\projects folder and find the project I'm currently working on.
2. In the project folder, sort by date and open the .jsonl file with the newest date.
3. In the .jsonl file, search for aiTitle and change the name to the one I want.

!Image

Restoring Last Session History

Just wanted to post what's been working for me to resume lost context in VSCode Chat Window.

Session History Directory

1. Navigate to %USERPROFILE%\.claude\projects
2. Sessions History files are named d942463c-bb6e-435d-b821-610e5bae6110.jsonl
3. Discover which file is the last Session by using the file system to sort files by Date Modified


Resuming a Session with Context

1. In VS Code, Select desired file first! Browse to and double-click to select index.html


1. Paste the following prompt at the start of a new conversation:

Resume from: C:\Users\user1\.claude\projects\d--\<session-id>.jsonl
Working directory: D:\nginx\var\www\example.com\public\gui\v1

Why both matter:

• The .jsonl path → restores conversation history and what was done
• The working directory → tells claude where the actual project files are so you can read/edit them without guessing

Optional but helpful: Open a key project file in the IDE (like index.html) before sending — it appears in claude's context automatically as ide_opened_file.

I threw Claude at this and sorted out a fix by patching the vs code extension JS. Works for me on Windows 11, hopefully it works for others.

It adds a fallback path for history/session loading:

• If the extension’s normal session index returns nothing, it reads session .jsonl files directly from ~/.claude/projects/<mapped-cwd>/.
• If opening a specific session returns empty, it directly loads <sessionId>.jsonl.
• It restores list titles from ai-title records (or first user text).
• It filters loaded records to message types the UI can render.

Patch file:
~/.vscode/extensions/anthropic.claude-code-2.1.101-win32-x64/extension.js

Replace the entire listSessions() method with:

async listSessions(){let K=this.cwd,V=await zd({dir:K,includeWorktrees:!1});if(V.length===0&&typeof K==="string"&&/^[a-z]:\\/.test(K)){let q=K[0].toUpperCase()+K.slice(1);if(q!==K){let z=await zd({dir:q,includeWorktrees:!1});z.length>0&&(this.logger.warn(`listSessions path-case fallback: ${K} -> ${q} (${z.length} sessions)`),K=q,V=z)}}let B=await g1.readTeleportMetadata(K,V.map((H)=>H.sessionId)),j=V.map((H)=>{let N=B.get(H.sessionId);return{id:H.sessionId,lastModified:H.lastModified,fileSize:H.fileSize,summary:H.summary,gitBranch:H.gitBranch,worktree:UR4(H.cwd),isCurrentWorkspace:!0,...N}});if(j.length===0)try{let q=require("os"),z=require("path"),U=require("fs"),Z=typeof K==="string"?K.replace(/[\\/:]/g,"-"):String(K),D=z.join(q.homedir(),".claude","projects"),L=z.join(D,Z),O=U.existsSync(L)?U.readdirSync(L).filter((F)=>F.endsWith(".jsonl")):[],N=O.map((F)=>{let M=z.join(L,F),A=U.statSync(M),w=F.replace(/\.jsonl$/,""),I=B.get(w),R=I?.summary;if(!R)try{let E=U.readFileSync(M,"utf8").split(/\r?\n/).filter((P)=>P.trim().length>0);for(let P of E){let T;try{T=JSON.parse(P)}catch{continue}if(T?.type==="ai-title"&&typeof T.aiTitle==="string"&&T.aiTitle.trim()){R=T.aiTitle.trim();break}if(!R&&T?.type==="user"){let h=T?.message?.content;if(Array.isArray(h)){let C=h.find((c)=>c?.type==="text"&&typeof c.text==="string"&&c.text.trim());if(C){R=C.text.trim(),R.length>70&&(R=R.slice(0,67)+"...")}}}}}catch{}return{id:w,lastModified:A.mtimeMs,fileSize:A.size,summary:R||w,gitBranch:I?.gitBranch,worktree:I?.worktree,isCurrentWorkspace:!0,...I}}),x=U.existsSync(L)?O.length:-1,G=U.existsSync(D)?U.readdirSync(D,{withFileTypes:!0}).filter((F)=>F.isDirectory()).map((F)=>F.name).slice(0,30):[];this.logger.warn(`listSessions debug cwd=${K} key=${Z} projectDir=${L} projectJsonl=${x} projectsRoot=${D} knownProjectDirs=${G.join(",")}`),N.length>0&&(this.logger.warn(`listSessions file fallback used: ${N.length} sessions from ${L}`),j=N)}catch(q){this.logger.warn(`listSessions debug failed: ${q}`)}ja(j);let Y=new Set(this.settings.getHiddenSessionIds()),X=Y.size>0?j.filter((H)=>!Y.has(H.id)):j;return X.length===0&&j.length>0&&(this.logger.warn(`listSessions fallback: hidden filter removed all sessions (cwd=${K}, total=${j.length}, hidden=${Y.size})`),X=j),this.logger.log(`listSessions cwd=${K} total=${j.length} hidden=${Y.size} returned=${X.length}`),{type:"list_sessions_response",sessions:X}}

Replace the entire getSession(K) method with:

async getSession(K){let V=this.cwd,B;try{B=await Ld(K,{dir:V})}catch(j){if(typeof V==="string"&&/^[a-z]:\\/.test(V)){let Y=V[0].toUpperCase()+V.slice(1);if(Y!==V)try{B=await Ld(K,{dir:Y}),this.logger.warn(`getSession path-case fallback: ${V} -> ${Y} (session=${K})`),V=Y}catch{}}if(!B)try{let Y=require("os"),X=require("path"),Q=require("fs"),G=(typeof V==="string"?V:String(V)).replace(/[\\/:]/g,"-"),q=X.join(Y.homedir(),".claude","projects",G,`${K}.jsonl`);if(Q.existsSync(q)){let z=Q.readFileSync(q,"utf8").split(/\r?\n/).filter((U)=>U.trim().length>0);B=[];for(let U of z)try{B.push(JSON.parse(U))}catch{}this.logger.warn(`getSession file fallback used: session=${K} file=${q} raw=${B.length}`)}}catch{}if(!B)throw j}if(!B||B.length===0)try{let Y=require("os"),X=require("path"),Q=require("fs"),G=(typeof V==="string"?V:String(V)).replace(/[\\/:]/g,"-"),q=X.join(Y.homedir(),".claude","projects",G,`${K}.jsonl`);if(Q.existsSync(q)){let z=Q.readFileSync(q,"utf8").split(/\r?\n/).filter((U)=>U.trim().length>0),U=[];for(let Z of z)try{U.push(JSON.parse(Z))}catch{}if(U.length>0)B=U,this.logger.warn(`getSession empty->file fallback used: session=${K} file=${q} raw=${B.length}`)}}catch{}let j;try{j=await(await g1.load(V,this.logger)).getSessionDiffs(K,V,B||[])}catch{j=void 0}let Y=(B||[]).filter((H)=>H?.type==="user"||H?.type==="assistant"||H?.type==="system"||H?.type==="meta"||H?.type==="compact");return this.logger.log(`getSession id=${K} raw=${(B||[]).length} filtered=${Y.length} cwd=${V}`),{type:"get_session_response",messages:Y,sessionDiffs:j}}

Then run:

• Developer: Reload Window or restart VS Code

@DeveloperAlly — your toolkit is pretty impressive, and the root-cause table is pretty damn informative. Answering your "what community tools am I missing?" question with one:

https://github.com/garrettmoss/restore-claude-history — pulls deleted JSONLs back out of macOS Time Machine snapshots.

This specifically addresses your root cause #5 ("CLI deletes session files on auto-update — irrecoverable data loss"): if the user had Time Machine running before the deletion, it's not irrecoverable. Mounts every TM snapshot, picks the largest version of each JSONL across snapshots, restores with mtime preserved and ACLs stripped. It complements your backup-vscode-state.sh / restore-vscode-state.sh pair, which (correctly) only restore from backups you took before the loss — mine catches the case where the user wasn't running your toolkit yet.

Caveats:

• macOS + Time Machine only. No help on Linux/Windows or if TM wasn't running.
• Recovers the on-disk JSONLs only. Your toolkit's recover-dropped-sessions.sh is the right next step if the sidebar still doesn't see the restored files.

Also filed issue #62272 on the cleanupPeriodDays bypass paths (subagents, SDK sessions), with three concrete asks. Folded into the dup-bot cluster of course, but kept open with a comment as a consolidated tracker.

Cross-linking your toolkit in my README's "See also" section now. Happy to coordinate further if useful — there's a real complementary stack forming between your in-app repair work, (and a few other people's repos that I link/mention in that README).

Hope this helps.

Thanks for the addition!

Are there any plans on fixing this critical bug?..
I use it all the time in GitHub Copilot Chat in VS Code (which also lets you rename, pin and archive sessions, show them on the side so it's easy to run a few things in parallel, see status and preview in a tooltip).