Critical: Claude Code silently deletes conversation history without user consent

[vstoyanov]

Severity: Critical — silent, irreversible data loss

Description

Claude Code automatically prunes (deletes) old .jsonl conversation files from ~/.claude/projects/*/ without any user consent, notification, or configuration option. Users discover their conversation history is gone only when they try to --resume an old session.

Evidence

On an Arch Linux system running Claude Code installed via AUR, upgraded through versions 2.1.85 → 2.1.101 over March–April 2026:

• 10 conversation sessions spanning 2025-11-22 to 2026-02-07 for a single project were silently deleted
• The .jsonl conversation files are completely gone from disk
• In newer versions, a sessions-index.json is written to preserve metadata about deleted sessions — but for projects where pruning happened before that feature was introduced, even the metadata is lost
• The only surviving record is prompt text in ~/.claude/history.jsonl (no assistant responses preserved)
• Cross-checking all projects on the system confirms the pattern: sessions-index.json entries and on-disk .jsonl files are always disjoint sets, proving systematic pruning

Observed behavior across multiple projects

HAS index  | entries=1 | jsonls=4 | backoffice
HAS index  | entries=0 | jsonls=3 | collector
NO  index  | jsonls=2 | rq-backtest          <-- no index, all old sessions gone
HAS index  | entries=4 | jsonls=6 | fluxcd
HAS index  | entries=1 | jsonls=3 | trade-track-pilot

In every project, index entries reference session IDs with NO corresponding .jsonl file, and .jsonl files on disk are NOT in the index — confirming the index is a tombstone for already-deleted conversations.

Expected behavior

1. Never delete user data without explicit consent. Conversation history is the user's data.
2. At minimum, provide a configurable retention policy (e.g., sessionRetentionDays in settings.json) with a default of unlimited.
3. If pruning is deemed necessary, warn the user before deletion and offer an archive/export option.
4. Provide a claude sessions list / claude sessions export command for users to manage their own data.

Environment

• OS: Arch Linux (kernel 6.19.11-zen1-1-zen)
• Claude Code: 2.1.101 (installed via AUR)
• Upgrade path: 2.1.85 → 2.1.86 → 2.1.88 → 2.1.92 → 2.1.97 → 2.1.98 → 2.1.101

[github-actions]

Found 3 possible duplicate issues:

1. [BUG] cleanupPeriodDays: 99999 ignored — 490 sessions silently deleted despite explicit setting #41458
2. Bug: --setting-sources local causes cleanup to ignore cleanupPeriodDays, silently deleting conversations globally #45903
3. [BUG] data loss through bad default settings #22547

This issue will be automatically closed as a duplicate in 3 days.

• If your issue is a duplicate, please close it and 👍 the existing issue instead
• To prevent auto-closure, add a comment or 👎 this comment

🤖 Generated with Claude Code

[vstoyanov]

Any updates on this???

[tudstudent]

Worthless, happens all the time.
Why not make this user configurable...
If you pause a project for 3 weeks all logs gone....

[drvonkitty]

i am devastated to find out that i lost thousands of messages across multiple contexts to this default behavior. there isn't even any recourse for those of us reporting this issue, because the data is permanently destroyed now. meanwhile i'm not sure what the purpose of automatically deleting the conversation history is -- these aren't gigantic files, and they're stored locally on the user's computer anyway. what's the point of storing the data on disk if there's going to be a 30 day retention policy as the default setting? at the VERY LEAST, make it 365 days or some reasonable period where user inactivity might be indicative of SOMETHING. 30 days is nothing, and the fact that there's no warning or way of knowing this setting unless you just so happen to read something buried in the middle of this page? it is baffling.

even if this policy is changed going forward -- which i strongly believe NEEDS to happen, because this is a critical issue that absolutely will burn more people going forward if unresolved -- it won't do anything to bring already-deleted conversation history back. not everyone constantly opens new sessions... the auto-compact even lends itself to having long-running, expansive contexts, regardless of whether this is "intended" or not. i am really, really disappointed by this. it is an irreversible violation of user consent and best data retention practices. anthropic ought to fix this and apologize to those of us for whom there is no fix available.

[emilrueh]

I too am devestated to have just found out about this completely unreasonable hidden default setting after having lost dozens of conversations of oingoing tasks in my projects after having been away for a mere month. Why would anybody think this is a good thing to implement??

Also considering the subagents/ .jsonl files are not being deleted although nobody needs those!