[BUG] Default cleanupPeriodDays silently deleted 58 of 69 session transcripts; sidebar shows ghost entries with "Session not found on disk"

Same outcome on a different platform and a different client, which suggests the deletion path is not desktop-specific. Linux, CLI only, no desktop app installed.

I run six accounts as six CLAUDE_CONFIG_DIR roots. Five of them carry no settings.json override, so they sit on the default. All six truncate at the same boundary:

root      oldest surviving transcript   files   size    cleanupPeriodDays
aron      2026-07-22                     1992   3.6G    (365, set today)
bjpang    2026-07-22                      705   1.4G    unset
int       2026-07-22                     1341   1.5G    unset
main      2026-07-23                      906   934M    unset
power     2026-07-27                      491   1.4G    unset
zava      2026-07-23                      813   675M    unset

Today is 2026-08-15. Six independently-populated roots, one shared cutoff around three weeks back, and ~/.claude/.last-cleanup stamped this morning. Note the aron root reads 365 only because I raised it today, after the loss; it was on the default while the deletion happened, like the rest.

Two things worth adding to the report:

The loss is not recoverable from anywhere local. I needed four months of usage history this week and none of it existed on disk. What made it recoverable at all was that aggregates had been submitted to a third-party leaderboard months earlier, so I could reconstruct daily and per-model figures from a public profile. Anyone who has not published their usage somewhere has no path back. That seems worth weighing against the current default, since transcripts are the only local record of what an account actually did.

Retention is by file mtime, so it deletes by last-touched rather than by conversation age. A long-running session that gets resumed keeps resetting its own clock and survives indefinitely, while a short session from the same afternoon is gone. The set that survives is therefore not "the last N days of work" but "whatever happened to be written to recently", which is a harder property to reason about than a straight age cutoff.

What I would want, in rough order of value: a one-time prompt or a startup warning before the first deletion rather than after; the setting surfaced somewhere a user can find it without reading the docs; and a default higher than 30 for .jsonl transcripts specifically, since they are small relative to what they represent. Mine total 9.4G across six accounts and four months, which is not a lot to keep for the only record of the work.

Thank you — this confirms the pattern precisely. My case (desktop app, macOS, single account): 58 of 69 sessions gone, and the survivors match your mtime observation exactly — sessions I happened to reopen recently survived regardless of age, while untouched ones from the same weeks were deleted. So we have the same boundary behavior on macOS/desktop and Linux/CLI across seven config roots total. I've also filed this with Anthropic support (conversation ID 215475490441586), referencing this issue.

+1 to your remediation order. I'd add: when cleanup deletes a transcript, the desktop app's corresponding sidebar entry should be removed or marked — currently it advertises the deleted sessions indefinitely, so users discover the loss only when recovery is impossible.

@codebytere-ant Could you clarify what "completed" refers to here? There is no linked PR, no closing comment, and no version mentioned. Specifically: (a) has any of the reported behavior changed (the silent default, the missing pre-deletion warning, the ghost sidebar entries), and in which release? (b) If the resolution is tracked elsewhere, could you link it? Given that this thread documents multi-month data loss across two platforms and had #87748 marked as its duplicate, a one-line disposition would help the users still exposed to the default.