Claude Code deletes your session transcripts after 30 days by default. The control is one line in ~/.claude/settings.json, the catch is that turning it up can’t bring back anything already deleted, and most people never hear about either part until they go looking for a log that’s gone. I turned mine up months ago; today I checked whether it actually held, and found the exact scar the old default had left on my own machine.
The default: 30 days, deleted at startup
The setting is cleanupPeriodDays, a top-level key in ~/.claude/settings.json. The official settings docs spell out the behavior: “Session files older than this period are deleted at startup (default: 30 days, minimum 1). Setting to 0 is rejected with a validation error.” So the 30-day default and the delete-at-startup are stated outright in the Claude Code settings reference; that part is documented, not my inference.
“Logs” here is narrower than all of ~/.claude. What cleanupPeriodDays deletes is your session transcripts: the per-session .jsonl files Claude Code writes under ~/.claude/projects/ (one per session, plus a subagents/ file per subagent run), and per the Claude Code changelog tasks/, shell-snapshots/, and backups/ as well. It doesn’t touch file-history/, sessions/, plans/, or commands/, which persist on their own clock. So what’s at risk is your chat-session history, not every trace of what you’ve done.
One nuance the docs don’t pin down is the clock. They say “older than this period” without naming which timestamp they measure. On my machine the deletion keys off file last-modified time, so that’s how I’ll describe ages below, but treat that part as my observation, not as documented.
What I found when I checked mine
I’d raised my cleanupPeriodDays to 3650 a while back (about ten years, effectively keep-forever) and wanted to confirm it was holding. As of June 25, 2026 it is: 1,324 transcript files, 647 of them top-level sessions, are older than 31 days and still sitting on disk [measured, this machine]. I use 31 days rather than 30 as a one-day buffer, so everything counted is unambiguously past the default’s expiry; that number is a June-25 snapshot and drifts a little as files age past the line. Under the 30-day default every one of those files would have been deleted at some startup. My oldest surviving session transcript was last modified on May 7, 49 days ago.
For total footprint, across all ages, it’s about 7,000 transcript files and 1.58 GB [measured, point-in-time], and that only climbs as new sessions land.
The floor is a scar, not an empty past
Nothing on my machine survives from before roughly May 5 to 7, anywhere in the projects/ tree. My history doesn’t actually start there, though, and I can prove it from a directory the sweep leaves alone.
Claude Code’s file-history/, its record of the edits it makes, isn’t covered by cleanupPeriodDays. On my machine it runs back to March 3, with 150 edit-history entries across March and April [measured], two months before my oldest surviving transcript. I was working in Claude Code that whole stretch; the transcripts from those weeks are just gone, taken by the purge while the un-swept file-history carried on.
The git history says the same from the project side, on two of my own projects. dropKnowledge has 140 commits dated to April (673 before May in total) yet its oldest surviving session transcript is May 8; chat-arch has 37 commits before May yet its oldest is May 7. And shell-snapshots/, swept on the same clock as the transcripts, bottoms out around May 6 too, a second swept corpus hitting the same wall.
Put them side by side and the shape is clear: file-history unbroken from March, transcripts and shell-snapshots both stopping in early May [derived]. That’s the scar from the last 30-day purge, the one that ran while I was still on the default, before I’d raised the number.
That clock matters, since it decides what “older than 30 days” counts. The ages here are file last-modified time, as I flagged above, not session-start time. The oldest transcript’s earliest internal message is timestamped May 5, about two days before the file’s own modified time, so the two clocks don’t even agree. Last-modified is the one cleanup keys off, so it’s the right one for “would this have been purged.”
I’ve only got my own machine to show here. It shows the default actually biting: files surviving well past their old 30-day expiry, and a floor where the purge cut everything swept while the un-swept history kept going. It doesn’t prove the 30-day default holds for everyone, which is what the docs are for.
Check yours, then fix it
The check takes a few seconds. Open ~/.claude/settings.json and look for cleanupPeriodDays. If it’s there, that number is your retention in days. If it isn’t there at all, that’s the case to watch for: an absent key means you’re on the 30-day default. “I don’t have that setting” reads as “I’m fine,” but it actually means “I’m being purged every 30 days.”
The fix is one line:
{
"cleanupPeriodDays": 3650
}Larger numbers keep logs longer; 3650 is about ten years, effectively forever. If you don’t want a decade of transcripts piling up, pick a deliberate ceiling like 365. There’s a genuine tradeoff on the other side: keeping everything grows the on-disk footprint without bound, and a busy setup can generate hundreds to low-thousands of transcript files a week [derived, rough]. My 1.58 GB of mostly text is nothing today, but it only goes up.
The catch, which is the whole point
Raising the number only protects transcripts from that point forward. It does nothing for anything already aged out. I can watch this in my own timeline: my value was already 3650 by June 11, when I mentioned it in an aside in the Command post published that day, and that’s after the early-May floor. Turning it up prevented the next purge; it never recovered the pre-May window. That window is gone [derived].
So if you rely on your session history for anything (memory, tooling, retrospectives, audits, or just being able to reopen last month’s work) set this before you need it, not after. The setting protects the future. Nothing protects the past you didn’t keep.