Where does Gemini CLI store chat history?

Under ~/.gemini/tmp/ /chats/, as .json or .jsonl files — one per chat, with a sub-agent's run nested one directory deeper. GEMINI_CLI_HOME moves the whole tree.

Which directory belongs to which project?

The directory name is a project id, not a path. ~/.gemini/projects.json maps ids back to directories, and a .project_root file inside the id directory names it as well.

Does deleting a chat delete the prompt log?

No. logs.json sits beside the chats in the same id directory and keeps what you typed; it survives deleting the chats and has to be removed separately.

Where Gemini CLI keeps chat history, and how to delete it

under ~/.gemini/tmp, in a directory named after a project id rather than a path

Gemini CLI writes each chat to disk as it happens, in a tree whose directory names are project ids. That is the part that makes it hard to clean up by hand: the path tells you nothing about which repository it came from, and the prompt log lives beside the chats rather than inside them.

Where the chats are

~/.gemini/tmp/<project-id>/chats/*.json        # one file per chat
~/.gemini/tmp/<project-id>/chats/<parent>/*.jsonl  # a sub-agent's run, one level deeper
~/.gemini/tmp/<project-id>/logs.json           # what you typed, kept separately
~/.gemini/tmp/<project-id>/logs/               # the rest of that session's own bookkeeping

GEMINI_CLI_HOME moves the whole tree. Both chat shapes exist on purpose: older builds write a single JSON document per chat, newer ones append JSONL, and a machine can hold both.

Which directory is which project

The id is not a path, and two mappings answer it. ~/.gemini/projects.json holds the reverse mapping; inside each id directory, a .project_root file names the directory the chats came from. Either is enough:

# from the registry Gemini keeps
python3 -c 'import json;print(json.load(open("'"$HOME"'/.gemini/projects.json")))' 2>/dev/null

# or from the marker beside the chats
for d in ~/.gemini/tmp/*/; do
  printf '%s  ' "$(basename "$d")"
  cat "$d/.project_root" 2>/dev/null || echo "(no marker)"
done

Without one of those, deleting by directory name is deleting something you cannot identify.

How to delete it

# one chat
rm ~/.gemini/tmp/<project-id>/chats/<file>

# every chat for one project, sub-agent runs included
rm -rf ~/.gemini/tmp/<project-id>/chats

# the prompt log for that project, which the line above does not touch
rm ~/.gemini/tmp/<project-id>/logs.json

# everything Gemini CLI has kept
rm -rf ~/.gemini/tmp/*

Two traps. The tree also holds checkpoint files, which are not chats — a tool that walks it looking for sessions has to skip them, and so do you. And ~/.gemini/tmp is where Antigravity keeps its own store on some installs, so a blanket rm -rf ~/.gemini/tmp can take a different agent's history with it; that is why deja reads the two apart rather than treating the directory as one store.

What you lose

The chats are the record of what was tried and what worked. Gemini CLI has no search across projects, so a decision from two months ago is reachable only while its chat file exists — and a sub-agent's run, nested one directory deeper, is often the only place a piece of work was described at all.

Keeping it searchable instead

deja indexes both Gemini chat shapes, the sub-agent runs and the other thirty-three agents on the machine into one local index — searchable from the shell, and readable by the agents themselves over MCP:

curl -fsSL https://raw.githubusercontent.com/vshulcz/deja-vu/main/install.sh | sh
deja "gemini retry budget"

Nothing to switch on first: the files are already there, including the months before deja was installed. Indexing and search stay local, credentials are stripped as the index is built, and deja forget drops a session from the index for good when you do want it gone.

Where every agent keeps its history · Memory for Gemini CLI · The Gemini CLI format

Found this useful? Star deja-vu on GitHub.