Part of the VS Code + GitHub Copilot as a Personal Assistant series.
Most people treat chat sessions with an AI assistant as ephemeral. The conversation happens, you get the answer, you close the chat. Maybe you copy a snippet out. Mostly the conversation is gone.
It is not gone. It is sitting on your disk as a plain text file. And it is enormously more useful than people realise.
Where to find it
Every chat session in VS Code with GitHub Copilot is saved as a JSONL file under %APPDATA%\Code\User\workspaceStorage\.
One file per conversation. JSON Lines format: one JSON object per line, each line is a message in the chat. The hash in the path identifies the workspace. The id in the filename identifies the specific conversation.
These files accumulate as you use Copilot. After a month of normal use, you have dozens. After six months, hundreds. They are searchable like any other text file.
Why this matters
Three patterns that use the chat history as a knowledge base.
1. Continuity across chats
I run multiple chat sessions per topic (covered in the first post in this series). Sometimes a conversation in one chat needs to inform a different chat. “In the Daily Ops chat this morning we decided X. Now I am in the Customer chat for X. Can you read that earlier conversation and continue from where it left off.”
I paste the path to the relevant JSONL file. The new chat reads the transcript. The context is absorbed. The new chat picks up where the old one left off. No re-explaining.
This is the most common way I use the chat history, and it costs about five seconds per handoff.
2. Annual review prep
The end of the performance year used to mean a week of trying to remember what I had done. Customer outcomes, technical decisions, key conversations. The kind of content that is not in formal status reports but is the actual story.
It is all in the chat history. Time-stamped. Per topic. Searchable.
A subagent (covered in the previous post) is the right tool for the search. “Read through my chat transcripts from the last six months. Find conversations where I worked through a customer outcome or made a technical decision. Summarise the top fifteen, with dates and the specific result.” The subagent does the reading. Comes back with a structured list. That list becomes the spine of the review writeup.
What used to be a week is now an afternoon.
3. “What was that thing I worked out three weeks ago”
The most underrated one. Every working day produces small insights, half-finished ideas, dead-end investigations, useful one-liners, fragments of code that worked. They live inside the chat where they happened. Without a way to retrieve them, they are effectively gone.
With searchable chat history, they are not gone. “I had a chat a few weeks ago where I worked out a query for X. Find it.” A subagent reads the relevant transcripts. Surfaces the chat. Quotes the bit I need.
This works because chats tend to have specific terminology in them. A search for the customer name or the technical concept hits the right files. The signal-to-noise ratio of chat transcripts is much higher than email or general note-taking, because chats are dense with the topic you were on.
How to actually use it
A few practical patterns.
For continuity across chats: copy the path of the source chat from File Explorer or the chat URL, paste it into the destination chat, say “read this transcript and pick up where we left off”. That is the whole technique.
For search: use a subagent. Describe what you are looking for. Constrain the time window if you can. Ask for direct quotes plus the source filename so you can verify.
For annual review prep: do the subagent search early. The results need to be curated by you, not just lifted. The chat history is the raw material. The review is the artefact you build from it.
For sharing across machines: if your workspace is on OneDrive (covered later in the series), the chat history naturally rides along. The same chat on your laptop is visible from your other devices. This works because the JSONL files are under %APPDATA% per machine but VS Code can read them across workspaces.
What this is not
This is not “all your chats are stored in the cloud and indexed by a third party”. The JSONL files are local to your machine. Your control. Your filesystem. If you want them backed up, back them up. If you want them deleted, delete them. The pattern is about treating local files as a knowledge base, not about granting anyone else access to them.
It is also not “the chat history is structured data you can query with SQL”. It is JSON Lines. It is text. The reading is done by the assistant, which is much better at extracting meaning from noisy text than any structured query language would be.
What I wish someone had told me earlier
Two things.
Rename chats early. The default chat names are useless. “Chat 2026-05-25 14:31” tells you nothing. “Engineering 1:1” tells you exactly what is in there. Renamed chats are vastly easier to find later. The chat name lives in the JSONL file, so search hits the name too.
Trust the corpus. Early on I would re-derive things I had already worked out, because I did not trust the chat history would have the answer. Once I switched to “search chat history first, derive only if not found”, the time savings were substantial. The corpus is real. Use it.
The mental model
A regular chat assistant is a series of conversations that happen and then evaporate.
A chat assistant treated as a knowledge base is the same series of conversations, but the conversations accumulate into a personal corpus. The longer you use it, the more valuable the corpus becomes. The corpus is yours. It is searchable. It is quotable. It carries forward.
This is the difference between using AI as a tool and using AI as part of your second brain. The tool version evaporates. The second-brain version compounds.
Next in the series: more tips as I publish them. The LinkedIn series is still going.
The LinkedIn version of this tip went out on 25 May 2026.