Español

Your History Is Deleted In 30 Days

Try to resume a session from two months ago. It isn't there. Not archived, not compressed — deleted, by a timer you never configured, with nothing to tell you it was about to happen.

A retention sweep you didn't opt into

Session transcripts are stored locally, in plaintext, under ~/.claude/projects/, so that sessions can be resumed. They are also swept on a schedule: the retention period is cleanupPeriodDays, and it defaults to 30 days.

The cleanup runs at startup, removing files older than the period. There's no warning and no confirmation, which is why most people discover the behaviour by noticing an absence — a resume list that's suspiciously short, or a specific conversation they went looking for and couldn't find.

Thirty days is a sensible default for what it's designed to do, which is stop a cache of plaintext transcripts growing without bound on your disk. It's a poor fit for the way people actually use these sessions, which is as a record of how a hard problem got solved.

Change it in one line

Set the period in your settings file:

{
  "cleanupPeriodDays": 365
}

That keeps a year. The setting can live at any settings layer — user, project, local, or managed policy — so you can raise it globally in ~/.claude/settings.json or per-project where the history is worth more.

Do this before you need it. Retention is not retroactive: raising the number today does nothing for the sessions that were swept last month. They're gone from local disk, and this is the one setting where reading about it and not acting has a deadline attached.

What survives the sweep, and what doesn't

The sweep is not indiscriminate, and the distinction is useful.

Exempt: the auto-memory directory. Notes the agent saved about your preferences, your corrections, and project context are excluded from the retention sweep. MEMORY.md and its topic files stay until you or the agent edits or deletes them.

Not exempt: the conversations themselves. Also swept on the same schedule are the /insights HTML reports, and agent-team task lists.

So the durable layer is the one the agent curates, not the one you lived through. Anything you'd want to reread — the reasoning, the dead ends, the actual debugging — is in the transcript, and the transcript is what expires.

Don't rely on the transcript as your record

Raising the number is the immediate fix, but the deeper habit is not treating a resumable session as documentation. Even with a year of retention, a transcript is a poor place to keep a conclusion: it's long, unstructured, machine-local, and invisible to everyone else on the team.

When a session produces something worth keeping, move it somewhere durable while you still have it in front of you:

• A gotcha the next person will hit belongs in the rules file.
• A decision with alternatives considered belongs in an ADR.
• A repeatable procedure belongs in a skill, where it can actually be re-run.
• A fact about how you work belongs in auto memory — which is exempt from the sweep anyway.

There's also a practical dependency worth knowing: /insights analyses your recent sessions to report on how you work and where things go wrong. It can only analyse sessions that still exist. Aggressive retention quietly limits that tool to whatever survived.

The takeaway

Your best debugging session has an expiry date, it defaults to 30 days, and nothing warns you. Set cleanupPeriodDays to something you're comfortable with today, since the setting can't recover what's already been swept. Then stop relying on transcripts as memory: the notes the agent saves are exempt from the sweep, and the conclusions you write down are exempt from the whole problem.