Default 30-day auto-cleanup silently and irreversibly deletes chat transcripts — no UI control, no warning, no recovery path

Resolved 💬 2 comments Opened Jun 3, 2026 by suenamis Closed Jun 3, 2026

Preflight Checklist

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

What's Wrong?

The default behavior of cleanupPeriodDays (30 days) silently and permanently removes chat session transcripts (.jsonl files) from ~/.claude/projects/<project>/ and the equivalent Desktop-app paths under %APPDATA%\Claude\. For users who rely on past sessions to continue long-running work, this is data loss that arrives with zero warning and no way to recover.

I just lost the entire transcript history of two important sessions I had explicitly kept as reference threads for ongoing work — they were 44 and 52 days old and were deleted by today's scheduled cleanup with no notification. The project's auto-memory MD files survived and helped, but the actual conversation flow — including specific decisions, tried-and-rejected approaches, and the back-and-forth that gives context to those decisions — is gone.

Specific UX gaps that make this painful:

  • No UI surface. cleanupPeriodDays exists only in settings.json. The Desktop app's settings UI doesn't expose it, so users can't even discover the setting until after the data loss.
  • No warning before cleanup runs. Sessions are unlinked with no toast, no confirmation, no preview list.
  • No soft delete / no Recycle Bin. Files are removed via fs.unlink, bypassing the Windows Recycle Bin entirely. No built-in undo.
  • The schema rejects cleanupPeriodDays: 0 (the obvious "never clean up" value) with a hint to set a large number instead. That validation error is the only place I discovered the workaround exists.
  • A 30-day default is too aggressive for a tool marketed as a long-running collaborative agent. Most users assume their sessions persist indefinitely.

What Should Happen?

  1. Expose cleanupPeriodDays in the Desktop settings UI with a clear label ("Keep chat transcripts for") and a "Never delete" option.
  2. Default to a much longer retention (365 days or "Never delete"), and require explicit opt-in to anything shorter.
  3. Move deleted transcripts to the OS Recycle Bin / Trash instead of permanent unlink. Recovery becomes trivial.
  4. Warn before the first cleanup of a given session: a one-time notification with an option to pin specific sessions.
  5. Per-session "keep forever" pin (right-click → "Pin / Never auto-delete").
  6. Accept cleanupPeriodDays: 0 as "never clean up" instead of rejecting it — match user intent.

Error Messages/Logs

Steps to Reproduce

  1. Use Claude Code Desktop on Windows.
  2. Have multiple sessions on a project that you return to occasionally.
  3. Let one of them sit untouched for more than 30 days.
  4. Start Claude Code; the auto-cleanup runs at startup and the transcript .jsonl files are unlinked from disk.
  5. Open the affected session in the Desktop UI: only the metadata shell remains (title, cwd, sessionId) showing "Session not found on disk" / "Sitzung nicht auf dem Datenträger gefunden". The chat content is gone with no warning, no Recycle Bin entry, and no way to recover from within the app.

Claude Model

None

Is this a regression?

No, this never worked

Last Working Version

_No response_

Claude Code Version

2.1.156

Platform

Other

Operating System

Windows

Terminal/Shell

PowerShell

Additional Information

Workaround currently in place: cleanupPeriodDays: 36500 (~100 years) in ~/.claude/settings.json to effectively disable auto-cleanup. Required reading the schema validation error to discover — not surfaced anywhere else in the UI or default configuration.

Thank you for the genuinely excellent tool — this is the kind of polish that would make it noticeably less stressful to rely on for long-running work.

View original on GitHub ↗

This issue has 2 comments on GitHub. Read the full discussion on GitHub ↗