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

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](mailto:aitrillium@gmail.com?subject=CR%20Early%20Access&body=Hi,%20I%20would%20like%20early%20access%20to%20the%20forensic%20recovery%20tool%20for%20Claude%20Code.) 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. |

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.

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.

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 #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?

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.

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

@karpathy can you help with getting some feedback maybe?

(writing this by hand, for how high-pri this is for me)

I just got burned by this, and I'm extremely upset. I thought I was accumulating months of Claude transcripts, which I could eventually mine to extract patterns to encode my decisionmaking into Claude as skills so it could be more autonomous.

I tried doing that today... and got the awful surprise that everything beyond 30 days had been deleted.

This is horrible, horrible UX. I didn't ask for this. I wasn't notified of this. That data from those hundreds of hours of interacting with Claude are now just gone.

@bcherny , bunch of people are getting nasty surprises here

This week i'll try reaching out to Dario and Daniela, to make sure that ignoring clients feedback stems from them (most likely it does). I am really surprised they expect to build anything great without listening to their customers, even, it seems, deliberately IGNORING their customers, instead of taking our valuable feedback and improving their product quickly.

Opened 2 cases with Anthropic's website support, one small payment problem, another one technical (this exact one), NONE got answered. Remarkable.

I have never seen such a company before in my entire life, with no responsibility whatsoever.

Is there any way to confirm that Claude is reading my setting in settings.json properly?

I just learned about this the hard way (coming back to a project on rarely used remote machine). Please can 30-day default be changed to infinite retention of local session history by default? No other harness I know off deletes sessions by default and this is imho unexpected behavior that should be changed or at least clearly communicated to the users.

Adding another data point: ~2 months of session history silently deleted on macOS desktop. What makes this worse: (1) archived sessions are not exempt — the archive label survives but the transcript is destroyed, so the session list is full of "session not found on disk" ghosts; (2) there is no UI surface for this setting at all — no onboarding prompt, no toggle in desktop settings or /config, just an undocumented-feeling JSON key. Local user data should never be hard-deleted by default without a visible, upfront control and a warning before first cleanup. At minimum: prominent retention toggle, archive = exempt, and soft-delete/trash instead of unlink.

Verified on v2.1.233 (Linux, native build), black-box:

• Fresh config dir, a session transcript under projects/ backdated 40 days: it was deleted during a run with default settings.
• Same setup with {"cleanupPeriodDays": 3650} in settings.json: the file was kept.
• The deletion happens in a background sweep a few seconds after startup, so very short runs may not trigger it — but any normal session will.
• /config does not show this setting on 2.1.233; it can only be set in settings.json.

This is the documented default, not a malfunction: https://code.claude.com/docs/en/settings says cleanupPeriodDays — "Default: 30 days, minimum 1. Claude Code deletes session files and other application data older than this period at startup", and https://code.claude.com/docs/en/data-usage notes transcripts are kept locally "for 30 days by default".

To keep transcripts longer, add "cleanupPeriodDays": 3650 (or another number of days) to ~/.claude/settings.json.

The requests for a first-run disclosure, a warning before deletion, and surfacing the setting in /config are feature requests rather than a bug — leaving this open so those can be considered.

🤖 Generated with Claude Code

Thanks for verifying the behaviour. However, this characterises the wrong alleged defect.

The report does not claim that cleanup is failing to follow its documented default. The defect is that Claude Code silently and permanently deletes locally stored user transcripts by default without any in-product disclosure or opportunity to make an informed choice.

A row in an online settings reference is not advance notice of an irreversible destructive action. Your black-box test confirms every material part of the report:

• a default installation deletes transcripts during a background sweep;
• the deletion is not visibly connected to a user action;
• cleanupPeriodDays is absent from /config;
• avoiding deletion requires hand-editing a setting users have no reason to know exists;
• there is no warning, cleanup receipt, trash, grace period, or undo.

I was personally affected. When I investigated on 16 August, my surviving parent-session transcripts formed a rolling July-August window; at least May and June had already been permanently removed. I had never configured cleanupPeriodDays because Claude Code had never told me the setting or the destructive default existed. I have now set it to 3650 days, but that cannot recover months of working history.

Whether this is labelled a bug or a feature request does not change the user-safety failure. Documentation makes behaviour referenceable; it does not make a silent destructive default discoverable.

At minimum, Claude Code should:

1. disclose retention during onboarding or before the first destructive sweep;
2. show the effective value and settings source in /config or /status;
3. move transcripts to recoverable trash with a grace period;
4. write a cleanup receipt showing what was removed.

Please continue treating this as a data-loss safeguard, rather than an optional usability enhancement. Users should not discover the retention policy only after their data is gone.

