How to Read Zed AI Assistant Panel Chat History as Real Documents

Zed ships with an AI assistant panel that lives to the right of your editor. It talks to Claude, GPT, or your own OpenRouter key, and it keeps every thread in a local file you can open. That last part matters more than most people notice. The panel is fine for asking questions inside the editor, but it is a terrible place to read a long answer twice, share a thread with a teammate, or reference an old debugging session six months later.

If you have ever tried to scroll back through a Zed thread that solved a nasty concurrency bug, you know the problem. The panel wraps aggressively, code blocks share the same narrow column, and there is no outline, no search across threads, and no way to hand the transcript to someone who does not use Zed. You end up screenshotting fragments and pasting them into a Slack thread, which loses the code fencing and half the context. The fix is boring and effective: pull the raw conversation out of Zed and read it as a real document.

Where Zed stores your assistant threads

Zed writes each assistant thread to disk as a JSON file inside its user data directory. On macOS the path is ~/Library/Application Support/Zed/conversations. On Linux it is ~/.local/share/zed/conversations, and on Windows it is %APPDATA%\Zed\conversations. Each file is named with a timestamp and a short slug derived from your first prompt, which makes them easy to sort by date. The format is plain JSON with a top-level messages array, so you do not need a Zed build to parse it.

Open one in any text editor and you will see the whole exchange: role, content, tool calls, and any file context Zed attached. The content is already markdown, which is the important detail. You do not have to reconstruct anything or run it through a converter. You have to render it somewhere that treats markdown as a first-class document instead of a chat bubble.

Turn a Zed thread into a real markdown file

The quickest path is a small shell script that reads the JSON and prints a clean markdown transcript. Loop over the messages array, print the role as an H2, and dump the content beneath it. Save the output as a .md file next to the project it belongs to. This gives you a searchable, version-controllable record that lives with the code it discusses.

If you do not want to script it, there is a Zed extension called assistant-export that writes the same transcript to a file with one command. Both approaches produce the same shape: a normal markdown file with the user prompts and assistant answers in order. Once the file exists, the reading problem becomes a rendering problem, and that has good answers. This is the same pattern that works for other editor-based assistants, and we covered a nearly identical flow in our guide on reading Cursor chat history.

Read the exported thread in Prism MD

Prism MD is built for exactly this file. Drop the exported markdown into Prism MD and you get proper typography, a persistent outline, KaTeX for any math the assistant produced, and Mermaid rendering for diagrams. Long code blocks stay legible instead of squeezing into a chat column, and the outline lets you jump between prompts without scrolling through a wall of answers. The reader also remembers scroll position per file, which sounds trivial until you are three days into a rewrite and want to pick up exactly where you left off.

The offline mode matters here too. Zed threads often contain code you cannot paste into a cloud service without breaking a policy, and Prism MD renders everything on device. You can read a full thread on a plane, tag it by project, and search across your entire assistant history without shipping a byte to anyone. That is the same reason people use it to read local LLM outputs from Ollama and LM Studio alongside their cloud transcripts.

Organize threads by project, not by date

Zed sorts conversations by timestamp, which is fine for one week and useless after three months. The moment you have more than fifty threads, you need a folder structure that matches how you think about work. Timestamps tell you when, but you almost always want to know what. A folder tree keyed on the project rebuilds that "what" without any extra effort. A simple layout that holds up over time:

• One folder per repo or product area
• One subfolder per initiative or bug hunt
• Filenames that lead with the problem, not the date

Once threads live in project folders, they behave like normal notes. Grep works, git works, and any markdown reader can walk the tree. The broader pattern for organizing AI conversations by project applies to Zed threads verbatim, and the payoff shows up the first time you need to remember how you solved something six months ago. You stop searching for "that thread about the deadlock" and start opening payments/checkout-race-condition.md directly.

What to keep and what to throw away

Not every thread is worth keeping. A one-shot rename question is noise, and archiving it fills your search index with junk. The threads that earn a permanent home are the ones where you learned something: a subtle race condition, a build system quirk, a library behavior that was not in the docs. Keep those, throw the rest away, and your archive stays useful instead of turning into a swamp.

A good rule of thumb is to review your Zed thread folder once a month. Delete the throwaways, rename the keepers to reflect what you learned, and move anything genuinely important into a longer-form note. If you want a system for pulling those keepers into a permanent knowledge base, the workflow in our post on building a personal knowledge base from AI conversations plugs into the Zed export flow with no friction. Over a year of use, the folder ends up looking less like a chat archive and more like a working engineering notebook.

FAQ

Can I export a Zed thread from inside the editor?

Not by default, no. Zed writes the JSON to disk automatically, but there is no built-in export command. Either read the JSON directly or install the assistant-export extension. Both routes land in the same place: a markdown file you can open in any reader.

Do exported threads include tool calls and file context?

Yes. The JSON records every tool call the assistant made and every file it read, and a decent exporter will render them inline so you can see what context shaped each answer. This is useful when you come back later and cannot remember why the assistant made a particular suggestion. The tool trail explains the reasoning without you having to reconstruct it from memory.

Is it safe to commit Zed threads to a git repo?

Only if you trust the audience. Threads often contain snippets of proprietary code, environment details, and half-formed thoughts, so private repos are fine and public ones are usually not. A per-project .gitignore entry for the export folder is a reasonable default. If you want them versioned, keep the archive in a private repo separate from the code repo.

Does Prism MD sync my Zed threads automatically?

No. Prism MD reads local files and does not touch your Zed data directory. You export or symlink the folder yourself, which keeps the boundary between the editor and the reader clean. That separation also means you can rotate readers later without losing your archive.