[BUG] Claude Code silently deletes conversation transcripts after 30 days by default

[joelhochstetter]

Preflight Checklist

• I have searched existing issues and this hasn't been reported yet
• This is a single bug report (please file separate reports for different bugs)
• I am using the latest version of Claude Code

What's Wrong?

cleanupPeriodDays defaults to 30, causing Claude Code to silently delete
~/.claude/projects//.jsonl files older than 30 days on
startup. There is no first-run disclosure, no warning before deletion, and the
setting is not surfaced in /config. I lost months of conversation history
before realizing this was happening.

Repro: Use Claude Code for >30 days without setting cleanupPeriodDays. Old
transcripts disappear.

Evidence on my machine: ~/.claude/history.jsonl shows 14 sessions / 1,315
prompts for one project from March–April. Only the current session's .jsonl
survives in ~/.claude/projects/. The cutoff matches the 30-day default
exactly. My settings.json does not override the default.

Impact: The code and git history remain, but the reasoning trail — design
discussions, debugging context, analysis — is gone. For research work that
context is the artifact.

What Should Happen?

Requested:

1. Change the default to non-destructive (disabled, or very long retention).
2. Disclose at first run; require opt-in for auto-deletion.
3. Soft-delete to a trash folder instead of unlink().
4. Surface the setting in /config.

Workaround for others: add "cleanupPeriodDays": 3650 to
~/.claude/settings.json immediately.

Error Messages/Logs

Steps to Reproduce

Use Claude Code for >30 days without setting cleanupPeriodDays. Old transcripts disappear.

Claude Model

None

Is this a regression?

I don't know

Last Working Version

No response

Claude Code Version

2.1.150

Platform

Anthropic API

Operating System

Ubuntu/Debian Linux

Terminal/Shell

Other

Additional Information

No response

[AiTrillium]

Adding evidence + an IP-sovereignty framing + a consolidated recommendation

Update 2026-06-04: #59248 is now the more-developed consolidation thread — @ojura's root-cause analysis, cross-platform reports (macOS/Windows/Linux), and several recovery efforts. I've posted our boundary-precise mtime evidence + ~900-session reconstruction datapoint there and recommend consolidating discussion at #59248. The cross-reference table below is updated to reflect this.

Confirming this on claude-opus-4-8 / Claude Code as of 2026-05-30, with reproducible on-disk evidence, and offering a constructive recommendation set.

Reproduction / evidence (deterministic). With no cleanupPeriodDays set (i.e., the 30-day default), on 2026-05-30 the oldest surviving transcript under ~/.claude/projects/ was dated exactly 2026-04-30 — the 30-day boundary, to the day. Everything older was gone, including a session of real value to us (a 16-hour build of an internal tool). No prompt, no notification, no confirmation preceded the deletion at any startup. We verified against the official claude-directory.md docs: "Files … are deleted on startup once they're older than cleanupPeriodDays" — with no mention of user notification, and no recovery mechanism (no trash, no archive, no export, no claude --recover).

Why this is more than an inconvenience. For paying users who treat their sessions as intellectual property — design reasoning, prompt history, hard-won context — this is silent, unconsented destruction of user-owned data. The transcripts are the user's record of their own thinking and work; deleting them by default, silently, with no recovery, inverts the expected ownership relationship. A 30-day default that quietly discards months of accumulated reasoning is a poor default for that audience, however reasonable it is for disk hygiene in the general case.

