[FEATURE] VS Code extension: "Search Sessions" should search session content, not just session titles
Preflight Checklist
- [x] I have searched existing requests and this feature hasn't been requested yet
- [x] This is a single feature request (not multiple features)
Problem Statement
I frequently need to return to a past Claude Code session — to reread how something was decided, recover context, or resume the work. I remember what the session was about (a file name, a symbol, an error string, a phrase I typed), but I rarely remember what the session ended up being titled.
The VS Code extension's "Search Sessions" input only matches the session title. Session titles are short, auto-generated, and frequently reflect one incidental message rather than the substance of the conversation. So the one thing I reliably remember about a session — its content — is the one thing I can't search on.
The practical effect: once a session scrolls out of recent view, it is effectively unfindable from inside the IDE. My fallback is to leave VS Code and grep ~/.claude/projects/<slug>/*.jsonl by hand, which finds the session ID but doesn't connect back to the extension's "resume session" action.
Proposed Solution
Extend the existing "Search Sessions" input in the VS Code sidebar so a query matches session content as well as the session title.
The transcripts are already on disk as .jsonl; this is a matter of reading them, not of new data collection. Options, lightest to heaviest:
- Match user messages only. Usually sufficient — people recall what they asked. Lowest cost.
- Match all message text (user + assistant), with a matching snippet shown under the session in the results list so I can tell candidate sessions apart.
- A maintained index (e.g. SQLite FTS5) over the transcripts, for users with large session histories.
Even option 1 would close the gap. Ideally the results show a match snippet and clicking one resumes that session directly, so search and resume stay in the same place.
Alternative Solutions
- Grep the transcripts manually (
~/.claude/projects/<slug>/*.jsonl). This works, and it's what I do today, but it's outside the IDE, requires knowing the on-disk layout, and produces a session ID rather than something I can click to resume. - Third-party indexers exist (e.g.
claude-code-searchon PyPI, built by a user in response to this exact gap). That such tools keep getting built is evidence of the demand; relying on them means an unofficial index of conversation transcripts, which not everyone will want. - Scroll the sidebar and rely on memory of the date. Breaks down entirely past a few dozen sessions.
- Rename every session by hand so the title contains searchable terms. Requires predicting, at the start of a session, which term future-me will search for.
Priority
High - Significant impact on productivity
Feature Category
Other
Use Case Example
- Last week I worked through a tricky bug in
wiring_runner.pyinvolving a cross-shard wake gap. Over the session we identified the root cause and I want that reasoning back. - Today I open the VS Code sidebar and type
wiring_runnerinto "Search Sessions". - Expected: the session appears, ideally with a snippet showing where the term matched.
- Actual: no results. The session's title is something like "Fix the ordering issue" — a phrase that appears nowhere in my memory of the session, and
wiring_runnerappears nowhere in the title. - I leave the IDE, grep the
.jsonlfiles, find a session ID, and resume by ID from the CLI.
Step 5 is the whole gap: the information is on disk, the extension just won't search it.
Additional Context
Environment
- Claude Code: 2.1.207
- VS Code: 1.128.0
- OS: Windows 11 (10.0.26200)
Why this is not a duplicate of the previously-closed issues
This request has surfaced before, but no open issue currently tracks it:
- #50344 was this exact request (VS Code sidebar search is title-only). It was auto-closed by the duplicate-detection bot as a duplicate of #30599, and is now locked.
- #30599 was about the CLI
--resumeand TUI/resumepicker — a different surface. It was then auto-closed as stale / not-planned, so the VS Code request was folded into a CLI issue that subsequently died of inactivity rather than being declined on the merits. - #34098 (fuzzy search for the
--resumepicker) and #33683 are likewise CLI-picker issues, and closed.
So: the VS Code sidebar surface has never had an open issue tracking it to a decision. If the maintainers would prefer one issue covering all surfaces (CLI picker, TUI, and the VS Code sidebar), I'm happy for this to be that issue — but please reopen or track it somewhere rather than closing it back into a closed issue.
Suggested labels: enhancement, area:ide, platform:vscode.