Verified on v2.1.233 (Linux, native build), black-box: Fresh config dir, a session transcript under projects/ backdated 40 days: it was deleted during a run with default settings. Same setup with {"cleanupPeriodDays": 3650} in settings.json: the file was kept. The deletion happens in a background sweep a few seconds after startup, so very short runs may not trigger it — but any normal session will. /config does not show this setting on 2.1.233; it can only be set in settings.json. This is the documented default, not a malfunction: https://code.claude.com/docs/en/settings says cleanupPeriodDays — "Default: 30 days, minimum 1. Claude Code deletes session files and other application data older than this period at startup", and https://code.claude.com/docs/en/data-usage notes transcripts are kept locally "for 30 days by default". To keep transcripts longer, add "cleanupPeriodDays": 3650 (or another number of days) to ~/.claude/settings.json. The requests for a first-run disclosure, a warning before deletion, and surfacing the setting in /config are feature requests rather than a bug — leaving this open so those can be considered. 🤖 Generated with Claude Code

This reply shows that neither you nor your bots have any clue about what is going on in this thread and what your customers are talking about. Shame on you and your company. I jsut can not believe my eyes. Is THIS the level of Anthropic?

macOS, v2.1.234. Partial recovery: ~/.claude/history.jsonl survives the sweep — the cleanup only touches .jsonl files under ~/.claude/projects/, and this one sits a level above. It holds every prompt typed, one JSON object per line (display, timestamp, project, sessionId, pastedContents). Mine goes back to 2026-03-10 with 7,350 prompts against 94 surviving transcripts; cross-referencing sessionId identified 497 deleted sessions holding 5,621 recoverable prompts. Responses, tool calls and diffs are gone, but the user half is intact with timestamps and project paths, and it lines up with git log.

Two things worth knowing. A surviving transcript doesn't mean the day survived — on a partially swept day only the session still being appended to later remains, so one day here shows 1 session / 16 messages in the transcript while history.jsonl records 6 sessions and 74 prompts. Any tooling reading only transcripts will report that day as nearly idle. And ~/.claude/session-env/ isn't swept either: one directory per session, 185 here against 94 transcripts, which gives a quick floor on how many sessions existed.

Side effect: the stats panel under-reports. It's built from ~/.claude/stats-cache.json plus a live scan of surviving transcripts, and those aggregates are computed from transcripts — so any sweep before a recompute permanently zeroes those days in the cache too. Panel showed 112 active days; history.jsonl proves 129.

Also confirming the report above: mtime is unreliable. My oldest file by mtime was 19 Jul; contents reach back to 19 Jun.

I'm really angry too. Since when it is Anthropics decision to delete MY data????
No trash bin usage! The files are completely gone. Even a low level BTRFS scan does not get them back.

TL;DR - this "purge" feature is rude... You should always let devs know when you're about to destroy their work, and ask for permission/confirmation. I've lots months of important work.

---

I just came back from a month's leave and got hit by this twice! Once at home, and then again at work!

At home, I didn't realise what had happened... I opened claude agents and heaps of my convos were missing.

I didn't really think anything of it at the time... just thought "gee it's going to be really annoying finding the convos to reopen". I was still on holiday mode... so didn't do any investigation into the matter...

Then the same thing happened at work!

Luckily, I created a Claude crash recovery script/prompt, which keeps track of conversations that I don't explicitly close myself so I can easily find and reopen them after a computer restart or crash! Except when I ran it, Claude told me there were no transcripts matching the conversation ids being tracked! "Wtf!" I thought... and began to Google. This is when I learned about the retention/purge policy. 30 days! FFS!

I'm freaking devastated!

I've had convos going for months working on architectures and ideating and brainstorming... and now it's all lost!

Not just the brainstorming.... but also all the decisions made while implementing features, and all the techniques learned along the way now lost!

It's all just gone! I'm back at square one, besides the things I remember or had materialised into code or issues.

It's very rude behaviour/functionality! Not in the least helpful.

At the very least, ask!

"Hey, you have some very long and old convos that haven't been touched in 30 days. Here's the list... if you want me to delete any, just click the checkbox next to the convo, to confirm the delete"

no thanks Claude... I've just been on holidays

I think MAYBE just MAYBE, the convos that I enabled remote access are still on my phone app!

I can't interact with them because the convos no longer exist on my computer, but at least I have them for the time being....

@bcherny thank you for stopping by this issue. Please don’t just look at the feature side, look at the human side too. There is real grief in this thread. No other software wipes your data under you like that.

Another ping @bcherny and @codebytere-ant, as you interacted also on #81100. This behavior is completely unexpected, and it should never be the users' task to find out about such unexpected, permanent destructive actions. Having good, conservative defaults (opt-in to destructive actions, for example) should be a general paradigm, also followed by AI systems. This current behavior just screams ignorance and complete misunderstanding of what good UX should look like (because you seem to see this as a "feature", not a bug, and did not even seem to have realized how surreal and dystopic this is).