The mitigation is currently unreliable (see #62272). Setting cleanupPeriodDays high does not appear to guarantee retention — deletion has been observed despite a high value, apparently on update/restart. So even users who find the setting cannot fully trust it.

Pointed-yet-constructive recommendations (roughly in priority order):

1. Consent before destruction. Make the first destructive cleanup opt-in, or at minimum show a one-time, dismissible notice ("Claude Code will delete transcripts older than N days; configure or disable here") before anything is deleted. Silent-by-default deletion of user IP is the core defect.
2. Recoverable trash, not hard delete. Move aged transcripts to a ~/.claude/trash/ (or OS recycle bin) with a grace window, instead of unlinking them. This alone would have prevented every loss in this thread.
3. Honour the setting reliably (fixes #62272). A high cleanupPeriodDays must actually prevent deletion across updates and restarts — otherwise the knob is decorative.
4. Pinning / retention exemption (aligns with #63842). Let users mark sessions as "keep forever," exempt from cleanup.
5. Export-on-cleanup. Optionally emit a compact Markdown/JSONL archive of a session to a user-chosen location at the moment it would otherwise be deleted.
6. Make the default discoverable. Surface cleanupPeriodDays (and its full sweep scope — see #51779, #38576, #63777) prominently in onboarding/docs; 30 days of silent deletion should not be something users discover only after losing data.

Happy to help test any of the above. The fact that we had to build a forensic recovery tool to reclaim sessions from local storage — and then watched the tool's own build session get auto-deleted — is the cleanest possible argument for items 1–2.

FYI: Cross-reference the feature/doc issues...

#	State as of 2026-05-30	Title	Role
#59248	open	Silent retention cleanup deletes session transcripts with no warning, opt-in, or recovery	Consolidation hub (most developed) — @ojura's mtime/settingSources root-cause; macOS/Windows/Linux; recovery efforts; our evidence posted here.
#62476 (this)	open	[BUG] Claude Code silently deletes conversation transcripts after 30 days by default	This thread; superseded as the working thread by #59248 (see Update above).
#62272	open	[BUG] Chat JSONLs deleted despite cleanupPeriodDays set high — appears triggered by updates/restarts	Critical — implies the §B mitigation is not fully reliable; reference + add evidence.
#63842	open	[FEATURE] Selective session retention: pin/bookmark important sessions	Feature direction — endorse + cross-link.
#51779	open	[DOCS] cleanupPeriodDays retention docs omit tasks, backups, shell-snapshots	Doc-scope gap.
#38576	open	[DOCS]cleanupPeriodDays docs omit tool result files from cleanup scope	Doc-scope gap.
#63777	open	[DOCS] swept-paths table omits .claude/worktrees/	Doc-scope gap.

[AiTrillium]

Cross-reference for anyone triaging: #59248 has become the more-developed thread on this bug — it carries @ojura's root-cause analysis (unlinkIfOld mtime-keying + the settingSources override that defeats a high cleanupPeriodDays), spans macOS/Windows/Linux, and collects several recovery efforts. I've added our boundary-precise evidence and a reconstruction datapoint there. Suggest consolidating discussion at #59248 so maintainers have one place for root cause + fixes.

[blain3white]

For a stopgap until a native retention option ships: I wrote Clean My Agent to back up Claude Code's session JSONLs on demand — keeps a safe copy before the 30-day window closes.

[fingoldo]

I've just lost valuable work (Claude code conversations and plans), probably because of cleanupPeriodDays default setting that silently deletes Claude sessions inactive for more than a month.

I can not call such default value anything other than idiotic. I think it should be

1. reverted to a safe value such as None, or -1, or 0, meaning NO truncation.
2. IF a user opts in by explicitly setting integer value above zero, use additional security precautions:
   2.1) use temporary folder similar to "Recycle bin" where conversations due to be deleted are stored in archived format for 1 extra month
   2.2) use weekly OS and email notifications warning user that some of their files have been archived and will be permanently deleted soon.
3. I'm a Claude for VS code user. All settings mentioned above should be exposed as UI elements, like [FEATURE] VS Code Extension: Add setting to configure "Past Conversations" time limit #13064 suggested. Why was that issue closed without any comment from the team? A real problem was surfaced on top of an even bigger problem. Wake up already, Anthropic, and stop ignoring your paying customers.

I'm tired of you ignoring user feedback. Over last 2 months, your product (Claude for VS Code) has been only deteriorating (i'm tired of Claude messaging disappearing from chat after 1-2 seconds, of models unable to focus on simple tasks, unable to follow the rules file, and so on), and now it has hit me with silent deletion of my valuable work.

If you at Anthropic don't value your sessions and are ready to throw everything to the thrash bin after 30 days, that's not the case for me and, i'm sure, for the majority of programmers who use your product.

Do NOT silently decide for me which of my projects you can permanently delete.

I often see Boris Cherny @bcherny giving interviews and bragging how 200 Claude agents are working for him while he is at the interviews, but I do not recall him ever mentioning he is gathering Claude user feedback and doing anything about it. I encourage Boris (or his agent, to that extent) to comment on why he thinks cleanupPeriodDays should silently stay 30 days and keep doing what it does the same way it does, and maybe even more importantly, why he thinks it's acceptable to ignore requests such as #13064 or this #62476 and leave them without any attention.

Dario once said in in his interview about leaving OpenAI:

When you feel that their values are not they say they are, when you feel that they are not honest, it makes it very hard to continue to work with the company.

Now i'm feeling the same about your own company, Dario. I can see it's an ongoing trend that Anthropic ignores feedback of its customers. In what universe is that a good thing?

[caioribeiroclw-pixel]

Adding one implementation-shaped boundary rather than another loss report, since this issue is now getting HN attention.

I don't think “users can back up ~/.claude” is a sufficient answer. Backups are good hygiene, but they don't replace product-level disclosure/provenance for a destructive retention sweep.

A useful acceptance test would be:

1. create a project with transcripts older than cleanupPeriodDays
2. start Claude Code with default settings
3. assert it either does nothing until explicit opt-in, or moves files to a recoverable trash/export first
4. assert the user can see a cleanup receipt before/after the sweep

Minimum receipt fields that would make this debuggable:

• Claude Code version + run timestamp
• effective cleanupPeriodDays and which settings source provided it
• matched transcript paths/count/date range
• action taken: kept / archived / trashed / permanently deleted
• restore path/window if archived or trashed
• the exact config command/UI path to change retention

That separates three states that currently collapse into “history is gone”: no transcript ever existed, transcript was intentionally archived, or transcript unexpectedly disappeared. It would also make future bug reports much easier to triage without asking users to reconstruct filesystem state after the fact.

[jerzygangi]

I'm also having this issue. It is high priority, in my opinion.