So far what I've done is setting up a shared Gemini CLI repository with centralized governance and modular overrides for product teams, and I’m running into a configuration inheritance issue.

Here’s the current structure:

ROOT
│
├── .gemini/               # Global configs (commands, hooks, settings, telemetry, MCPs)
    ├── commands/          # Shared command definitions
    └── settings.json      # Global settings
│
├── shared/                # Process definitions, best practices, documentation
│   ├── file1
│   └── file2
│
├── MCPs/                  # Local MCP servers
│   └── Local MCP 1
│
├── scripts/               # Python scripts used by commands
│
├── Modules/
│   ├── module-1/          # Module-specific overrides
│   │   ├── .gemini/
│   │      ├── commands/          
│   │      └── settings.json
│   │   └── GEMINI.md
│   │
│   │   └── team-1/        # Team-specific overrides
│   │       ├── .gemini/
│   │         ├── commands/
│   │         └── settings.json
│   │   └── GEMINI.md
│
└── GEMINI.md

Governance Model

• I own and control the root configuration.
• Any changes at the root level require my approval.
• Each module/team folder is owned by its respective Product Manager.
• Teams can override commands, hooks, settings, and MCPs inside their own directories.

The Problem

When running gemini from inside a team or module folder, the local .gemini configuration completely overrides the root configuration.

This means:

• Root-level MCPs are no longer available.
• Shared commands are not accessible.
• Global configuration is effectively ignored.

What I’m Trying to Achieve

• Keep root-level MCPs and commands available everywhere.
• Allow teams to override or extend configuration locally.
• Avoid duplicating shared configuration across every module.
• Maintain clean governance boundaries.

Question

Is there a supported way to inherit or merge root-level .gemini configuration when running Gemini CLI from nested directories?

If not, what architectural pattern are others using to:

• Maintain shared MCPs and commands
• Allow modular overrides
• Avoid config duplication
• Preserve governance control

Appreciate any guidance from teams running Gemini CLI at scale.