Default 30-day cleanupPeriodDays silently hard-deleted ~950 session transcripts (no warning, no trash) — please add safeguards

Environment

• Claude Code 2.1.158 (CLI + Windows desktop app), Windows 11 Pro, NVMe SSD (TRIM enabled)
• Daily use since 2026-04-10, ~1,000 sessions across multiple project roots

What happened

The default transcript retention (cleanupPeriodDays, default 30 days) hard-deleted the local session-transcript store in bulk, with no warning and no recycle-bin/trash stage:

• For months the cleanup effectively did not run (verifiable via file inventories: on 2026-07-12 the store still contained 995 transcripts dating back to mid-April, far beyond 30 days).
• Around 2026-08-06 (app start after a period of inactivity, presumably following an update), a sweep deleted roughly 950 transcripts covering 2026-04-15 → 2026-07-09 in one pass — including 917 transcripts of programmatic/agent runs and months of research conversations.
• On 2026-08-09 10:26 (local) a second sweep on app start removed the remaining ~160 July files (.last-cleanup timestamp matches).
• The deletion is a hard delete (no recycle bin). The desktop app's own session register (%AppData%\Roaming\Claude\claude-code-sessions\...) keeps title metadata and then flags transcriptUnavailable: true — so users still see their session titles but the content is gone, which makes the loss confusing to diagnose.

Impact

• Months of long-running research conversations lost locally; discovered only when trying to reopen sessions.
• On a TRIM-enabled SSD, file carving (winfr) recovers nothing. We ultimately recovered most transcripts only because (a) Windows VSS shadow copies happened to cover the most recent sweep, and (b) the user had made independent manual backups of ~/.claude earlier in the summer. Users without such luck lose everything silently.

Requests

1. Warning before destructive cleanup — especially when a sweep would delete a large number of transcripts (e.g., after the cleanup was dormant and a backlog accumulated). A one-line prompt ("about to delete N transcripts older than X days — continue? [y/N]") would have prevented the entire incident.
2. Soft-delete stage — move to a trash/archive folder (or OS recycle bin) instead of hard unlink, even if only for N days.
3. Surface the setting — cleanupPeriodDays deserves prominent mention in docs/getting-started and a line in /doctor output showing current retention and next-sweep effect.
4. Reconsider the default — 30 days of silent hard deletion is aggressive for a tool whose transcripts are often the primary record of long-running work. A much longer default (or no deletion by default, with size-based prompts) would be safer.
5. Log what was deleted — a summary line (count, date range, per-project) in a log file would make incidents diagnosable after the fact.

Notes for other affected users

• Check Windows VSS shadow copies ("Previous Versions") quickly — recent sweeps may still be recoverable from a shadow of C:\Users\<you>\.claude\projects.
• Your session titles survive in %AppData%\Roaming\Claude\claude-code-sessions\ (cliSessionId field maps register entries to transcript filenames) — useful for inventorying what was lost.
• Set "cleanupPeriodDays": <large number> in ~/.claude/settings.json to stop further deletion.

Thanks for looking into this — happy to provide sanitized file inventories/timelines if helpful.