Describe the feature or problem you'd like to solve
copilot --resume (and the interactive resume picker) can find a past session by session ID, ID prefix, or name — but it does not search the content inside the session (the user/assistant messages stored under ~/.copilot/session-state/<id>/events.jsonl).
If I remember a session by something that was typed in it — a file path, a PR number, an error string, a class/function name, a command I ran — but the session was never named (or has a vague or duplicated auto-generated name), I currently can't find it via --resume. I have to open sessions one by one and read through them.
This was partially raised in #714 (Feature Request: Session History Search), which was closed as "addressed in a different form — experimental support in agent workflows, not a standalone command, and not yet GA," with an invitation to reopen if it doesn't meet the use case. It's also related to #3615 (natural-language resume lookup). Neither currently gives a generally-available way to match on the actual text inside a session.
Proposed solution
Make session search look inside message content, not just the name/ID. Any of these would solve it:
copilot --resume "<text>" matches sessions whose messages contain that text (today this only matches the session name).- A type-to-filter in the interactive
copilot --resume picker that greps message bodies, not just the displayed name.
- A dedicated
copilot search <keyword> that lists matching sessions and lets you resume one.
Suggested result format:
sessionId | matched snippet | name | last active
Example prompts or workflows
copilot --resume "src/auth/login.ts" — I edited that file in some sessioncopilot --resume "PR #15883012" — I discussed that PR somewherecopilot --resume "ServiceBusMessageErrorHandler" — find the session about that class- Interactive: run
copilot --resume, then type to filter by content, not just name
Additional context
Session transcripts already live locally as JSONL under ~/.copilot/session-state/<id>/events.jsonl, so local content search is feasible and fast (ripgrep over those files is near-instant). Building the search into --resume / a search command would make it work out-of-the-box without users maintaining their own grep/fzf scripts or a side "search-history" session.
Related: #714, #3615.
Describe the feature or problem you'd like to solve
copilot --resume(and the interactive resume picker) can find a past session by session ID, ID prefix, or name — but it does not search the content inside the session (the user/assistant messages stored under~/.copilot/session-state/<id>/events.jsonl).If I remember a session by something that was typed in it — a file path, a PR number, an error string, a class/function name, a command I ran — but the session was never named (or has a vague or duplicated auto-generated name), I currently can't find it via
--resume. I have to open sessions one by one and read through them.This was partially raised in #714 (Feature Request: Session History Search), which was closed as "addressed in a different form — experimental support in agent workflows, not a standalone command, and not yet GA," with an invitation to reopen if it doesn't meet the use case. It's also related to #3615 (natural-language resume lookup). Neither currently gives a generally-available way to match on the actual text inside a session.
Proposed solution
Make session search look inside message content, not just the name/ID. Any of these would solve it:
copilot --resume "<text>"matches sessions whose messages contain that text (today this only matches the session name).copilot --resumepicker that greps message bodies, not just the displayed name.copilot search <keyword>that lists matching sessions and lets you resume one.Suggested result format:
Example prompts or workflows
copilot --resume "src/auth/login.ts"— I edited that file in some sessioncopilot --resume "PR #15883012"— I discussed that PR somewherecopilot --resume "ServiceBusMessageErrorHandler"— find the session about that classcopilot --resume, then type to filter by content, not just nameAdditional context
Session transcripts already live locally as JSONL under
~/.copilot/session-state/<id>/events.jsonl, so local content search is feasible and fast (ripgrep over those files is near-instant). Building the search into--resume/ asearchcommand would make it work out-of-the-box without users maintaining their own grep/fzf scripts or a side "search-history" session.Related: #714, #3615.