Claude Code Deletes Old Sessions After 30 Days by Default: Fix

By default, Claude Code deletes a session's transcript once it has gone unused for longer than cleanupPeriodDays, which is 30 days unless you change it. The sweep runs in the background after a session starts. To stop it, add "cleanupPeriodDays": 3650 to ~/.claude/settings.json and back up ~/.claude/projects. If you see No conversation found with session ID, the file may be gone, or it may still be on disk and Claude Code is looking somewhere else. This guide covers both, plus a third cause the setting does not fix.

What does "No conversation found with session ID" mean?#

You run claude --resume, or /resume inside a session, and either the list is empty or you get:

No conversation found with session ID: 3f2c…

Claude Code keeps every conversation as a JSON Lines file on your machine:

~/.claude/projects/<the project path, with non-alphanumeric characters replaced by ->/<session id>.jsonl

A project at /Users/ada/code/api gets a folder called -Users-ada-code-api. That error means Claude Code found no transcript for that ID in the places it searched. There are three separate reasons that happens, and they need different fixes:

Why does Claude Code delete conversations after 30 days?#

Because that is the default retention period, and you can change it. Claude Code's settings reference says transcripts older than cleanupPeriodDays are deleted, with a default of 30 days and a minimum of 1.

A few things about it that the top results skip over:

• It runs when you use Claude Code, not on a schedule. The docs describe "a background sweep after a session starts". A transcript that has sat unused past the limit can go the next time you start a session, and the sweep covers every project on the machine. Two exceptions in the current docs: transcripts of sessions started or last continued in Claude Desktop or Cowork are kept at any age (v2.1.248 and later, unless an admin or desktopSessionCleanupPeriodDays sets a limit), and the sweep pauses when Claude Code can't safely determine the retention period.
• It deletes the file; it does not move it to the Trash. #64999 describes files removed with fs.unlink, bypassing the Windows Recycle Bin, and #62476 asks for a soft-delete folder instead. #85466 describes about 950 transcripts removed in one pass, on an app start the reporter believes followed an update.
• It only takes the conversation. Your code, git history, CLAUDE.md files and settings are untouched. What goes is the reasoning trail: the dead ends you rejected, the debugging, the "why" behind a change. The /resume list loses the session too.
• 0 does not mean "never". Before v2.1.89, setting 0 silently stopped transcripts being written at all (#23710). Since then it is rejected with a validation error. Use a large number.

As of September 15, 2026, #62476 (opened May 26, 2026) is still open, and the documented default is still 30.

Why can't Claude Code find a session that is still on disk?#

Sessions are filed by project directory. So whether one "exists" depends on where you are standing when you ask. #33912 is a clear example (on v2.1.74, closed as not planned): the .jsonl file was right there, and every resume attempt still returned No conversation found.

Here is how lookup works as of Claude Code's current session docs:

• claude --continue only resumes the most recent session in the current directory.
• The /resume picker shows sessions from the current worktree by default. Press Ctrl+W to widen it to every worktree of the repository, or Ctrl+A to see every project on the machine.
• claude --resume <id> checks the current project and its worktrees first, then every other project on the machine. Before v2.1.223 it stopped at the current project, so older builds needed you to cd into the original folder. If a hand-copied duplicate of the transcript exists in two places, it reports not found rather than guessing.
• Sessions started with claude -p or the Agent SDK are left out of the picker and out of --continue. They can still be resumed by ID. Scripts and tools built on the SDK create these, which is why they never show in the list.
• The desktop app, Claude Code on the web and the VS Code extension each keep their own history. A session started in one does not appear in the CLI's picker.

That produces the common "it vanished" cases:

1. You renamed or moved the project folder. The transcripts live under a folder named after the old path. The new path's picker is empty. Ctrl+A finds them. (Moving a session with /cd relocates it to the new directory's storage; moving the folder in Finder does not.)
2. You opened a git worktree or a subfolder. Different directory, different default list. Ctrl+W or Ctrl+A brings them back.
3. You opened the project on another Mac. The files were never there. ~/.claude/projects is local to one machine and nothing in the CLI syncs it.

Why were transcripts deleted even with cleanupPeriodDays set high?#

Several reports describe transcripts disappearing with retention set to years. One has an explanation; the others do not:

• #86991 (v2.1.146): with cleanupPeriodDays: 9999, projects were pruned to one transcript each. A Claude Code maintainer explained that if settings.json was not valid JSON at the moment cleanup ran, that version fell back to the 30-day default, and said it is fixed in a recent release. (The reporter had suspected autoUploadSessions; the maintainer said that setting has no effect in public builds.)
• #62272 (v2.1.91): files deleted with cleanupPeriodDays: 36500, which the reporter correlated with VS Code restarts, CLI and extension auto-updates, and Claude Desktop running alongside. Closed as a duplicate.
• #78578: the VS Code extension updated from 2.1.211 to 2.1.212, restarted into a fresh session, and the multi-week transcript was gone. Closed as not planned after a period of inactivity.

