What /memory shows in Gemini CLI, and where saved memories go

In Gemini CLI, memory is not a database. It is the text of the GEMINI.md files the CLI loads, plus a private per-project MEMORY.md index, and /memory is the command that shows and reloads that text. When the agent says it saved a fact, it edited one of those Markdown files. There is no separate memory store to browse, and no save_memory tool to call.

Run gemini --version first. This page describes v0.65.0, the stable release on 20 October 2026.

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

Status, 27 October 2026: /memory add no longer exists, but the command reference is stale: it lists refresh and omits reload and inbox; no current page documents /memory add. The v0.65.0 source has show, list, reload (with refresh as an alias), and inbox. A reply in issue #26563 (closed 14 May 2026) said the model now writes memory by editing files. Auto Memory is still marked experimental in its docs. 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.

What the `/memory` command does#

A context file is a Markdown file the CLI reads before work starts and puts into the model's prompt. GEMINI.md is the default name; the private MEMORY.md index is loaded the same way. /memory is a viewer and reloader for that set. The show, list, and reload subcommands do not call a model.

/memory show is the direct answer to "what did it actually load at startup?" It prints the exact text, not a summary. If a startup fact is missing there, it was never loaded; a model that says it remembers is not evidence.

The file count in /memory show can include a subdirectory GEMINI.md that was loaded just-in-time when a tool touched that directory. That file's text is appended to the tool output, not to the startup hierarchy, so /memory list may show its path while a later /memory show does not print its contents. The AGENTS.md loading guide covers that order.

Where a saved fact actually goes#

The current system prompt tells the model to route each fact to one of four places and not duplicate it.

The same facts are also described in the memory files page, which says the agent edits the files with write_file or replace.

<project> is the CLI's identifier for the workspace. On v0.65.0 it is a readable slug derived from the folder name, such as my-repo; the session docs still call it <project_hash>. The source migrates old hash folders to the new name.

Inside the private memory folder, MEMORY.md is an index. Short facts go in the index; a longer procedure goes in a sibling .md file with a one-line pointer from the index. The loader reads MEMORY.md; it does not scan the folder for arbitrary notes. A sibling file that the index never mentions is not loaded automatically.

If the folder still has a private GEMINI.md and no MEMORY.md, the loader reads it as the legacy fallback. Once MEMORY.md exists, the legacy file is ignored. That matters after an upgrade: a fact can be sitting in the old file.

A project fact saved by an older build may also sit in the global ~/.gemini/GEMINI.md; a 2025 report described exactly that (#15101, closed 15 March 2026 after inactivity). Check the global file before concluding the memory was lost.

Finding the private file#

/memory list is the reliable way to get the path. It prints the loaded files, including the private index when it exists.

/memory list

From a shell, the folder name is not obvious. This finds every private index on the machine:

find ~/.gemini/tmp -maxdepth 3 -name MEMORY.md -print

Then read the one for your project, replacing my-repo with the folder name from the previous command:

cat ~/.gemini/tmp/my-repo/memory/MEMORY.md

If the file is not there, the agent has not saved a private note for this project. Check ./GEMINI.md and ~/.gemini/GEMINI.md before assuming the save failed.

Why `/memory add` says `save_memory` was not found#

Older Gemini CLI versions had a save_memory tool and a /memory add command. In v0.65.0 both are gone. /memory has no add subcommand, so /memory add some text cannot add anything. The error in issue #26563 is what that looks like on v0.41.1: the CLI tried to call save_memory and no such tool existed. The replacement is direct editing: ask the agent to remember something, and it uses write_file or replace on the appropriate Markdown file.

Some tutorials and blog posts still tell you to use /memory add. They predate the change. There is also no /memory delete or /memory clear; deleting a memory means editing the file.

There is no save_memory tool to install. If a page tells you to enable it, that page is stale.

How to check that a memory was saved#

The model's answer is not the check. It can repeat what it intended to write. Check the file.

1. Run /memory list and copy the path for the tier you expected.
2. For a repo file, run git status --short and git diff -- GEMINI.md.
3. For a private note, read the index and its newest lines.
4. Run /memory reload, then /memory show, and look for the exact sentence. If it is there, it loaded.

git status --short
git diff -- GEMINI.md
find ~/.gemini/tmp -maxdepth 3 -name MEMORY.md -print -exec tail -20 {} \;

A new session also picks up the change. For a repo file, commit the edit so it is shared; the local session already sees the working tree.

If the line is present in /memory show and the model still ignores it, the storage worked. That is an instruction-following problem, not a memory-location problem. The Gemini CLI guides cover the next checks.

How to change or delete one#

Edit the file, then reload.

1. Run /memory list.
2. Open the file. Remove the line. For a private note with its own file, delete the file and remove the pointer from MEMORY.md. For a repo GEMINI.md, commit the removal.
3. Run /memory reload, then /memory show, and confirm the line is gone.
4. If the same fact exists in more than one tier, remove every copy. The current prompt says not to duplicate, but files written by older sessions can.
5. Auto Memory candidates are separate. Review them with /memory inbox and discard the ones you do not want.

Deleting MEMORY.md removes the private index. Sibling notes remain on disk but are no longer loaded; delete them too if the fact is sensitive.

Setting experimental.autoMemory to false stops new extraction. It does not delete existing inbox items; drain the inbox first, or remove the project memory folder's .inbox and skills directories.

What `/memory inbox` is#

Auto Memory is an experimental background extractor. It reads old session transcripts, looks for durable facts and repeated procedures, and writes reviewable proposals. It is off by default.

• Enable it with experimental.autoMemory in ~/.gemini/settings.json, or in .gemini/settings.json for one project, then restart. The Auto Memory docs list the exact JSON.
• Eligible sessions have been idle for at least three hours and contain at least ten user messages. Current, trivial, and subagent sessions are ignored.
• Candidates go to the project memory folder: memory patches under .inbox/ and skill drafts (a skill is a folder with a SKILL.md instruction file) under skills/. /memory inbox groups new skills, skill updates, and memory updates.
• It cannot edit a project GEMINI.md. It can propose private project memory, global personal memory, and skills.
• Nothing is applied without approval. An applied memory patch updates the file and reloads memory for the current session.

Without the flag, /memory inbox prints: "The memory inbox requires Auto Memory. Enable it with: experimental.autoMemory = true in settings."

Disabling the flag stops the background service on the next session start. Existing inbox items stay on disk.

Privacy matters here. Extraction uses model calls and may send transcript excerpts to the configured model. The extractor is instructed to redact secrets and tokens, but that is best effort, not a guarantee. Do not treat the inbox as a safe place for credentials.

What not to keep there#

Private memory is a plain Markdown file in your home directory. The CLI does not encrypt it, and it is not a secret store. Anything you would not paste into a prompt should not go in GEMINI.md, MEMORY.md, or a sibling note. The agent memory secrets guide has a checklist for what to capture and what to scrub.

Where to go next#

• Gemini CLI guides — the rest of the set.
• Does Gemini CLI read AGENTS.md? — what loads, in what order, and how to prove it.
• Why Gemini CLI can't read a gitignored file — when a file is on disk but invisible to the tools.
• How to check what your coding agent actually remembered — the cross-tool version of the check.