The Problem

When running gemini-cli from within a project that has its own .env file (e.g., a Python project using python-dotenv), the CLI attempts to load that project's .env file. This can cause authentication failures if the project's .env file does not contain the GEMINI_API_KEY or other necessary environment variables for the Gemini CLI.

This behavior forces users to either:

1. Add their Gemini API key to every project's .env file, which is not ideal for security or convenience.
2. Temporarily rename or move the project's .env file, which is disruptive to the project's workflow.

Proposed Solution

Provide a mechanism to force the Gemini CLI to ignore the local project's .env file and instead use the global ~/.gemini/.env file.

This could be implemented as:

• A command-line flag:

  gemini --use-global-env

• A setting in ~/.gemini/settings.json:

  {
    "ignoreLocalEnv": true
  }

Why is this needed?

This feature would improve the user experience by:

• Preventing conflicts: It would prevent conflicts between the Gemini CLI's environment variables and the project's environment variables.
• Improving security: It would avoid the need to store the Gemini API key in multiple project-specific .env files.
• Increasing convenience: It would allow users to run the Gemini CLI from any project without having to worry about .env file conflicts.