Retrieved article excerpt
Open article · Retrieved 2026-10-04T16:42:27.588121+00:00
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 in a background sweep
The setting is `cleanupPeriodDays`, a top-level key in `~/.claude/settings.json`. The [settings reference](https://code.claude.com/docs/en/settings-reference#cleanupperioddays) gives the default as 30 days and the minimum as 1, and says setting `0` fails validation. It also says how the deletion runs: as a background sweep after a session starts, with no message, so an old session just stops showing up in `/resume`. When I first wrote this in June the docs said “deleted at startup”. The effect on your files is the same either way. The 30-day default is stated outright in the docs, so that part is documented, not my inference.
“Logs” here is narrower than all of `~/.claude`. The core of 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). Per the Claude Code changelog, `tasks/`, `shell-snapshots/`, and `backups/` joined the sweep in v2.1.117. So what’s at risk is mainly your chat-session history.
The [`.claude` directory docs](https://code.claude.com/docs/en/claude-directory#cleaned-up-automatically) name more than I did in June: `file-history/` and `plans/` are among the swept paths too, along with debug logs, the paste cache, and orphaned worktrees. I can’t tell which of those are new and which I simply missed. Under `projects/`, the docs say it keeps your auto memory folder, `projects/<project>/memory/`, as well as the Claude Desktop and Cowork transcripts covered below. Before v2.1.228 the sweep treated folders inside the memory folder as session data and could delete old files in them.
Two exceptions are worth knowing:
- **Claude Desktop and Cowork sessions are kept by default.** Since Claude Code v2.1.248, the sweep keeps the transcript of any session you started or last continued in Claude Desktop or Cowork, at any age. The changelog calls this a fix for those sessions “disappearing after 30 days”. A new setting, `desktopSessionCleanupPeriodDays`, puts an age limit back on them, though never a shorter one than `cleanupPeriodDays`. Sessions you run anywhere else, the terminal or an IDE, still follow `cleanupPeriodDays`.
- **Your organization can override you.** If managed settings set `cleanupPeriodDays`, that value wins over yours, and it applies to the Desktop sessions too.
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 by some sweep. 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
No transcript 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 the tree itself shows it. Eight of my project folders under `projects/` were created between January and April 2026, and not one of them holds a transcript older than May 5 [*measured* 2026-09-30, folder creation times]. The folders outlived the files in them. I was working in Claude Code that whole stretch; the transcripts from those months are just gone.
When I first wrote this, I used `file-history/`, Claude Code’s record of the edits it makes, as the proof. 150 of its files carry modified dates in March and April, back to March 3. That was the wrong clock. Those dates came from the files Claude Code copied, not from when it copied them: 124 of the 150 were written to disk more than a day after the date they carry, and the earliest was written on April 12 [*measured* 2026-09-30, file creation times]. Every `file-history/` session folder was last changed on or after May 6, right at the transcript floor, so it doesn’t show the sweep leaving it alone either.
The git history says the same from the project side. In my public chat-arch repository, commits predate the oldest surviving May session transcript. And `shell-snapshots/`, swept on the same clock as the transcripts, bottoms out around the same period too, a second swept corpus hitting the same wall. Private client repositories are excluded from this public comparison.
Put them side by side and the shape is clear: project folders going back to January, 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 took every older transcript while the project folders that held them stayed. 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, unless your organization sets `cleanupPeriodDays` in managed settings, which wins. 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.” That’s still true in September 2026 for sessions you run outside Claude Desktop and Cowork. Sessions from Claude Desktop and Cowork are the exception above, on v2.1.248 or later.
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](https://brycewatson.com/blog/26-building-command-operator) 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.
## Revision log
What changed on this page and how it was checked
**2026-09-30.** Re-checked against the current Claude Code docs and changelog, with Claude Code 2.1.280 on this machine.
- **Corrected what the sweep covers.** The post said it doesn’t touch `file-history/` or `plans/`. Current docs list both as swept, so I’ve said so.
- **Withdrew the file-history evidence.** The post used 150 `file-history/` files dated March and April as proof that my history predates the transcript floor. Those are modified dates copied from the edited files, not the dates Claude Code saved them: the earliest was written to disk on April 12, and every file-history folder was last changed on or after May 6. The proof is now the eight project folders created between January and April that hold no transcript older than May 5.
- **Added the Claude Desktop and Cowork exception** from v2.1.248, and the `desktopSessionCleanupPeriodDays` setting that caps it.
- **Added that managed settings override yours**, that `desktopSessionCleanupPeriodDays` can’t go below `cleanupPeriodDays`, and that auto memory is kept (before v2.1.228 the sweep could delete files in folders inside it).
- **Updated how the deletion runs.** The docs now describe a background sweep after a session starts, not deletion at startup. The description changed to match.
- **Fixed the docs link**, which pointed at a section of the settings page that has since moved to its own reference page.
The 30-day default, the minimum of 1 and the rejection of `0` are unchanged. I didn’t run a fresh sweep on the default setting to watch what it deletes today, so the list of swept paths comes from the docs, not from my machine.