What would you like to be added?
Currently, if I define some environment variables at ~/.gemini/.env, and I define some other variables in my project at .gemini/.env, only the project-level file is used; the user-level file is ignored.
Feature request: support hierarchical loading of .env. If multiple .env files are found, then the union of all variables defined would be set. In the case of conflicts, the standard order of precedence (as is used for settings.json) can be applied to choose a winner.
FYI, my use case is that I have my authentication information set at ~/.gemini/.env, and I want it to apply to all projects. But in some projects, I want to provide a custom system prompt, so I set GEMINI_SYSTEM_MD=1. I'd like to configure that in .gemini/.env.
Why is this needed?
For the same reason that multiple settings.json files are supported: users need to apply settings that apply to different scopes.
Additional context
No response
What would you like to be added?
Currently, if I define some environment variables at
~/.gemini/.env, and I define some other variables in my project at.gemini/.env, only the project-level file is used; the user-level file is ignored.Feature request: support hierarchical loading of
.env. If multiple.envfiles are found, then the union of all variables defined would be set. In the case of conflicts, the standard order of precedence (as is used forsettings.json) can be applied to choose a winner.FYI, my use case is that I have my authentication information set at
~/.gemini/.env, and I want it to apply to all projects. But in some projects, I want to provide a custom system prompt, so I setGEMINI_SYSTEM_MD=1. I'd like to configure that in.gemini/.env.Why is this needed?
For the same reason that multiple
settings.jsonfiles are supported: users need to apply settings that apply to different scopes.Additional context
No response