cleanupPeriodDays default of 30 silently destroys the only evidence a user has of a behavior change

Problem

~/.claude/projects holds the JSONL transcript of every session — timestamped,
with the model recorded per message. It is the only local record of how Claude
actually behaved over time.

cleanupPeriodDays defaults to 30, so that record is a rolling 30-day
window that deletes its own history. Deletion is silent: no warning, no
summary retained, no indication on any subsequent run that data existed and is
now gone.

The consequence is specific and self-defeating: a user who notices a
behaviour change across a model transition can never substantiate it, because
by the time a regression is noticeable enough to report, the baseline it would
be measured against has already been deleted. The reports that reach you are
therefore structurally limited to unfalsifiable impressions — which is the least
actionable form the feedback could possibly take.

I hit exactly this. I built tooling to measure quality drift across
opus-4-8 → opus-5 from my own transcripts. It only worked because I happened to
check the setting roughly three weeks before my July baseline would have
rotated away. Had I looked in October, the comparison would have been
permanently unreproducible — and no error, log line, or prompt would ever have
told me why.

Why the default is doing real harm

• 30 days is shorter than the interval between model releases, so the default

guarantees that cross-model comparison is impossible for anyone who hasn't
pre-emptively changed it.

• The setting is not discoverable from the failure. There is no failure. The

data is simply absent.

• Transcripts are small relative to what they enable. My live directory is

162 MB; the 105 sessions I've archived compress to 46 MB — trivial next to
any modern dev toolchain's cache.

• It disproportionately destroys longitudinal data, which is the only kind

that can answer "did this get worse," while leaving recent data — which
answers nothing on its own — intact.

Reproduce

1. Fresh install, don't touch settings.
2. Work for two months across a model transition.
3. Try to compare the first month against the second.

The first month is gone. Nothing recorded that it was deleted.

Suggested fixes, roughly in order of preference

1. Raise the default to something past a release cycle — 180 days. Simplest

fix, no new surface area.

1. Retain a metrics summary on deletion. Even if raw transcripts must

rotate, keep an append-only per-week/per-model rollup: request count,
token totals, tool-call counts. Counts only, no message content, so it
carries no privacy or secret-leakage risk. Kilobytes per year. This
preserves the ability to detect drift without preserving the transcripts
themselves, and is probably the right answer.

1. Warn once, before the first deletion. "N sessions older than 30 days

will be deleted; set cleanupPeriodDays to keep them." Makes the setting
discoverable at the only moment it matters.

1. Surface it in claude doctor alongside the retention window and current

on-disk size.

I'd take (1) and (2) together: raise the default, and make the rollup
unconditional so the signal survives even for users who deliberately want
aggressive cleanup.

Note on the raw data

Argument against long retention: raw transcripts contain secrets. Mine held a
wifi password, personal email addresses, and infrastructure variable names —
none deliberately. That's a genuine reason to be careful about the transcripts,
and a good reason to prefer fix (2): the counts-only rollup has none of that
exposure and retains everything needed to detect a change over time.

Context

Tooling that works around this, and the measurement that motivated it:
https://github.com/koreyshirey/claude-regression