Project-specific context is incorrectly saved to global user memory.

[jadmadi]

What happened?

While working within a specific project directory, the Gemini CLI agent saved detailed, project-specific information to the global user memory file located at ~/.gemini/GEMINI.md. This pollutes the global memory with context that should not persist or be applied to other projects.

Steps to Reproduce:

1. Start a session with the Gemini CLI in a project directory.
2. Perform tasks related to the project (e.g., discuss files, run builds, modify code).
3. Observe that the agent saves memories related to the project's structure, files, and purpose.
4. Check the contents of ~/.gemini/GEMINI.md and see the project-specific data.

Example of incorrect data saved:

1. Gemini Added Memories

2. The user prefers to use pnpm for package management.
3. The user's project is a Web Games API using Cloudflare Workers and D1. The D1 database is named games-warehouse and is bound as DB. The main worker script is src/index.js. The API is

4.  documented in `api.md`.
   

5. The Cloudflare Worker (src/index.js) now includes CORS headers (Access-Control-Allow-Origin: *) to resolve cross-origin issues. The test.html file has been updated with an improved Arabic UI and enhanced game logic, including more relevant incorrect options for the "Challenge" game.

What did you expect to happen?

• The global memory file (~/.gemini/GEMINI.md) should only store generic, user-level preferences that are applicable across all projects (e.g., "The user prefers to use pnpm").
• Project-specific context should be managed in-session and not be written to the persistent global memory file.

Client information

• CLI Version: 0.1.21
• Git Commit: 055fe46d
• Operating System: linux v20.18.1
• Sandbox Environment: no sandbox
• Model Version: gemini-2.5-pro
• Memory Usage: 164.5 MB

Login information

Not applicable/required.

Anything else we need to know?

This bug is problematic because it can cause the agent to mistakenly carry over context from one project to another, leading to confusion and incorrect actions. The agent itself confirmed this was incorrect behaviour.

[jacob314]

This seems more like an enhancement than a bug. How might we know when the user wants to save project specific memories versus global memories? Would be curious what the UX for this should be.

[gitenstuff]

@jacob314 It's a bug because my global GEMINI.md clearly says to save memories to the local .gemini/GEMINI.md file. I've tried a dozen different ways to word that, including getting suggestions from gemini, itself.

-> no matter what the wording, the directive is ignored.

My current entry, which gemini says should do the trick is:

# AI Configuration Files (GEMINI.md, CLAUDE.md, etc)
- Edits or new ai configuration files (GEMININ.md, CLAUDE.md, etc) must strictly follow the structure and format of this document.
- New entries must be put in proper section. 
- Edits and new entries must be compared with existing entries to ensure they are not redundant or conflicting.
- Conflicting entries must be brought to the attention to the user for remediation.
- Default memory config is ./.gemini/GEMINI.md (LOCAL to the current project workspace).
- When adding new memories (using save_memory or similar tools), ALWAYS write them to the LOCAL project's .gemini/GEMINI.md file (create it if it doesn't exist).
- NEVER write project-specific memories to the global ~/.gemini/GEMINI.md file.

[gemini-cli[bot]]

Hello! As part of our effort to keep our backlog manageable and focus on the most active issues, we are tidying up older reports.

It looks like this issue hasn't been active for a while, so we are closing it for now. However, if you are still experiencing this bug on the latest stable build, please feel free to comment on this issue or create a new one with updated details.

Thank you for your contribution!