Notes on coding agents and the pages they leave behind, on moving between notes apps, and on the plain mechanics of keeping what you think. Written and published from a Sumibako vault.
Where Claude Code keeps your conversation history, and the thirty days you have to read it
Where Claude Code stores conversation history, the cleanupPeriodDays default that deletes it after 30 days, and four ways to read a session file.
Prashant Shaw
Founder, Sumibako
9 min read
On 30 June The Register ran a story under the headline "Claude Code users complain their chat records are being mysteriously wiped out", which is the kind of sentence that makes you check a folder you did not know you had. The folder is ~/.claude/projects. Every conversation you have ever had with Claude Code is in it, one file per session, and by default each file is deleted thirty days after you last touched it, quietly, the next time Claude Code starts. Anthropic's position, given to the paper in a statement, is that this is a feature: "Keeping plain text transcripts of coding sessions on disk indefinitely creates real security and privacy risks, since they can contain source code, credentials, and other sensitive material," and "The 30-day default balances the ability to resume recent work against not holding that data on disk longer than needed."
They are right about the first part, which is why the rest of this post matters. The transcript of a coding session is the most complete record of a piece of work you will ever have, and it is also the most sensitive, and it is also on a timer. This is where the files are, what is in them, the setting that deletes them, four ways to read one, and what to keep. Everything below was checked on 30 October 2026 against Anthropic's own sessions page, two GitHub issues and that article.
🗂️ Where the files are
The documentation is plain about it. Transcripts live at ~/.claude/projects/<project>/<session-id>.jsonl, where the project folder is "your working directory path with non-alphanumeric characters replaced by" a hyphen. So a project at /Users/you/code/app
. A path longer than 200 characters is cut and given a hash. Inside the folder is one
.jsonl
file per session, named by the session's id, and on my machine a session that ran subagents also has a folder of its own beside the file, with their transcripts under
subagents
.
The format is one JSON object per line. "Each line is a JSON object: a message, a tool use or result, a record of a request Claude Code sent the model, or a metadata entry." Most of the lines are the last kind. Opening one of mine from a long day, the file was 30 MB and ten thousand lines, of which about a thousand were things I said or Claude said back; the rest were tool calls, their results, snapshots of files before an edit, and bookkeeping. It holds everything the agent saw: every file it read, every command's output, in full. That is what makes it worth keeping and what makes Anthropic nervous about keeping it.
Two environment variables move it. CLAUDE_CONFIG_DIR moves the whole of ~/.claude somewhere else, and CLAUDE_CODE_PROJECT_DIR_NAME names the project folder yourself instead of deriving it from the path, which the docs describe as being for hosts that embed Claude Code and give each session a directory of its own.
⏳ The thirty days
The setting is cleanupPeriodDays, in settings.json, and the sessions page lists it in one line: "Change the 30-day retention". The settings reference described it, in the words a GitHub issue quoted back in June 2025, as "How long to locally retain chat transcripts (default: 30 days)". That issue asked whether the thirty days ran from a session's creation or its last activity, and was closed without an answer; a later reply in it says a session's files go thirty-one days after the last time you used it.
What it does, as The Register put it: "The problem appears to come down to the cleanupPeriodDays configuration option, which defaults to 30 days and runs every time Claude Code starts up, wiping out any .jsonl file it finds that isn’t fresh enough." There is no notice. A second issue, from a Claude Desktop user, is titled "Session transcripts silently auto-deleted after 30 days; sidebar shows ghost entries that error on click", and describes a default that "silently deletes session transcript JSONL files with no notification, no opt-in, and no exposure in the desktop UI", leaving the app's sidebar listing sessions whose files are gone. It was closed as not planned. Anthropic told The Register the policy has been there since launch and is documented, which is true, and is also the problem: nobody reads the settings reference until the day they need a file that is not there.
To keep sessions longer, put the setting in ~/.claude/settings.json:
The desktop app and Cowork have a setting of their own, desktopSessionCleanupPeriodDays, and the article notes that several users reported a large value not behaving, so after you change it, check the folder in a month rather than trusting it. The docs also say what to do when you want the opposite: "To delete a project’s transcripts and related state sooner, run claude purge".
⚠️WARNING
The sweep runs when Claude Code starts, so the morning you open it to find last month's session is the morning it goes. If there is a session from more than three weeks ago you still want, read it or copy the file today, before the next claude.
🔍 Four ways to read a session
1️⃣ The session picker.claude --resume with no argument opens it, and each row shows "the AI-generated session title, conversation summary, or first prompt, along with time since last activity, git branch, and file size". claude --resume <transcript-path> resumes a file by its absolute path, which means a .jsonl copied from another machine opens too. Resuming is reading with the meter running: the whole session is loaded back into the model's context, and on a long one Claude Code shows a "Resume this conversation?" dialog with an estimate of how much of your five-hour usage limit that costs. It is the way to continue work, and an expensive way to look something up.
2️⃣ /export. From inside a session, "Run /export to open a menu that lets you copy the current conversation to your clipboard or save it as a plain-text file, with messages and tool outputs rendered as readable text." Pass a filename to skip the menu. The docs are precise about what it is for: "/export produces a rendered transcript for a person to read." It is the right thing for the session you are in. It cannot open a session you are not in, and it does not survive the thirty days unless you ran it in time.
3️⃣ A script. The sessions page lists the interfaces meant for code: claude -p --resume <session-id> --output-format json to ask an old session a question and get structured JSON back, and the transcript_path that hooks receive, with the note that "A SessionEnd hook can archive the transcript when a session ends." That last one is the quiet answer to the whole retention question. A three-line hook that copies the file somewhere on every session end is a backup nobody has to remember.
4️⃣ A viewer. The file itself, dropped on something that reads it. I built one, because I wanted to read a session from three weeks ago without paying to resume it: the Claude Code history viewer takes one .jsonl or a project folder's worth, lists the sessions newest first with a search box across all of them, and shows each one as it ran, with every tool call folded under the step that made it, the command or the path on the line and the result inside, each compaction marked with the token counts before and after, and Claude Code's own cost line from the file. Nothing is uploaded; the file holds your code, so it is read in the browser and stays there. One session comes out as Markdown or as a single HTML file with the calls still folded, all of them as a zip.
📝NOTE
Anthropic warns that "The entry format is internal to Claude Code and changes between versions, so scripts that parse these files directly can break on any release." The viewer parses that format, and was written against the files Claude Code 2.1 writes in October 2026. If a release changes the shape and yours reads wrong, the page's hello address is where to say so.
🧾 What is in a file, from reading mine
Anthropic documents where the file is and not what is in it, so this part is from opening a few of my own. Each prompt I typed is a user record with the text as I typed it, and a slash command is stored wrapped in tags with the program's own message beside it. Each reply is several assistant records that share one message id, one per block: the text, a tool call with its full input, a thinking block. The tool's result comes back as a user record of its own, with the output in full, which is where the megabytes go. A compaction is a system record with a compact_boundary subtype, carrying how many tokens the context held before and after; one of mine went from 428,605 to 17,713. A cost-state record keeps a running total in dollars, by model, with lines added and removed. And the context the program injects, CLAUDE.md, a skill you invoked, a reminder, is in there too, as attachments and as user records marked isMeta, which is how a reader tells what you said from what the program said on your behalf.
Two things are not in it in any useful form. Images, a screenshot you pasted or one a tool took, are present as data and best treated as a count. And the thinking blocks in my files were mostly empty, with a signature where the text would be. If you were hoping to read the reasoning, the file is not where it is kept.
💾 What to keep, and where
The lesson of the compaction post applies here with the timer added: a file on disk survives, and this particular file survives for thirty days. The transcript is a record, not a note. It has the tool output in it and the decision buried under the tool output, and it is large and sensitive and on a schedule.
So keep three things, in order of effort. Raise cleanupPeriodDays, which costs a line in a file and keeps the raw record for when a bug turns out to have been introduced in week six. Export the sessions worth re-reading as text, with /export while you are in them or as Markdown or HTML from the viewer after, and put the files where your other documents live rather than in a hidden folder named after a path. And for the sessions that decided something, write the decision down somewhere a person will find it: the viewer's Import button puts a session into a Sumibako vault as a page of the prompts and replies, with each run of tool calls counted on one line so a long day fits, and the agent can write the handoff page itself at the end of a session, which is the version that does not need you to remember.
The thirty days is Anthropic's answer to a real risk, and I would not turn it off on a shared machine. I would just stop treating the folder as an archive. It is a cache with a good explanation, and the archive is wherever you put the sessions you read twice.
What Claude Code's compaction keeps and drops, when it fires without asking, the idleCompaction setting that stops it, and the one habit that makes it harmless.
