This article was created with the help of AI. The numbers come from my own server.
My first prompt to Claude Code on my work server is dated May 26. The oldest session transcript still on disk is from September 11. Everything in between is gone, and I never saw a warning.
It isn't a bug. Claude Code keeps session transcripts for 30 days and then deletes them. The docs say so, on a page few people open. One line in the settings changes that, but only going forward.
What disappears
Every Claude Code session is written to a file under ~/.claude/projects/. It holds the whole conversation: your messages, the model's replies, every tool call and its result. /resume reads these files to take you back into an old session.
After 30 days the file is deleted. Nothing tells you. The session simply stops showing up in /resume, and its subagent transcripts and any orphaned git worktrees from parallel tasks go with it.
Some things survive:
-
Prompt history.
history.jsonlkeeps what you typed, unless HIPAA settings apply to your account. So my May questions are still there. The answers are not. - Auto memory. The notes Claude keeps about a project are not part of the sweep.
-
Claude Desktop and Cowork sessions. Since v2.1.248 they are kept at any age, unless you set
desktopSessionCleanupPeriodDays.
I checked my own server
On October 11 I had 724 transcript files taking 861 MB. By age: 181 from the last week, 62 from the week before, 338 from the third week and 143 older than that. Not one older than 30 days.
I can't check what was in the deleted ones. Probably bug hunts and notes on why something was built a certain way. Exactly what you open an old session for.
Has it already happened to you?
Three commands:
grep cleanupPeriodDays ~/.claude/settings.json
find ~/.claude/projects -name '*.jsonl' | wc -l
find ~/.claude/projects -name '*.jsonl' -mtime +30 | wc -l
The first shows whether you set a retention period. If it prints nothing, you're on the 30-day default. The second counts all transcripts, the third only those older than 30 days. If the third prints zero and you've used Claude Code for more than a month, the sweep has already run.
One line in settings
Add the key to ~/.claude/settings.json:
{
"cleanupPeriodDays": 3650
}
That's about ten years. Three things to watch:
-
Zero doesn't mean never.
0fails validation, and the minimum is 1. To keep things long, pick a big number. - It only works forward. Deleted files don't come back.
- Disk adds up. A month of my work took 861 MB, roughly 10 GB a year. I run a lot of agents, so yours may be far less.
The catch: those files hold everything
Transcripts are plain text, unencrypted. The docs are blunt about it: if a tool reads a .env file or a command prints a credential, that value lands in the session file. That is why the default is short.
The longer you keep history, the more secrets pile up on disk. If you raise the limit, deny reads of credential files with permission rules, and keep ~/.claude/projects/ out of unencrypted backups.
And if you'd rather keep nothing, CLAUDE_CODE_SKIP_PROMPT_HISTORY stops writing transcripts and prompt history, --no-session-persistence does the same for a single -p run, and claude purge wipes what is stored for one project.
What I picked
365 days. A year covers nearly every time I go back to an old decision, and the disk use and the secrets stay manageable.
Funny that a tool which holds your whole project in its head forgets its own history after a month.
The details are in the Claude Code docs. I collect findings like this on Promtime, the news site I edit.
Top comments (3)
Three and a half months in is about when people notice, usually the day an old session was supposed to explain a decision. We stopped relying on the local transcripts for that and keep every session word for word somewhere that doesn't expire. Disclosure: I build brethof-brain, which does that and curates the current state from it, but the settings change you describe is the fix everyone should make on day one.
The security side is where the 30-day cutoff actually makes sense. Keeping transcripts for a year without locking down tool permissions means any credential touched during an exploratory run sits in plain jsonl indefinitely. I set
cleanupPeriodDaysto 180, but paired it with strict path denies in settings for env files and credential directories so the transcripts don't become an unencrypted key dump.Agreed, that's the real trade-off. Raising the limit without the deny rules just swaps losing history for keeping secrets on disk.