Export Copilot sessions to record interactions with AI as material for articles#
Introduction#
When interacting with AI, it can be difficult to look back on something important at the moment, even though it is investigating or making decisions on the spot.
Right-clicking in the chat pane and choosing “Copy All” lets me extract the conversation as Markdown. But clicking through and saving it manually every time is not a very solid workflow.
What I wanted to do this time was something simpler.
I would like to keep a log of what I researched and thought about AI, including the interaction with Copilot that I am currently doing, under the current repository. Then, I would like to read the logs later and write blog articles about things that interested me and the knowledge that became clear through my interactions with AI.
This time, as an entry point for that purpose, I will record how I started writing a script to export Copilot Chat sessions to Markdown.
Initial Thoughts#
The first thing I looked into was how the existing Copilot session export extension retrieved session information.
My hope is that it will be easier to use if the session list, title, date and time, and body can be obtained from something like Copilot’s public API.
However, when I investigated, I found that rather than using such a stable API, it seemed to be reading the JSONL of the transcript stored under VS Code’s user data and reconstructing session information from there.
In other words, the actual process is as follows.
Search under
workspaceStoragein VS CodeRead
.jsonllocated atGitHub.copilot-chat/transcriptsGet session ID and start time from
session.startExtract
user.messageandassistant.messagein orderCreate a title from the first user comment
Format and save in Markdown
It’s important to note that this is not a method based on Copilot’s official stable API.
If the internal storage format of VS Code or Copilot changes, it may break. However, as a tool for keeping a personal work log, I decided that it was worth trying out first.
Saving with a script instead of right-click copy#
The original goal was to be able to save logs from the command line instead of manually copying them from the chat field.
So I came up with the following script.
rye run python export_sessions.py --latest
Use --latest to write only the latest session. If you want to check the list, use --list. If you want to display only a specific session, use --session.
The output format was Markdown.
The blog posts themselves are written in reStructuredText, but Markdown is easier to read as a raw log and makes it easier to preserve the Copilot conversation as-is.
When turning the log into an article, I can extract the parts I need and organize them into a reStructuredText post.
Think about where to store your logs#
When I started writing the script, the first thing I wondered about was where to put the file.
This repository is strictly a Sphinx + ablog blog site. Therefore, it is not very clean to keep adding auxiliary scripts that are slightly different from the main blog directly under the root.
On the other hand, translate-po-ja-en.py is already located directly under the root. This is a blog support tool created to support the translation of articles into English.
So, should I also move this export_sessions.py to a location like tools/? Or should I allow it to be placed directly under the root for now?
When I looked into it, I found that translate-po-ja-en.py was referenced in the command examples in AGENTS.md and README.md. It seems that there will be no major technical problems with the move, but the documentation will need to be updated.
This time, rather than organizing the script placement, I prioritized starting operations to keep logs.
Therefore, I decided to leave the script body directly under the root and separate only the output destination.
_notes/sessions/
Save the Copilot session Markdown here. Treat _notes as a storage area for hand notes and materials, and keep it separate from the published article itself.
Furthermore, since raw logs are not committed as they are, use .gitignore to make them unmanaged.
If you follow this policy, the flow will be as follows.
AI とやりとりする
↓
export_sessions.py で Markdown に保存する
↓
_notes/sessions/ に生ログが残る
↓
ログを読み返して記事の主題を決める
↓
docs/blog/posts/ に ablog 記事を書く
You can separate “raw logs” and “published articles”, making it easier to handle them later.
Commit the script to make it a good script#
The next thing I was concerned about was whether the script was in a good state to commit.
The initial implementation assumed a specific ID for workspaceStorage in VS Code. This works in my environment, but if I commit it as is, it becomes a script that is highly dependent on the environment.
Therefore, instead of assuming a fixed workspace ID, by default it scans under workspaceStorage and looks for the directory where GitHub.copilot-chat/transcripts exists.
If necessary, you can narrow down the target with options.
rye run python export_sessions.py --workspace-id <workspace-id>
rye run python export_sessions.py --transcripts-dir <path>
Normally, it is used for automatic search, so that it can be explicitly specified only when necessary.
This eliminates the need to directly write personal workspace IDs.
This change was not just about keeping things tidy. A script committed to the repository should still make sense when I look at it later in another environment, and it should be easy to adjust if needed.
If environment-specific values remain mixed in, it may work as a work memo at that point, but it will be weak as a tool to keep in the repository.
What I learned this time#
What became clear through this work is that simply saving the interactions with AI as-is is not enough to make them into a blog post.
The log contains a mixture of progress during the investigation, hesitations, confirmations, and implementation decisions. It is valuable as a work record, but it is not meant to be read directly by the reader.
When writing an article, you will need to organize it as follows.
what I wanted to do
where I hesitated
What decision did you make?
How was it actually implemented?
What knowledge can you use next time?
This time, we’re not just talking about exporting Copilot sessions.
What matters more is building a flow where conversations with AI do not end as temporary chats, but are kept as work logs and later turned into blog posts.
Creating a tool to keep logs is also a preprocessing process for writing articles.
Future usage#
In the future, after comprehensive research and implementation consultation with AI, logs will be saved as follows.
rye run python export_sessions.py --latest
Read over the saved Markdown, and if you find a theme that could be written about as an article, compile it as a future-dated article in docs/blog/posts/.
At this time, there is no need to write an article about the entire contents of the raw log.
Rather, I think of logs as material, and articles that are restructured for readers from there.
If necessary, the following improvements could be made in the future.
Make title generation a little more readable
Detecting what appears to be secret information from output Markdown
Narrow down sessions to specific repositories
Generate article draft suggestions from logs
Develop a dedicated agent definition for turning logs into ablog posts
The last point in particular goes well with the operation of this blog.
If you define an agent that not only saves logs but also writes articles from them, next time you can simply ask them to write an article based on this log, and it will be easier to arrange the date, location, article format, and confirmation items.
Closing#
Conversations with AI can also be used just to solve problems on the spot.
However, if you keep a log of your research and decisions, you can reuse it later as your own knowledge. Furthermore, if I organize it into a blog post, it might be helpful to someone who is thinking about the same thing.
This time, as a first step toward that end, I started creating a mechanism to export Copilot sessions to Markdown.
Although there are still some parts that depend on the internal storage format, it seems like it will be enough to start using it as a tool for keeping personal work logs.
First, leave a log. Then read it again. And write an article.
I want to grow this workflow little by little.
Article information
- author:
mtakagishi
- Published:
2026-05-29