Skip to content

Where Gemini CLI stores GEMINI.md, settings, commands, and MCP servers

Gemini CLI (Google’s open-source terminal agent) keeps its context in a global ~/.gemini/ folder, per-project .gemini/ folders, and GEMINI.md files scattered through your repos. Its one structural quirk: there is no separate MCP config file — MCP servers live inside settings.json. ~ is your home directory; paths starting with .gemini/ are relative to a project root.

ArtifactGlobalPer-projectFormat
Context files (rules)~/.gemini/GEMINI.mdGEMINI.md (root, ancestors, and subdirectories)Markdown
Settings~/.gemini/settings.json.gemini/settings.jsonJSON
MCP servers~/.gemini/settings.jsonmcpServers.gemini/settings.jsonmcpServersJSON (inside settings)
Custom commands~/.gemini/commands/**/*.toml.gemini/commands/**/*.tomlTOML
Extensions~/.gemini/extensions/<name>/gemini-extension.jsonJSON + bundled files
System settings/etc/gemini-cli/settings.json (Linux), C:\ProgramData\gemini-cli\settings.json (Windows), /Library/Application Support/GeminiCli/settings.json (macOS)JSON

Gemini CLI concatenates context from a documented hierarchy: the global ~/.gemini/GEMINI.md, then GEMINI.md files from your working directory up through each parent to the project root (a .git folder) or home, then any in subdirectories below you (scanned up to 200 directories by default). Closer files come later, so they effectively refine the broader ones. Context files can pull in others with @path/to/file.md imports, and /memory show prints exactly what got loaded.

settings.json — four layers, surprising precedence

Section titled “settings.json — four layers, surprising precedence”

Settings merge from system defaults → user (~/.gemini/settings.json) → project (.gemini/settings.json) → system override (/etc/gemini-cli/ settings.json on Linux, C:\ProgramData\gemini-cli\settings.json on Windows, /Library/Application Support/GeminiCli/settings.json on macOS).

String values in settings can reference environment variables ("apiKey": "$MY_TOKEN"), and the CLI auto-loads .env files — from the current directory upward, then ~/.env — so secrets tend to live one hop away from the config that names them.

MCP servers are a mcpServers map inside settings.json — there is no .gemini/mcp.json. Entries carry command/args/env/cwd for stdio servers or url/httpUrl/headers for remote ones, plus trust, includeTools, and excludeTools. Setting trust: true skips tool-call confirmations for that server, so it deserves the same review as an always-allow permission. The env and headers blocks are where API keys end up — treat both settings files as secret-adjacent.

Commands are TOML files, not Markdown: ~/.gemini/commands/ (all projects) or .gemini/commands/ (one project), each file with a required prompt field and optional description. Subdirectories namespace the name — commands/git/commit.toml becomes /git:commit — and a project command shadows a global one with the same name.

Installed extensions live under ~/.gemini/extensions/<name>/, each with a gemini-extension.json manifest. An extension can bundle its own MCP servers (mcpServers), its own context file (contextFileName, defaulting to a GEMINI.md in the extension folder), and its own commands/ directory of TOML commands — all loaded at startup. That makes extensions a capability surface that never appears in your settings files: servers and rules you didn’t write are running from a folder most people never open.

Quartermaster’s scanner indexes every location on this page — including extension bundles under ~/.gemini/extensions/ and one record per MCP server parsed out of settings.json — into one searchable registry alongside Claude Code, Cursor, Codex, and 8 more tools. It can convert a GEMINI.md to CLAUDE.md or AGENTS.md (and back), and secrets are never indexed — env/header key names kept, values dropped. See the full discovery map or the quickstart.