As of September 15, 2026, we found no published root cause for #62272 or #78578. Two practical conclusions: keep settings.json valid JSON (an editor that checks it helps), and treat the setting as reducing the risk while a backup removes it.

The 60-second fix: raise the setting and back up the folder#

1. Raise retention. Open ~/.claude/settings.json (create it if it does not exist) and add the key, keeping whatever else is in the file:

{
  "cleanupPeriodDays": 3650
}

That is about ten years. Put it in your user settings file, not a project's shared .claude/settings.json, so it applies everywhere and does not depend on a repo. Make sure the file is still valid JSON after editing, and run /status after launch to check for a settings warning.

2. Back up the transcripts. Copy the folder somewhere Claude Code does not manage. Leave out --delete, so a file removed from the source is kept in the copy:

mkdir -p ~/Backups/claude-projects
rsync -a ~/.claude/projects/ ~/Backups/claude-projects/

To run it every hour, add a line with crontab -e:

0 * * * * rsync -a "$HOME/.claude/projects/" "$HOME/Backups/claude-projects/"

Time Machine covers ~/.claude too, as long as your home folder is not excluded. It is worth checking before you need it.

3. Before an update, resume what matters. If a session is important, open it after an extension or CLI update, before you start new work. Reports #62272 and #78578 both involve the restart that follows an update.

How to recover a Claude Code conversation that is already gone#

Honestly: only from a copy. Claude Code has no restore command and no trash folder for transcripts.

Where to look:

• Time Machine. Browse ~/.claude/projects/<project folder>/ in a snapshot from before the deletion and restore the .jsonl. The reporter of #62272 published a helper for exactly this, restore-claude-history.
• Your own backup, iCloud Drive or Dropbox copies, or another machine you worked on.
• ~/.claude/history.jsonl. It records prompts you typed. It will not give you the model's replies, the tool calls or the file diffs, but it can remind you what you asked.

If you find the .jsonl:

1. Put it back under ~/.claude/projects/ in the folder named after the project's current path (for example -Users-ada-code-api). Create the folder if needed.
2. Make sure only one copy of that session ID exists across all project folders, or --resume <id> will report not found.
3. Run claude --resume <session id> from the project directory.

What a restored transcript gives back: the full conversation, including tool calls and results, and the model and agent it was using. It does not bring back the state of your files at the time; that is what git is for. On Pro and Max plans, resuming a session that has been idle for more than about an hour and is over 100,000 tokens offers to resume from a summary instead of the full history.

Do Codex, Gemini CLI and Grok have the same problem?#

The lookup problem, yes; the default deletion, at least for Gemini CLI. Each of these CLIs keeps conversations in its own home directory, and each refuses a resume it cannot honour. These are the messages we saw when we ran each tool against a missing thread on our own Mac on August 31, 2026 (wording can change between versions):

Two notes on that table:

• Gemini CLI also deletes after 30 days by default. Its configuration reference sets general.sessionRetention to enabled: true, maxAge: "30d". Raise maxAge or set enabled to false in its settings.json.
• In our testing, Grok printed a line that looks like an error and is not. Session "…" not found locally, restoring conversation from remote... is a status line, after which Grok tried to fetch the conversation remotely. Only Failed to restore session from remote meant it could not be restored.

If you switch between these tools, each one's memory of a project lives in a different place under a different key. Moving work between them loses context unless something carries it across. We wrote about that in running Claude Code, Codex, Gemini and Grok from one app.

The durable fix: keep the conversation with the project#

The settings change and the backup deal with deletion. They do not change the underlying design: the conversation lives in a folder named after a path, in a tool's private directory, on one machine. So a rename hides it, a second Mac never has it, and an update can remove it.

This matters to us because Universe, the Mac app we make, runs Claude Code, Codex, Gemini CLI and Grok as engines. So Universe keeps its own record of each conversation instead of relying only on each CLI's private copy.

How Universe handles it:

• The record is files you can open. Sessions live in ~/.universe, with their transcripts and the files the agent made. The app's database is an index rebuilt from those files, so deleting it loses nothing.
• Switching engines keeps the conversation. Change the model mid-conversation and the new engine is given the conversation so far, instead of starting blank.
• Signed in, it is backed up. When you sign in, session transcripts and a backup of the model's conversation memory sync to Universe's cloud. That is also how a session can move to a second Mac and keep its history.

Where Universe fits, and where it does not#

• It does not protect sessions you run in a terminal. A plain claude session outside Universe still lives in ~/.claude/projects and is still subject to cleanup. Set cleanupPeriodDays either way.
• It is Mac only (Apple silicon or Intel, macOS 13 or later), and it needs your own model account: Claude Pro or Max, a ChatGPT Plus, Pro or Business plan, a Google account for Gemini, an xAI key, or a local open model.
• Cloud backup needs an account. The app works without one, but then the record is only on that Mac, in ~/.universe.
• If all you want is Claude Code in a terminal with your history kept, the settings change plus an hourly rsync is the whole answer, and it is free.

If you would rather your agents' conversations stay with the work across renames, restarts, engine switches and machines, see what Universe does, check the plans (there is a $0 plan), or download it.