[BUG] VS Code sidebar delete (trash) is still a silent no-op — #49824 was closed as not planned without a fix

Preflight Checklist

• [x] I have searched existing issues
• [x] This is a single bug report
• [x] I am using the latest version of Claude Code

What's Wrong?

Clicking the delete (trash) icon beside a session in the VS Code extension sidebar does nothing. The session stays in the list, the underlying .jsonl in ~/.claude/projects/<project>/ is not removed, and there is no confirmation dialog, error, or visual feedback of any kind. The click is a silent no-op.

This was previously reported as #49824 (17 April 2026) and closed by the stale bot as "not planned" without a fix. It is still broken ~140 versions later. There is no CLI escape hatch either: claude --help lists agents, auth, mcp, plugin, project and so on, but no session management command, so deleting a session by hand means finding and rm-ing the right .jsonl.

Related but distinct: #78173 (the rename/delete icons are barely visible on hover) is about seeing the control. This is about the control not working once you do.

What Should Happen?

Clicking delete should remove the session from the sidebar and delete or archive its .jsonl, ideally behind a confirmation prompt. Failing that, it should surface an error rather than doing nothing.

Environment

| | |
|---|---|
| Claude Code CLI | 2.1.222 |
| VS Code extension | 2.1.232 (2.1.229 also present) |
| VS Code | 1.133.0 |
| OS | macOS 26.5, Apple Silicon |

Steps to Reproduce

1. Open VS Code with the Claude Code extension.
2. Open the Claude Code sidebar; hover a session to reveal the pencil and trash icons.
3. Click the trash icon.
4. Observed: nothing. No dialog, no error, no change to the list.
5. ls ~/.claude/projects/<encoded-cwd>/ — the session's .jsonl is still there, mtime unchanged.
6. Reload the window (Developer: Reload Window). The session is still listed.

Verified locally, so these can be ruled out

• Not permissions. ~/.claude/projects/ and the per-project directory are user-owned and writable (drwx------ marcellosano staff), and the .jsonl files are -rw------- owned by the same user. rm on one succeeds.
• No lock or temp files in the session directory.
• Not storage corruption. The transcripts are well-formed JSONL and load fine when resumed.

Why it matters

Session transcripts accumulate with nothing able to prune them from the UI. On this machine:

• 157 sessions in a single project directory
• 1.1 GB in ~/.claude/projects/
• largest single transcript 22 MB

The sidebar is also the only place most users will look. With delete inert, the list grows without bound and the only remedy is hand-editing an internal directory — which is exactly the operation most likely to destroy the wrong thing, since the files are named by UUID with no title on disk to identify them by.

There is a sharper edge to that last point given #86280, #69140 and #59248 (transcripts being deleted unintentionally): users are currently unable to delete the sessions they want gone, while separate bugs delete ones they wanted kept. A working, confirmed delete would help on both sides.