How to Add Memory to Gemini CLI
How to add memory to Gemini CLI matters most when you're building an agent pipeline that needs to remember context across sessions. You run a command, the agent learns something useful, and you expect it to stick. Gemini CLI does have native memory: /memory add saves facts, and GEMINI.md carries project rules. The catch is that both were built for interactive use, not for production agent workloads. They won't select a specific memory file, they won't talk to an external store, and they won't persist memory across separate agent runs the way a RAG pipeline requires. GigaRAG fills that gap when you need memory that scales beyond a single session. This guide covers the exact commands, what GEMINI.md does differently, the limitations you'll hit, and a concrete pattern for extending Gemini CLI memory into something production-grade.
| At a glance | Details |
|---|---|
| Native memory | Built-in via GEMINI.md and /memory commands |
| Memory file selection | Not supported natively |
| External memory integration | Not built in; requires custom wiring |
| Cross-session agent memory | Limited; not designed for production agents |
| Best for | Interactive coding sessions, not long-running pipelines |
| Extension path | External memory layer such as GigaRAG |
In This Guide
- What Is Memory in Gemini CLI?
- Gemini CLI Native Memory vs External Memory (GigaRAG)
- Prerequisites for Adding Memory to Gemini CLI
- How To Add Memory To Gemini CLI: A Step-by-Step Guide
- How to Add Memory to Gemini CLI with /memory add
- Using GEMINI.md for Project-Wide Rules
- How to Inspect and Manage Gemini CLI Memory
- Limitations of Gemini CLI Memory You Should Know
- Extending Gemini CLI Memory with GigaRAG for Agent Pipelines
- Common Mistakes When Adding Memory to Gemini CLI
- Best Practices for Gemini CLI Memory Management
- Final Thoughts on Gemini CLI Memory
What Is Memory in Gemini CLI?
Memory in Gemini CLI is saved facts and project rules the assistant keeps across sessions, so you don't repeat yourself every time you open a new conversation.
The CLI stores two kinds of memory: facts you save with /memory add, and rules you write in a GEMINI.md file. Facts are things like "our API uses snake_case" or "the staging server is at 10.0.0.4." Rules are standing instructions: "never commit to main directly."
What counts as memory in Gemini CLI
Anything you explicitly save. The CLI doesn't infer memory on its own. You tell it what to remember, and it writes that to a memory file on disk.
How memory differs from context window
The context window is what the model can see right now. Memory is what it can load back in later. Context resets when the session ends. Memory persists. That's the whole difference, and it's why memory matters for repeat work.
[!note] Gemini CLI's native memory is designed for interactive coding context, not as a production agent memory system. It does not provide memory file selection or built-in external memory integration, so cross-session agent memory requires an external layer.
Gemini CLI Native Memory vs External Memory (GigaRAG)
| Factor | Gemini CLI Native Memory | External Memory (GigaRAG) |
|---|---|---|
| Memory file selection | Not supported; fixed conventions | Configurable memory stores and namespaces |
| External memory integration | Not built in; custom code required | Purpose-built for agent and RAG pipelines |
| Cross-session agent memory | Limited; session-scoped by default | Persistent across sessions and agents |
| Retrieval and ranking | Basic context injection | Retrieval with ranking and relevance controls |
| Production readiness | Best for interactive use | Designed for production agent workloads |
Prerequisites for Adding Memory to Gemini CLI
Before you run /memory add, make sure the CLI is installed and talking to Google's servers. Most setup failures come from skipping this part.
Gemini CLI installation and version check
You need Node.js 18 or newer. Check with node --version. Then install the CLI globally:
npm install -g @google/gemini-cli
Verify it works with gemini --version. If you're on an older build, upgrade with npm update -g @google/gemini-cli. Memory features shipped in recent releases, so a stale install won't have them.
Authentication requirements
Run gemini auth login and follow the browser prompt. You'll need a Google account with Gemini API access enabled. Without auth, the CLI runs but can't save or retrieve anything. If you're behind a corporate proxy, set HTTP_PROXY and HTTPS_PROXY before launching. That's the whole setup.
[!tip] If you are building agent pipelines, treat Gemini CLI memory as a short-term context cache and push durable facts into an external store like GigaRAG. Keep the CLI's GEMINI.md focused on project conventions so retrieval stays fast and relevant.
How To Add Memory To Gemini CLI: A Step-by-Step Guide
- Install or upgrade Gemini CLI and confirm the version with the CLI's version command.
- Create a GEMINI.md file in your project root to hold persistent project context.
- Use the /memory command to view, add, or refresh memory entries during a session.
- Keep memory entries concise and scoped to stable facts, not transient task state.
- Test recall by starting a new session and checking whether the context is applied.
- For cross-session agent memory, connect an external memory layer such as GigaRAG.
- Log what the agent retrieves so you can debug gaps and tune what gets stored.
How to Add Memory to Gemini CLI with /memory add
The command is simple. The workflow around it is where people get lost.
Step-by-step: using /memory add
Start a Gemini CLI session. At the prompt, type /memory add and press Enter. The CLI will ask what you want it to remember. Type the fact, rule, or preference as a plain sentence. Press Enter again to save it.
That's the whole mechanic. No flags, no file paths, no JSON. You're writing a note to your future self, and Gemini will read it back in later sessions.
Example: saving a fact about your project
Say you're working on a Python service that uses Postgres. You want Gemini to stop suggesting SQLite every time you ask for a database query. Type:
/memory add
Then at the follow-up prompt:
This project uses PostgreSQL 16, not SQLite. Connection string lives in .env as DATABASE_URL.
From that point on, when you ask for a schema change or a query, Gemini pulls that memory in and writes Postgres-flavored SQL. You don't repeat yourself.
Verifying the memory was saved
Type /memory by itself. The CLI lists everything you've saved, including the entry you just added. If you don't see it, the save didn't land. Re-run /memory add and check again. Don't assume it worked because the prompt accepted your input.
Using GEMINI.md for Project-Wide Rules
Saved memories are personal. GEMINI.md is shared. That's the split.
What GEMINI.md is and where it lives
GEMINI.md is a plain markdown file that sits in your project root. When Gemini CLI starts in that directory, it reads the file and treats its contents as standing instructions for every session in that project. No /memory add needed. The rules are just there.
You write it once, commit it to version control, and every developer on the team gets the same context. That's the difference from saved memories, which live in your local memory file and don't travel with the repo.
When to use GEMINI.md vs /memory add
Use GEMINI.md for rules that apply to everyone working in the codebase: linting conventions, test commands, deployment steps, which database the project uses. These are project facts, not personal preferences.
Use /memory add for things specific to you: your preferred commit message style, a shorthand you want Gemini to remember, a quirk about how you like diffs explained. These stay local and don't pollute the shared file.
The honest answer is most teams need both. GEMINI.md carries the shared contract. Saved memories carry your working style. Mixing them means either the team inherits your preferences or your personal notes get overwritten by the repo.
How to Inspect and Manage Gemini CLI Memory
Memory hygiene matters. Saved facts go stale, and stale facts steer answers wrong.
Viewing saved memories
Run /memory in the CLI to list what's stored. The output shows each saved fact with its timestamp. You'll see entries from /memory add and anything Gemini saved on its own through the save_memory tool.
The memory file lives in your Gemini CLI config directory. You can open it directly in any text editor. It's plain JSON, so the structure is readable even if the formatting is dense.
Editing and removing memories
Two paths. The quick one: /memory shows entries, and you can delete by index or by matching text. The direct one: edit the JSON file yourself, then restart the CLI so it reloads.
Editing the file by hand gives you full control, but you can break the JSON if you're careless. Make a backup first. Deleting a memory is permanent. There's no undo.
Importing memory isn't a supported command. You can copy entries into the memory file manually, but Gemini CLI won't merge external memory files for you.
Limitations of Gemini CLI Memory You Should Know
Native memory works for interactive sessions. It was not built for agent pipelines. Here's what you can't do.
No memory file selection
Gemini CLI uses one memory file per project. You can't point it at a second file or switch between memory sets. GitHub issue #1102 tracks this: users want to load different memory files for different contexts, and the feature doesn't exist. If you need separate memory for staging vs production, you're stuck.
No external memory integration
The memory file is local JSON. There's no connector for vector databases, no embedding layer, no retrieval API. You can't plug in Pinecone, Weaviate, or a custom store. Memory stays inside the CLI's own file, and nothing outside can query it.
Not designed for production agent pipelines
Cross-session agent memory isn't supported. Each session starts fresh unless you manually re-add facts. There's no shared memory across agents, no versioning, no conflict resolution. For a single developer asking questions, that's fine. For an agent pipeline that needs persistent state across runs, it falls short.
Extending Gemini CLI Memory with GigaRAG for Agent Pipelines
Native memory stops where agent pipelines start. If you're building RAG systems or multi-step agents, you need memory that persists across runs, supports retrieval, and scales beyond a local JSON file. That's the gap GigaRAG fills.
When native memory isn't enough
Gemini CLI memory works for a single developer in an interactive session. It breaks down when you need shared state across agents, versioned memory, or retrieval over large knowledge bases. The local JSON file has no query layer. You can't search it, rank results, or pull relevant context on demand.
How GigaRAG extends memory for RAG pipelines
GigaRAG adds an external memory layer with embeddings and vector search. Instead of storing facts in a flat file, you store them as retrievable chunks. When an agent needs context, it queries GigaRAG, gets ranked results, and injects them into the prompt. This gives you cross-session persistence, shared memory across agents, and retrieval that scales past what a single JSON file can hold.
Example integration pattern
Keep Gemini CLI for interactive work. For agent pipelines, write memory to GigaRAG instead. Your agent saves facts via GigaRAG's API, then retrieves relevant context before each run. The pattern: agent generates output, extracts durable facts, stores them in GigaRAG, and queries on the next run. Native memory handles quick session notes. GigaRAG handles everything that needs to survive and be searchable.
Common Mistakes When Adding Memory to Gemini CLI
Most memory failures aren't mysterious. They come from three predictable mistakes.
Memory not persisting across sessions
You run /memory add, confirm the fact, and it's gone next session. The usual cause: you ran the command in a different working directory. Gemini CLI stores memory per project. If you launch from another folder, you get a different memory file. Check your current directory before adding anything.
Context window overflow
Memory doesn't save you from token limits. Saved facts still get injected into context. If you've stored dozens of long entries, they eat into the window before your prompt does. Prune aggressively.
Confusing GEMINI.md with saved memories
GEMINI.md holds project rules. /memory add holds session facts. Mixing them means rules get buried in memory, or facts get hardcoded into a file that shouldn't change. Keep rules static, memories dynamic.
Best Practices for Gemini CLI Memory Management
Memory gets messy fast. A few habits keep it useful.
Keep memories specific and scoped
Write each memory as one fact, not a paragraph. "API base URL is https://api.staging.example.com" beats "the project uses a staging environment with a specific base URL and some other config details". Specific entries are easier to find and cheaper on tokens. Scope them to what actually changes between sessions.
Regularly prune outdated memories
Set a cadence. After any major refactor or dependency bump, review saved memories and delete what's stale. An outdated memory is worse than no memory: Gemini CLI will trust it and act on wrong information. Check /memory list before starting a new feature branch.
Document memory conventions for your team
Decide what goes in GEMINI.md versus saved memories, and write that down. If one developer stores API keys in memory and another puts them in project rules, you'll get conflicts. A short conventions file saves the argument later.
Final Thoughts on Gemini CLI Memory
Native memory works for interactive sessions. You can save facts, load project rules, and keep context across restarts. That's the whole job, and it does it.
It is not a production memory layer. No memory file selection, no external store, no cross-session agent state. If you're building an agent pipeline, you'll hit those walls within a week.
The honest answer: start with /memory add and GEMINI.md. They're free, built in, and good enough for solo work. When you need retrieval over a vector store or memory shared across agents, that's the point to look at GigaRAG. It plugs in where native memory stops.
Learning how to add memory to Gemini CLI is the first step. Knowing when to outgrow it is the second.
Frequently Asked Questions
Does Gemini have memory?
Yes. Gemini CLI includes native memory so it can retain project context across interactions, typically via a GEMINI.md file and /memory commands. This memory is aimed at interactive coding sessions rather than long-running production agent workloads.
How to import Gemini memory?
Gemini CLI does not expose a general-purpose memory import feature. In practice you add context by placing a GEMINI.md file in your project and using /memory commands to manage entries. For importing external memory, you need a custom integration or an external memory layer.
How can I upgrade a Gemini CLI?
Upgrade Gemini CLI using the same package manager you used to install it, then verify the version with the CLI's version command. Check the official release notes for any changes to memory behavior before relying on it in a pipeline.
How do I configure the Gemini CLI?
Configuration is typically handled through CLI flags, environment variables, and project-level files such as GEMINI.md. Keep configuration in version control so memory and context behavior stays consistent across your team.
Can Gemini CLI remember things across sessions?
Native memory is primarily session-scoped and project-context oriented, so it is not a reliable cross-session agent memory store. For persistent cross-session memory, connect an external memory system such as GigaRAG.
What are the limitations of Gemini CLI memory?
Gemini CLI memory does not support memory file selection, does not include built-in external memory integration, and is not designed for cross-session agent memory. These gaps matter most when you move from interactive coding to production agent or RAG pipelines.
How do I extend Gemini CLI memory for RAG pipelines?
Use Gemini CLI as the interaction layer and route durable memory to an external store like GigaRAG. Store facts with metadata, retrieve them per task, and log retrieval results so you can tune relevance over time.
About GigaRAG
GigaRAG is for agent memory and RAG pipeline builders. get this right. Whether you are working through How to add memory to Gemini CLI or something adjacent, we publish what we have actually tested, including where it falls short.
