Claude Code quietly wipes session logs after 30 days

On one developer's machine, eight Claude Code project folders created between January and April 2026 contain no transcript older than May 5. The folders survived and the files inside them did not. The write-up on Brycewatson shows what the 30-day default deletion looks like after it has run, and changing the setting later brings none of those files back.

At a glance

• Claude Code deletes terminal and IDE session transcripts older than 30 days unless cleanupPeriodDays in ~/.claude/settings.json says otherwise, and the sweep runs in the background with no message.
• Since v2.1.248, sessions started or last continued in Claude Desktop or Cowork are kept at any age, while managed settings from your organization override your own cleanupPeriodDays value.
• The fix is one line, { "cleanupPeriodDays": 3650 }, roughly ten years, but it only protects transcripts from that moment on, and anything already swept stays gone.

If you haven't been following this, people have complained about it before. A GitHub issue (anthropics/claude-code #64999, filed against version 2.1.156) calls the default silent and permanent data loss. The reporter lost two reference sessions, 44 and 52 days old, to a scheduled cleanup that gave no notification. The same issue says the setting exists only in settings.json, not in the Desktop app's settings screen, and that the reporter found the workaround only through the validation error that rejects 0.

The 30-day default deletes transcripts in a background sweep with no message

The setting is cleanupPeriodDays, a top-level key in ~/.claude/settings.json. The settings reference gives a default of 30 days and a minimum of 1, and a value of 0 fails validation. The sweep runs in the background after a session starts and shows no message, so an old session simply stops appearing in /resume. In June the docs said deletion happened at startup. Your files end up deleted either way.

Most of what gets swept is chat history: the per-session .jsonl files under ~/.claude/projects/, plus a subagents/ file for each subagent run. According to the changelog, tasks/, shell-snapshots/ and backups/ joined the sweep in v2.1.117. The current docs also list file-history/, plans/, debug logs, the paste cache and orphaned worktrees. The auto memory folder, projects/<project>/memory/, is kept. Before v2.1.228, though, the sweep could delete old files in folders inside it.

Since v2.1.248, Claude Desktop and Cowork sessions are kept at any age

Since Claude Code v2.1.248, the sweep keeps the transcript of any session you started or last continued in Claude Desktop or Cowork, however old it is. The changelog calls this a fix for those sessions disappearing after 30 days. A new setting, desktopSessionCleanupPeriodDays, can put an age limit back on them, but never a shorter one than cleanupPeriodDays.

Sessions you run in the terminal or an IDE still follow cleanupPeriodDays. If your organization sets that key in managed settings, its value wins over yours, and it covers Desktop sessions too. If the key is missing from your own file, you are on the 30-day default. As of September 2026 that still applies to everything outside Desktop and Cowork.

If ten years feels like too much, the author suggests picking a deliberate ceiling such as 365. Keeping everything means the folder keeps growing, and by the author's rough estimate a busy setup can produce hundreds to low thousands of transcript files a week.

1,324 transcripts older than 31 days survived on a machine set to 3650

The author raised cleanupPeriodDays to 3650 months ago and then checked whether the setting was working. As of June 25, 2026, 1,324 transcript files, 647 of them top-level sessions, were older than 31 days and still on disk. The extra day is a buffer, so every file counted is clearly past the default's limit. The oldest surviving transcript was last modified on May 7, 49 days earlier.

Counting files of every age, the machine held about 7,000 transcripts taking up 1.58 GB at that point. The value was already 3650 by June 11, when the author mentioned it in a post published that day. That date falls after the early-May floor.

Measured on September 30, the eight project folders created between January and April hold nothing older than May 5. shell-snapshots/, which is swept on the same schedule, runs out around the same time. Commits in the author's public chat-arch repository go back further than the oldest surviving transcript. The author reads this as the mark left by the last 30-day purge before the setting changed.

The author withdrew 150 file-history files as evidence

The post keeps a revision log. The June version had cited 150 file-history/ files dated March and April, going back to March 3, as proof that the history started before the floor. But those dates came from the edited files themselves. 124 of the 150 were written to disk more than a day after the date they carry, and the earliest was written on April 12.

Every file-history/ session folder was last changed on or after May 6, right at the transcript floor. The September 30 recheck, done against the current docs and changelog with Claude Code 2.1.280, also fixed the list of swept paths. The June post had said file-history/ and plans/ were left alone.

Which clock decides that a transcript is 30 days old?

The docs don't name one. They only say "older than this period". On the author's machine, deletion goes by the file's last-modified time, and the author presents that as an observation, not documented behavior. The two clocks can disagree. The earliest message inside the oldest transcript is stamped May 5, about two days before the file's modified time.

According to a write-up by Adityabawankule, each session is an append-only JSONL file named by its session ID. Resuming an old session keeps adding to that same file, and subagent work sits in a separate folder named after the session. If the author's observation holds, the sweep behaves like a fridge clean-out that goes by when a container was last opened, not when the food went in.

The Claude Code docs say /resume reads those local files. Once a file is deleted, the session can't be resumed, and looking it up by ID returns "No conversation found with session ID". The GitHub issue adds that files are removed with fs.unlink, which skips the Windows Recycle Bin, and that there is no preview or undo.

The post is open about its limits. The deletion clock is the author's own observation, and the author didn't run a fresh sweep on the default, so the list of swept paths comes from the docs. In our view, the weak point is the missing key. A settings file without cleanupPeriodDays looks like nothing needs attention, yet it means a purge every 30 days. The GitHub reporter only found the setting through an error message.

Check settings.json before your next session

The next sweep runs after your next session starts, so open ~/.claude/settings.json now and look for cleanupPeriodDays. Whatever has already aged out will not come back. The GitHub issue asked for a 365-day or never-delete default, moving files to Trash instead of deleting them, and a warning before deletion. Apart from the Desktop and Cowork exception, no timeline has been given for any of those changes reaching terminal sessions.