gemini-cli - 💡(How to fix) Fix Feature: GEMINI.md context discovery should traverse git submodules [1 participants]

What would you like to be added?

Make GEMINI.md auto-discovery traverse into git submodules instead of stopping at submodule boundaries.

Today, when you launch gemini from inside a git submodule, the parent repo's GEMINI.md is not picked up — even though the submodule directory is physically nested inside the parent on disk. The reverse is the same: from the parent, GEMINI.md files inside submodules are ignored.

Repro:

project/                       ← parent repo
├── GEMINI.md
└── api/                       ← submodule (has .git file)
    └── GEMINI.md

• cd project && gemini → loads project/GEMINI.md, ignores project/api/GEMINI.md
• cd project/api && gemini → loads project/api/GEMINI.md, ignores project/GEMINI.md

The discovery chain breaks at the inner .git file.

Why is this needed?

Common monorepo-with-submodules layout: the parent repo holds ecosystem-wide context (architecture overview, how services talk to each other, shared conventions), and each submodule has its own service-specific context. That parent context is just as relevant when working inside a submodule, and submodule context is just as relevant when working from the parent on a cross-cutting task.

The workarounds today are all bad:

• Duplicate the parent context into every submodule's GEMINI.md — DRY violation, drifts immediately.
• Use @import ../GEMINI.md from inside each submodule — works, but it's manual per-submodule, brittle to renames, and inverted (a submodule shouldn't have to know about parent layout).
• Put ecosystem context in ~/.gemini/GEMINI.md — pollutes global config with one project's stuff and breaks if you work on a second monorepo or switch machines.

The mental model users actually have: GEMINI.md inheritance follows the directory tree. A submodule being a separate git repo is an implementation detail of git — from the user's and the model's perspective, project/api/ is just a folder under project/.

Additional context

Parallel to anthropics/claude-code#44884 — same root cause filed for Claude Code. Worth flagging as a cross-vendor pattern: the same hierarchical discovery model breaks on submodules in both tools.

Also relevant if/when #12345 lands and AGENTS.md becomes a default context filename — the same boundary problem will apply, since it's traversal logic, not filename-specific. Same goes for users on the array form of contextFileName (since #18598): the fix should apply uniformly to every configured name.

Environment: Windows 11, monorepo with 8+ submodules across mixed stacks (Node.js, Next.js, Lua).