Where did my Gemini CLI session go? Resuming, retention, and invalid identifiers

A Gemini CLI session is the transcript of one conversation: your prompts, the model's replies, every tool call and its output, appended to a file under ~/.gemini/tmp/<project-id>/chats/ as you work. Closing the terminal does not delete it. "My session is gone" usually means the CLI is looking in a different directory, the ID you used was not the full one, retention removed the file, or the resume path described below removed it.

Run gemini --version first. This page describes v0.65.0 (20 October 2026); paths and flags have moved across the 0.6x releases.

Checked against Gemini CLI's documentation on 27 October 2026.

Status, 27 October 2026: a resumed session can be deleted by the next startup cleanup, so back up the chats folder before a long resume; see [the resume bug section](#the-resume-bug-that-can-take-the-real-file-with-it) below for the file pattern to watch. Unpaid-tier and Google One users were moved to Antigravity CLI on 18 June 2026, so this page applies to paid, API-key, Vertex AI and enterprise installs; the Gemini CLI hub has the details.

Where the session files are#

Every conversation you can resume is one file, normally JSONL (one JSON object per line), in the current project's chats directory:

~/.gemini/tmp/<project-id>/chats/session-2026-10-27T09-15-0b2adf84.jsonl

The filename carries the start time, to the minute, and the first eight characters of the session's UUID. The full UUID is not in the filename: for a JSONL session it is in the first line; for a legacy .json session, use /resume or the Session ID: line in the exit summary instead of head -n 1.

The session management docs call <project-id> a project hash. In v0.65.0 it is a short slug stored in ~/.gemini/projects.json, and older SHA-256 directory names are migrated on first run. The registry maps an absolute path to that slug (storage.ts, projectRegistry.ts).

What counts as a project is narrower than people assume: it is the directory where you launch gemini. Starting in ~/code/app one day and ~/code/app/packages/api the next gives you two session lists, because the absolute path is the key. So does reaching the same checkout through a symlink, moving or renaming the folder, or switching to a worktree. A worktree — a second checkout of the same repository — is a separate project too when you start Gemini in it; Gemini's own --worktree exit summary prints the cd and gemini --resume line for it.

To see the mapping and the files:

cat ~/.gemini/projects.json
ls ~/.gemini/tmp/<project-id>/chats

On Windows the same files are under C:\Users\<you>\.gemini\tmp\<project-id>\chats.

gemini --list-sessions says "for this project" and means it. It does not show another directory's sessions, even when the UUID is still valid.

The resume commands, and the ID people get wrong#

The index is one-based and ordered oldest first. In the docs example, 1 is the session from two days ago and 3 is the one from a minute ago. --resume 1 does not mean "the latest".

Copy the UUID that --list-sessions prints. If your build prints only a shortened value, read the full UUID from the exit summary (Session ID:...) or, for a JSONL session, from the first line of the file. The eight characters in the filename (-0b2adf84.jsonl) are a filesystem label, and --resume 0b2adf84 fails with "Invalid session identifier".

head -n 1 ~/.gemini/tmp/<project-id>/chats/session-2026-10-27T09-15-0b2adf84.jsonl

--resume with no value is treated as latest. If the project has no sessions, latest prints a warning and starts a new session; an index or UUID that does not resolve exits with an error. The three flags --resume, --session-id, and --session-file are mutually exclusive.

Inside the CLI, /resume opens the session browser: arrow keys, / to search, Enter to load, x to delete, Esc to leave. The browser is project-scoped too, and it previews the first prompt and message count, which is often enough to tell two similar sessions apart.

`/resume list` is not the session list#

This trips people who search for "resume list". /resume alone opens the automatic session browser. /resume list lists tagged chat checkpoints made with /resume save <tag>: a named copy of the conversation, with no file snapshot. When there are none it prints "No saved conversation checkpoints found." That message says nothing about your automatic sessions. Use /resume without list to see those.

The three saved things are different:

The last one is the undo path; the rewind and restore guide covers it.

What "Invalid session identifier" is telling you#

The error is more useful than it looks. It prints the directory it searched:

Error resuming session: Invalid session identifier "...".
  Searched for sessions in /home/you/.gemini/tmp/app-1a2b/chats.

Read that path first. If it is not the project you meant, the session is probably fine and you are in the wrong directory.

You started elsewhere. cd to the directory you used before, or import the file into the current project (below). Running from a subdirectory, a symlinked path, or a worktree all produce a different project ID.

You used the filename suffix. The list prints the UUID; the eight characters in session-...-0b2adf84.jsonl are only the first eight characters of it. A truncated paste produces the same error, which is what happened in a 2026 report on macOS (#24535, closed as duplicate 7 April 2026).

Retention deleted it. The default keeps sessions for 30 days; see the next section. ls the chats directory before assuming corruption.

The file has no resumable content. Sessions with only startup or system messages are filtered out of the list, so they cannot be resumed by UUID either. That is usually a session that never got a prompt, not work you lost.

You are on an old Windows build. Versions around 0.35.0 printed the resume command with single quotes around the UUID; the parser took the quotes literally. The report was closed as completed in May 2026 after an earlier close was reopened (#23718). v0.65.0 wraps the ID in double quotes on Windows, which PowerShell and CMD both accept. If your build prints single quotes, remove them; the UUID itself has no quotes.

What retention deletes, and when#

Cleanup is on by default and runs at startup, in the background, before the interactive UI is ready. It also starts before --list-sessions exits, so the list can change under you if a cleanup pass finishes first (sessionCleanup.ts).

The default policy is 30 days from the recorded last update, no session-count limit, and a one-day minimum retention so a session cannot be deleted the day it was created. It is configured in settings.json (settings reference):

{
  "general": {
    "sessionRetention": {
      "enabled": true,
      "maxAge": "30d",
      "minRetention": "1d"
    }
  }
}

maxCount has no limit when unset; add it if you want to keep only the most recent N sessions. When a session is deleted, the CLI also removes its implementation plans, task tracker, tool outputs, and activity logs. There is no trash to restore from.

Deleting is separate from clearing: /clear starts a new session and leaves the old one in the list, while /quit --delete or /exit --delete deletes the current session's history and temporary files. Closing the terminal does neither.

The resume bug that can take the real file with it#

The report is specific and worth knowing even if your build has moved on (#27368).

gemini --resume has been observed to leave a second .jsonl file with the same eight-character suffix: a new timestamp, the same short ID, and little or no content. If that file has no resumable conversation, the next normal launch classifies it as corrupt in getAllSessionFiles. identifySessionsToDelete then passes every corrupt file to the cleanup, and the cleanup derives the short ID from the filename and expands the delete to every file ending in -<short-id>.jsonl. The only guard is that a file's full UUID must not equal the current session's ID; on a normal launch the current ID is a fresh UUID, so the resumed session is not protected.

That is the code path in sessionUtils.ts and sessionCleanup.ts at v0.65.0. Reports on 0.43 through 0.53 describe the result: the newest session vanishes from /resume and --list-sessions, and the older file cannot be resumed by UUID. A comment in the report says /resume from inside a running session does not create the duplicate file, because the in-session browser takes a different path; treat that as a report, not a guarantee.

The safe habit is cheaper than reproducing it:

• Quit Gemini, then copy ~/.gemini/tmp/<project-id>/chats/ somewhere outside ~/.gemini before a long resume.
• After resuming, look for a second file with the same suffix. If one appeared, copy both files out before the next launch.
• If you can, use the in-session /resume browser instead of the --resume flag for important work.
• Keep the backup until you have verified the transcript, not just that the session opened.

Check you got the right session#

Opening a session proves the file parsed, not that the work is where you left it. Check three things before you continue:

1. The transcript. Match the browser's start time, message count, and first prompt to the session you meant.
2. The working tree. Run git status, git log -1, and git diff --stat; the conversation carries the old plan, the files carry the current branch.
3. The instruction files. A resume replays the transcript but rereads the current GEMINI.md, so rules added or removed since then apply now. The AGENTS.md and GEMINI.md guide explains the loading order.

If the session was compressed — older turns replaced by a summary when the context window filled — the model may be working from that summary rather than every original turn, even though the session file still holds the conversation it recorded. Context compaction explains what a summary keeps.

Back it up, or move it to another folder#

Sessions are plain local files. With Gemini closed:

mkdir -p ~/gemini-session-backup
cp -a ~/.gemini/tmp/<project-id>/chats ~/gemini-session-backup/

Copy ~/.gemini/history/<project-id> and ~/.gemini/tmp/<project-id>/checkpoints too if you use checkpointing; those are the snapshots behind /restore. The transcript is plaintext and can contain prompts, source code, tool output, and secrets, so treat the backup like the machine.

To continue a session in a different project, the CLI accepts --session-file <path> (present in the CLI source and --help, but not in the flag table at v0.65.0). It loads the transcript, gives it a new session ID, writes it into the current project's chats directory, and adds an "Imported session from..." message. That is an import, not a move: the original stays where it was (gemini.tsx).

Copying the .jsonl into the target project's chats directory and then using --resume also works, because the loader does not check the recorded project path. The metadata still names the old project, so prefer the import for anything you will keep.

Cross-folder resume by UUID is not implemented at v0.65.0; the lookup is still the current project's chats directory. If the work has to move to another agent or machine, a short handoff file is more reliable than the transcript; the handoff guide has the shape.

Where to go next#

• Gemini CLI guides — the hub for this set.
• What /rewind and /restore actually put back — the undo paths, and why checkpoints are not a backup.
• Context compaction — if the resumed conversation lost the middle of the work.
• Does Gemini CLI read AGENTS.md? — if the resumed session is missing its rules.
• Hand off work between Claude Code and Codex — when starting fresh beats resuming.