"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."
Those users would be wise to back those files up if they consider them valuable intellectual property. If they're important enough that you'd miss them after a disk failure, then they should have been being backed up already.
>if they consider them valuable intellectual property [...]
It's hard to take any of what's written seriously, given that it's all AI generated. Did the user actually lose "valuable intellectual property", or did they tell claude to write as dire of a justification as possible?
I got bitten by this. I sometimes check past sessions for "prompt I used to do X". I consider the LLM output to be mine as well, as it's something I paid for. Nothing should be deleted without my knowledge and approval.
Isn’t “Anthropic won’t fix it” a little sensational for barely month old issue with little activity(two upvotes, one of which is me), in backlog of 5k+? Agree that it’s a real issue that need fixing however
- it is silent, not announced anywhere, and calls rm on your data
- setting the days to zero doesn't disable it, it immediately rm's ALL your chats
- even setting it to _something_ big doesn't prevent data loss if you launch Claude Code in some modalities (certain subagents, etc) that don't load this config key but perform deletion anyway (with the 30 day default)
I just noticed that it’s a config option. Weird that it’s so short though, I can understand why it may be needed for users who spawn hundreds of sessions a day
Wow good timing, I’ve been working on a session hub of sorts for devs. Check it out, you can store your sessions on here. https://joe-store-frontend.onrender.com
The best mitigation I've found against this is training Claude to collate what it does within the project dir, specifically a CLAUDE.md vision file and .claude/changelog that documents the changes it makes. The biggest pain point though is remembering to force it to do that between sessions (man is that contextual memory unreliable sometimes).
Oh yeah - it commonly doesn't update my BACKLOG.md after shipping something. It tends to catch itself on the next set of work, but sometimes I have it clean up based on recent commits.
Have you tried using hooks? I have a similar changelog except I write it to a SQLite database for searchability across all my sessions. I use the Stop/StopFailure hooks and it reliably writes to the change log. I used to just use CLAUDE.md instructions for this, but as you've experienced it's not completely reliable.
This literally hit me just last night. Went to continue a project I haven't touched in a while and couldn't find the session, which I wanted to continue from as it's a cheap way to track token cost at the project level. Many missing sessions, then Claude told me what was up and I had it configure retention for 10,000 years.
This is clearly shown in the settings/config (or at least was last time I looked), if people are surprised by this I recommend asking claude code what settings you can tweak
Why ask for what settings you can tweak? It's supposed to be the case that the defaults are good for many, and then when something needs tweaking you ask about it at that point. And still though this 30 day limit might be good for many, it's actually pretty bad overall because it leads to irreversible loss for those who it isn't good.
Except that those customers can access the traces for 30 days, and freely copy them at any point during that period? It's a usability issue at worst, not some anti-customer conspiracy.
Those users would be wise to back those files up if they consider them valuable intellectual property. If they're important enough that you'd miss them after a disk failure, then they should have been being backed up already.