## Precedence / Override Order Here is how Gemini CLI decides which config takes effect when there are conflicts. Highest precedence > lower precedence. ``1. Command-line arguments 2. Environment variables (or `.env`) 3. Project settings file (`.gemini/settings.json`) 4. User settings file (`~/.gemini/settings.json`) 5. System settings override file (`/etc/gemini-cli/settings.json` etc.) 6. System defaults file (`/etc/gemini-cli/system-defaults.json`, or platform equivalent) 7. Built-in defaults (hardcoded values in the app)`` Notes: - Some docs list two system settings files (“defaults” and “override”). The “override” one has higher precedence than user & project settings. [Google Gemini](https://google-gemini.github.io/gemini-cli/docs/cli/configuration.html?utm_source=chatgpt.com) - Environment variables and CLI arguments always override any setting from files. [Medium+1](https://medium.com/google-cloud/gemini-cli-tutorial-series-part-3-configuration-settings-via-settings-json-and-env-files-669c6ab6fd44?utm_source=chatgpt.com) - `GEMINI.md` context files are loaded in a hierarchical manner: global then project then possibly subdirectory. It’s less about “override” of specific keys and more about how contexts are combined. [Philschmid+1](https://www.philschmid.de/gemini-cli-cheatsheet?utm_source=chatgpt.com) ``` Built-in defaults (hardcoded in binary) │ ├── System defaults file │ └── /etc/gemini-cli/system-defaults.json │ ├── System settings override file │ └── /etc/gemini-cli/settings.json │ ├── User settings │ └── ~/.gemini/settings.json │ ├── Project settings │ └── .gemini/settings.json │ ├── Environment variables / .env files │ └── GEMINI_API_KEY=... │ └── Command-line arguments └── gemini --model=... --temperature=... ``` **Special files (not strict overrides, but loaded if present):** ``` ~/.gemini/GEMINI.md ./GEMINI.md (project-level context) ```