No prompt triggered it. No command asked for it. A background cleanup pass did it on its own, twelve minutes after a new session started.
What the source says
On May 14, 2026, a Claude Code user filed GitHub issue #59248 after discovering that the tool's built-in retention cleanup had silently deleted every prior conversation transcript in a workspace — including a session from the previous day. The user was running Claude Code through the Cursor extension (build anthropic.claude-code-2.1.141-darwin-arm64) on macOS, in a workspace whose path contained a space. A second session started in that workspace at 13:01 PT; a cleanup pass ran at 13:13:20 PT, rewriting the .last-cleanup marker file. The Cursor resume picker afterward showed an empty history, with no in-product indication that any data had ever existed.
The reporter backed the claim with file-level evidence rather than a bare assertion. Their ~/.claude/settings.json had no cleanupPeriodDays override, so cleanup ran on the binary's default — documented at 30 days. With the report filed 2026-05-14, that default should have preserved everything back to 2026-04-14. Instead, the most recent surviving transcript material dated to 2026-03-04 — 71 days earlier, not 30. Eight orphaned <sessionId>/subagents/ directories (about 15 MB across 72 files) survived with no parent .jsonl transcript for any of them, and Claude Code's own ~/.claude/file-history/ log confirmed six session UUIDs had been active in the workspace the previous day — none of which had any surviving directory anywhere under ~/.claude/projects/.
Deletion went straight to unlink(): no soft-delete staging folder, no grace period, no --restore subcommand, and on macOS the files bypassed Trash entirely. Rolling back the Cursor extension version had no effect, since the transcripts live under ~/.claude/, independent of extension version. The issue carries labels area:core, bug, data-loss, has repro, and platform:macos, and remains open with no maintainer response as of publication.
What it doesn't establish
This is one user's report, not a confirmed pattern. There is no maintainer response on the issue, so Anthropic has not confirmed the 71-day figure, acknowledged a bug in the cleanup logic, or explained why the observed retention fell so far short of the documented default. The report doesn't establish whether this affects all platforms or only the Cursor-extension / macOS path the reporter used, and it doesn't rule out a local misconfiguration the reporter didn't think to check. Severity here is scored medium (6.2), not because the loss wasn't real and permanent for this user, but because it is a single unconfirmed report against a documented default, not a demonstrated systemic failure.
Why it's worth tracking anyway
What makes this one different from most entries in this database isn't an agent doing something reckless when asked — it's a maintenance process silently doing less than what the product's own documentation promises, with no warning and no way back. A 30-day retention default is a data-safety commitment as much as a storage-cleanup policy; a gap between "documented" and "observed" of more than 2x, with zero soft-delete and zero restore path, is the kind of failure that erodes trust precisely because it's invisible until you go looking for something that's already gone.
Top comments (0)