Gemini CLI resume session: --resume, /resume and history

To resume a Gemini CLI session, cd into the project and run gemini --resume (short form gemini -r), which reopens the session started there most recently. For an older one, gemini --list-sessions prints a numbered list: pass the number (gemini --resume 3) or the full <session-uuid>. Inside a running session, /resume opens a session browser.

Commands checked on 24 October 2026 against v0.65.0, the latest stable release then, using Google's session management page and the source on GitHub. The two disagree on one point, the name of the project folder, and both versions are below.

How to resume a Gemini CLI session#

The numbers run oldest first: 1 is the first session you started in this project and the newest has the highest number (sessionUtils.ts). So run --list-sessions before --delete-session, because number 1 is the oldest, not the latest. "Latest" goes by when a session started, not when you last used it. If you reopened an older session yesterday, gemini -r still picks the one that began most recently.

--resume, --session-id and --session-file are mutually exclusive: Gemini CLI takes only one of them per start.

The session browser#

Typing /resume while Gemini CLI runs opens a list of this project's past sessions with the date, the number of messages and the first prompt of each. Press / to search by ID or by what was said, Enter to resume the highlighted one, x to delete it and Esc to close. /chat opens the same browser; it's an alias.

Named checkpoints: /resume save and /chat save#

Nothing needs saving before you quit, because Gemini CLI records every session as it goes. A checkpoint is different: a named copy of the conversation at one moment, for a point you may want to go back to.

/resume save before-refactor
/resume list
/resume resume before-refactor

• /chat save, /chat list and /chat resume are the same three commands.
• /resume load <tag> is another name for /resume resume <tag>.
• /resume delete <tag> removes a checkpoint.
• Saving under a tag that exists asks before it overwrites.
• /resume share notes.md (or a .json name) writes the current conversation to that file.

A checkpoint belongs to the project you saved it in. The commands reference says you can only resume one from that same project, so start Gemini CLI in that folder first. The source writes it as checkpoint-<tag>.json in the project's folder under ~/.gemini/tmp/ (logger.ts).

Where Gemini CLI keeps session history#

chatRecordingService.ts writes one file per session and names it from the start time in UTC, to the minute, plus the first 8 characters of the session ID:

~/.gemini/tmp/<project>/chats/session-2026-10-24T09-15-a1b2c3d4.jsonl

If that name is already taken, a counter goes between the time and the ID. On Windows the folder is C:\Users\<you>\.gemini\tmp\. Google lists what the file holds: your prompts and the replies, every tool call with its input and output, token counts, and the model's reasoning summaries when there are any.

Google's page calls the project folder <project_hash>. In the current source it's your project folder's name, lowercased, with anything but letters and digits turned into dashes: ~/Code/My App becomes my-app, and a second project with the same name gets my-app-1. ~/.gemini/projects.json records which path owns which name, and a .project_root file inside the folder says the same (projectRegistry.ts). Older versions used a SHA-256 hash of the path, and Gemini CLI moves those folders to the new names when it next opens the project.

History is per project. Run gemini -r in ~/Code/other-app and it reads other-app's chats folder, never this one's. GEMINI_CLI_HOME moves the whole tree: with it set, everything lives in $GEMINI_CLI_HOME/.gemini/ (configuration reference).

Why Gemini CLI deletes sessions after 30 days#

Since v0.33.0, released on 11 March 2026, Gemini CLI cleans up old history by default (release notes). Each time it starts, it deletes sessions in the current project whose last update is more than 30 days old, along with their plans, tool output and logs. Four settings in settings.json control it:

To keep a year of history, put this in ~/.gemini/settings.json:

{
  "general": {
    "sessionRetention": {
      "maxAge": "365d"
    }
  }
}

Units are h, d, w and m (a 30-day month). Set "enabled": false to keep everything. In /settings the same two are Enable Session Cleanup and Keep chat history (that one is maxAge). A maxAge shorter than minRetention is invalid, and Gemini CLI then skips the cleanup altogether.

Three details from sessionCleanup.ts. The cleanup only looks at the project you start Gemini CLI in, so a project you haven't opened for two months still has its old sessions until you open it. It also deletes session files it can't read. And it reads only the chats folder, so tagged checkpoints sit outside it and are left alone. Claude Code has the same 30-day default under another name, cleanupPeriodDays (Claude Code deleted your old chats?).

Why a session doesn't come back#

gemini --resume says "No previous sessions found for this project." or "Invalid session identifier" for one of these reasons:

1. Another folder. Sessions are per project. cd back to where you started it.
2. Another GEMINI_CLI_HOME. A session started with GEMINI_CLI_HOME=~/gemini-work is in ~/gemini-work/.gemini/tmp/, and plain gemini won't list it.
3. The 30-day cleanup. Once deleted, it's gone. Raise maxAge now so the rest stay.
4. The macOS Seatbelt sandbox. When it runs inside sandbox-exec, Gemini CLI keeps its history in ~/.cache/.gemini/ instead, because the sandbox profile blocks writes to ~/.gemini (storage.ts).
5. A wrong number. The index counts from the oldest session, and it shifts when sessions are deleted. Run --list-sessions again.

Resuming on another Google account#

Since 18 June 2026, Gemini CLI no longer serves Google AI Pro and Ultra sign-ins, or people on the free Gemini Code Assist for individuals. Google's announcement says Code Assist Standard and Enterprise licences keep working, and that Gemini CLI "will remain accessible via paid Gemini and Gemini Enterprise Agent Platform API keys". If that's how you sign in, history and resume work as above.

Signing out and back in as another account inside one ~/.gemini keeps the history, because it's stored per project, not per account. People who keep each account in its own GEMINI_CLI_HOME split their history too: each home has its own tmp. The fix is to link tmp from ~/.gemini into each home before its first run, along with GEMINI.md, commands, extensions and skills, never the sign-in files; changing Google account in Gemini CLI has the commands. Gemini CLI then finds the project's folder again through its .project_root file. Use only accounts and keys you own and are entitled to use; providers' terms may not allow sharing a subscription sign-in.

The Claude Code and Codex versions of this have different commands and folders: resuming a Claude Code session and Codex CLI resume.

How Shuriken keeps Gemini chats going#

In Shuriken, a Gemini CLI chat is a chat in a project. It's saved where it runs and opens from any device you've linked, so there's no session number or ID to look up.

Every Google sign-in you add as a source gets its own GEMINI_CLI_HOME, and Shuriken links tmp from your ~/.gemini into each one, with GEMINI.md, commands, extensions and skills. Every sign-in writes its sessions into the same folder, so the second reason above doesn't apply. With two or more Gemini sources, Shuriken switches between them. Hot swapping is our name for it: Shuriken moves your chats to another of your accounts or sources when one nears its limit. A Gemini chat moves when its current turn ends, and the next turn picks up the same conversation on the new source. Source switching has the settings.

Shuriken runs the same Gemini CLI, so a Google AI Pro, Ultra or free sign-in fails there just as it does in your terminal. If you hold a Code Assist licence or a paid Gemini API key, download Shuriken and add it as a source.