How to Read Cline Chat History as Real Documents

If you use Cline in VS Code, you already know the pain. A long agent run scrolls off the panel, the tabs pile up, and when you want to reread the reasoning behind a change it takes ten minutes of clicking to find the moment. Cline stores everything on disk, which is great. It simply does not give you a comfortable way to read it later. This guide walks through where those files live, how to open them as real documents, and how to keep them useful over time.

Cline is the VS Code agent formerly known as Claude Dev, and it writes each task to a local folder as JSON. The structure is stable enough to script against, and once you know the layout you can pipe it into any markdown reader you prefer. The rest is taste. If you also work in other tools, we cover the same shape in our guide to reading Cursor chat history and the one for Claude Code and Cursor agent transcripts.

Where Cline stores your chat history

On macOS, Cline writes tasks to ~/Library/Application Support/Code/User/globalStorage/saoudrizwan.claude-dev/tasks. On Linux it lives under ~/.config/Code/User/globalStorage/saoudrizwan.claude-dev/tasks. On Windows the path is %APPDATA%\Code\User\globalStorage\saoudrizwan.claude-dev\tasks. Inside that folder you get one subdirectory per task, named with a timestamp. Each task folder contains api_conversation_history.json, ui_messages.json, and any files Cline created or attached during the run.

The two JSON files serve different purposes. api_conversation_history.json is the raw exchange with the model, including tool calls and results. ui_messages.json is what you saw in the VS Code panel, including the say and ask events, so it reads closer to a transcript. For rereading later, the UI messages file is almost always the friendlier starting point. The API file is what you want when you need to audit tool arguments or debug a strange model choice.

Convert a task to clean markdown

The fastest path is a small shell script that walks a task folder and prints markdown to stdout. You do not need anything exotic. jq and a handful of pipes will get you a clean file per task, ready to open in any reader. The rough shape looks like this.

• Read ui_messages.json and filter for type of say or ask.
• Map say to a role heading and ask to a callout so tool confirmations stand out.
• Preserve code blocks as fenced blocks with a language hint when the message includes a file path.
• Append a short footer with the model name, token counts, and cost pulled from the last few entries.

The result is a self contained markdown file that you can open anywhere. If you keep every task as its own document, a single folder becomes a searchable log of every agent session you have run. Naming that folder something boring like cline-archive and dropping it into your dotfiles or a private repo pays off within a month. That folder plays nicely with the workflow described in our post on building a personal knowledge base from AI conversations, and it makes the search-across-everything approach with ripgrep immediately useful.

Read the transcripts without losing the thread

A raw dump is fine for grep. It is not fine for careful rereading. Cline runs tend to be long, they contain a lot of tool output, and the visual noise from raw diffs makes it hard to follow the reasoning. This is exactly the problem markdown readers were built to solve. Prism MD renders code blocks with proper syntax highlighting, folds long tool results by default, and gives you a table of contents so you can jump between tasks. On a mid range laptop it opens a 300 message transcript in under a second.

Once you have a clean file per task, treat it the way you treat a design doc. Skim the section headings first. Open the code blocks that changed anything real. Skip the retries. If a section is worth keeping, drag it into your notes app the same way you would with any other reference. Reading Cline history well is mostly about deciding what to ignore, which is a skill you build after a few honest attempts.

Keep the archive useful

An archive that grows without pruning becomes noise. Cline generates a lot of tasks, and many of them are throwaway experiments you will never read again. Once a week, spend five minutes deleting the folders you no longer care about. Keep the ones where the agent made a real change to your repo, or where the reasoning surprised you and might be worth quoting later. A short pruning pass every Friday keeps the archive under control without turning it into a second job.

Two more habits pay off. First, rename kept task folders with a short human label after the timestamp, so future you can scan the list without opening each one. Second, if a task produced code that shipped, drop the PR link into the top of the markdown file. That single line turns the transcript into a small piece of engineering history rather than a loose log. Over a year you end up with a private commentary track on your own codebase, which is more valuable than any generic changelog.

FAQ

Does Cline sync history to the cloud? No. Cline is local first, which is part of why people pick it over hosted assistants. Everything lives in the VS Code global storage folder for that machine, and nothing leaves the disk unless you move it. If you want the history on another laptop, copy the folder yourself or sync it with your dotfiles setup. Syncthing works well for this because it handles the many small JSON files without complaint.

Can I read Cline transcripts on my phone? Yes, once you export them. Convert the task to markdown, drop the file into iCloud, Dropbox, or Syncthing, and open it in any mobile markdown reader. The same approach works for reading long AI answers on iPhone and on Android. The phone is a fine surface for skimming reasoning while away from the desk, though editing on it is a losing battle.

What is the difference between Cline and Claude Code transcripts? Cline runs inside VS Code and stores per task folders with UI plus API JSON. Claude Code runs in a terminal and stores its own session files under a different path. The reading workflow is the same in both cases, but the exact scripts differ because the JSON schemas are not identical. Both are covered in the coding agent reading guide linked earlier.

Is it safe to commit Cline task folders to a repo? Usually no. They contain full model outputs, sometimes with file contents, environment details, or paths you would rather not publish. If you want to version an archive, use a private repository and review before pushing. A quick pass with a secrets scanner on the export is a cheap sanity check before any push, even to a private remote.