Session transcripts and scratchpad folders are never cleaned up on disk; VS Code extension writes to a separate, one-directionally-synced session index

Environment

• OS: Windows 11 Pro
• Claude Code version: 1.40609.0 (f65e38), built 2026-08-27T16:19:51.000Z
• Frontends involved: Claude Code (this app/CLI) and the VS Code extension
• Session transcript storage: ~/.claude/projects/<project-path>/*.jsonl
• Session scratchpad storage: %TEMP%\claude\<project-path>\<session-uuid>\

Summary

Three related symptoms of the same root cause — no session-teardown cleanup on either frontend — found while investigating why ~/.claude/projects/ had accumulated ~300 MB of session transcripts despite regularly deleting sessions from both the VS Code extension and this app:

1. Session index sync between the VS Code extension and this app is one-directional. Sessions created in this app appear in VS Code's session list. Sessions created in the VS Code extension never appear in this app's session list/explorer.
2. Deleting a session, from either side, never deletes its underlying .jsonl transcript file. Delete only flips a "deleted" marker inside the JSON and/or drops the entry from whichever UI's index — the file itself is untouched and remains on disk indefinitely, with no UI path left to remove it.
3. Per-session scratchpad directories under %TEMP%\claude\ are never cleaned up either. Every session (regardless of frontend, regardless of whether it was later "deleted") gets its own %TEMP%\claude\<project>\<session-uuid>\ folder that persists indefinitely — 55 such folders were found for a single project, dating back over a day of normal use, none removed after their sessions ended. Windows does not purge %TEMP% automatically by default (only opt-in Storage Sense does, on its own age/free-space schedule), so this is unbounded growth with no cleanup path from either the OS or the app.

Steps to reproduce

Part A — one-directional index sync:

1. Create session A in this app (Claude Code, not the VS Code extension).
2. Open the VS Code extension's session list → session A is visible there.
3. Create session B from the VS Code extension.
4. Check this app's session list (e.g. via the session explorer, or the list_sessions MCP tool) → session B is not visible, even after it's been running for a while (ruled out registration delay by re-checking after ~1 minute).

Part B — delete doesn't remove the file:

1. Take session A (created in this app, from Part A).
2. Delete it from this app's UI.

• Result: it's still listed in the VS Code extension's session list.
• Result: ~/.claude/projects/<project>/<A's-uuid>.jsonl still exists on disk; its content now contains a "deleted" marker/state.

1. Delete session A again, this time from the VS Code extension (where it was still showing).

• Result: no further change — the .jsonl file is identical, still present, still just marked "deleted".

Part C — scratchpad directories accumulate the same way:

1. Run Claude Code sessions normally (either frontend) over a period of time, closing each when done.
2. List %TEMP%\claude\<project-path>\ → one subfolder per session-uuid exists for every session ever run, including ones closed hours/days ago and ones already "deleted" via Part B.
3. In this instance: 55 such folders for a single project, oldest from over a day prior, none removed.

Expected behavior

• Sessions created in either frontend should be visible (and deletable) from both, since they're operating against what's supposed to be the same underlying project/session store.
• Deleting a session from either frontend should actually remove (or otherwise reclaim disk space for) its transcript file, or the UI should clearly indicate that "delete" only unlists it and the file is retained.
• A session's scratchpad directory under %TEMP%\claude\ should be removed once the session ends (or at least once it's deleted), not retained indefinitely.

Actual behavior

• The VS Code extension appears to maintain its own local session index that isn't written back to whatever shared index this app's explorer reads — so sync only flows one way (this app → VS Code).
• Delete, on both sides, is a soft operation (index/visibility + an in-file "deleted" marker) that never touches the file on disk.
• Net effect: every session ever created — deleted or not, from either frontend — permanently accumulates both its .jsonl transcript in ~/.claude/projects/<project>/ and its scratchpad folder in %TEMP%\claude\<project>\, with no UI-driven or automatic way to reclaim either. In our case the transcripts alone reached ~300 MB before being noticed and cleaned up manually by deleting .jsonl files directly from the filesystem; the scratchpad folders (55 for one project) are comparatively small today (~280 KB) but grow unbounded the same way, and Windows does not purge %TEMP% automatically by default.

Impact

Silent, unbounded disk growth over time for any user who uses both the VS Code extension and another Claude Code frontend, or who deletes sessions expecting the transcript/scratchpad to actually be removed. No warning or indicator surfaces this — it's only visible by manually diffing the project directory's files (and %TEMP%\claude\) against the session list.

Suggested fix

• Either make the VS Code extension write into the same shared session index this app reads (true bidirectional sync), or make clear in both UIs that they're backed by separate stores.
• Make "delete" actually remove the transcript file (or provide a separate "purge"/"empty trash" action that does), rather than leaving orphaned files with no remaining UI reference.
• Add a teardown hook that removes (or at least offers to remove) a session's %TEMP%\claude\<project>\<session-uuid>\ scratchpad directory once the session ends or is deleted.