Gemini CLI ignores .env with custom oauth_creds.json path

[piknockyou]

Description

🐛 Problem

When running Gemini CLI, some users encounter the following error on login:

Failed to login. Message: This account requires setting the GOOGLE_CLOUD_PROJECT env var.
See https://goo.gle/gemini-cli-auth-docs#workspace-gca

According to the Gemini CLI Authentication Docs, this error should only occur in specific cases, but I am seeing this even though none of those cases apply. I only have personal accounts.

---

✅ Workaround

The issue can be resolved by explicitly setting GOOGLE_CLOUD_PROJECT in a .env file located at:

• Windows: %USERPROFILE%\.gemini\
• Linux/macOS: ~/.gemini/

Example:

GOOGLE_CLOUD_PROJECT=YOUR_PROJECT_ID_HERE

After doing so, Gemini CLI starts and works fine. ✅

The same fix also applies for Kilo Code > Settings > Providers > API Provider > Gemini CLI. ✅

---

🚨 Issue with Kilo Code

However, when Kilo Code > Settings > Providers > OAuth Credentials Path (optional) > "YOUR_CUSTOM_PATH_HERE\oauth_creds.json" is configured for API Provider Gemini CLI, Kilo Code disregards the .env file located next to the oauth_creds.json file. In chat, this leads to a Gemini CLI API error ❌:

{
  "error": {
    "code": 403,
    "message": "Permission denied on resource project default.",
    "errors": [
      {
        "message": "Permission denied on resource project default.",
        "domain": "global",
        "reason": "forbidden"
      }
    ],
    "status": "PERMISSION_DENIED",
    "details": [
      {
        "@type": "type.googleapis.com/google.rpc.ErrorInfo",
        "reason": "CONSUMER_INVALID",
        "domain": "googleapis.com",
        "metadata": {
          "containerInfo": "default",
          "service": "cloudaicompanion.googleapis.com",
          "consumer": "projects/default"
        }
      },
      {
        "@type": "type.googleapis.com/google.rpc.LocalizedMessage",
        "locale": "en-US",
        "message": "Permission denied on resource project default."
      },
      {
        "@type": "type.googleapis.com/google.rpc.Help",
        "links": [
          {
            "description": "Google developers console",
            "url": "https://console.developers.google.com/"
          }
        ]
      }
    ]
  }
}

---

🎯 Expected Behavior

• Each profile change (chat mode) or path change (settings) for Gemini CLI should trigger a reload of the .env file that resides alongside the selected oauth_creds.json.

---

🔄 Suggested Fix / Feature Request

• Update the integration of Gemini CLI so that the .env file is dynamically read/reloaded whenever a different Gemini CLI profile is selected.
• Ensure that GOOGLE_CLOUD_PROJECT is consistently applied from the .env file next to the active oauth_creds.json, not just from the one originally loaded at launch.

---

🪜 Reproduce

To reproduce cleanly, you must ensure there’s no “cross-contamination” from the default .gemini folder loading an existing .env file during Kilo Code setup.

1. Close VS Code.
2. Rename existing ~/.gemini folder.
3. Create a .env file inside it; it contains GOOGLE_CLOUD_PROJECT=YOUR_PROJECT_ID_HERE.
4. Start VS Code and set up the Kilo Code provider Gemini CLI with the OAuth Credentials Path pointing to your oauth_creds.json.

Of course, for these steps to be relevant, your account must also be one of those flagged as requiring the GOOGLE_CLOUD_PROJECT setting, as detailed in the Gemini CLI authentication docs.

---

📌 Summary

• Problem: Gemini CLI (vanilla & Kilo Code) requires GOOGLE_CLOUD_PROJECT env var, even for personal accounts where it shouldn't be needed.
• Workaround: Manually creating a .env file with GOOGLE_CLOUD_PROJECT in ~/.gemini/ fixes the issue for the standard CLI and for Kilo Code's default setup.
• Kilo Code Issue: Kilo Code ignores the .env file when a custom path for oauth_creds.json is used, causing API errors.
• Expected Fix: Kilo Code should dynamically load the .env file that is located next to the currently active oauth_creds.json upon profile or path changes.

---

💻 Environment

• OS: Windows 11

---

Related to

#947
#1153
#1199
#1454

cline/cline#4526
google-gemini/gemini-cli#1432
google-gemini/gemini-cli#3001

[benzntech]

After some investigation, I located what seems to be a well-maintained and active fork or successor project that serves the exact same purpose. It may be a useful and stable reference for this discussion:

Working Alternative: https://github.com/ssdeanx/Gemini-CLI-Web

For additional context, both the original project and this alternative are excellent examples of wrapping the official Google Gemini CLI (google-gemini/gemini-cli) in a responsive web interface. They provide a full-featured, IDE-like experience for interacting with the AI from any device.

The architectural pattern they use is particularly insightful. They employ a Node.js backend that acts as an intermediary, executing gemini commands in a child process and streaming the results to a React frontend. This effectively creates a user-friendly GUI for a powerful command-line tool.

The underlying Gemini CLI itself is notable for being designed as an AI agent, equipped with built-in tools for file system operations, web searches, and shell command execution, all of which are made accessible through this web UI.

This pattern of creating a web service to abstract a CLI could be a valuable model to consider for other developer tools. Hope this updated reference is helpful for the ongoing discussion.

[piknockyou]

@benzntech
I perceive your reply as unrelated and a bit spamy.

[benzntech]

@piknockyou Please check the code and implement the same pattern.
https://github.com/ssdeanx/Gemini-CLI-Web/blob/2bef09aadcae171eb48195bfd1c4cf7f4fc32344/server/gemini-cli.js

This implementation shows a different approach. The Gemini CLI tool expects authentication to be handled through a
configuration file (~/.gemini.json) rather than direct API key usage or OAuth tokens. The CLI tool itself manages the
authentication, and applications interact with it as a subprocess.

[AppliedEllipsis]

I had to go into my Google Cloud Projects, delete the gemini-cli project
then I used a different project (I guess you could create a new one) in my .env file
cli worked again, but gemini in kilo didn't, it flagged an error about authorizing gemini for the project with a url to copy and paste.
I visited the URL and it allowed me to authorize gemini and then it started working.

With my main project I tried, it had issues with one of the permissions being granted with the url and told me to request it from my admin, which is me, but never gave me the options or access in the different interfaces.
So I had to use and define another project.

[piknockyou]

@benzntech @AppliedEllipsis

Thanks for trying to help, but I think there's confusion about what this issue reports.

The Specific Bug

When Kilo Code is configured with a custom OAuth Credentials Path (e.g., C:\CustomPath\oauth_creds.json), it ignores the .env file in that same directory (C:\CustomPath\.env).

Instead, it only reads from the default ~/.gemini/.env location, causing the permission error.

Expected: Kilo Code should load .env from the same directory as the custom oauth_creds.json
Actual: Kilo Code ignores it and only uses the default location

This is NOT about:

• Alternative CLI implementations/wrappers
• GCP project setup or authorization flows
• Issues with the default ~/.gemini/ location (that works fine)

@benzntech - Your suggestions don't address this specific path resolution bug in Kilo Code.

@AppliedEllipsis - Your workaround involves GCP project changes, not Kilo Code's .env loading behavior with custom paths.

If you're not using custom OAuth credential paths in Kilo Code settings, you may have different issues worth tracking separately.

[ravibaskaran]

On my Windows 11, the .env file did not exist in the default .gemini folder. So, I created the file and added GOOGLE_CLOUD_PROJECT=YOUR_PROJECT_ID_HERE

However, it still does not work. I am getting the same error

[piknockyou]

On my Windows 11, the .env file did not exist in the default .gemini folder. So, I created the file and added GOOGLE_CLOUD_PROJECT=YOUR_PROJECT_ID_HERE

However, it still does not work. I am getting the same error

@ravibaskaran

My issue is specifically about Kilo Code ignoring .env files when using a custom OAuth Credentials Path setting, not about general Gemini CLI authentication problems with the default setup.

If you're having issues with the default ~/.gemini/.env configuration (not using a custom path), that's a different problem and should be tracked in a separate issue or one of the related issues already linked above.

[rickdeoliveira]

Don't forget to activate (enable) the Google API service

[piknockyou]

Don't forget to activate (enable) the Google API service

@rickdeoliveira

That’s unrelated to this issue. The bug here is specifically about Kilo Code ignoring .env files when a custom OAuth Credentials Path is used, not about Google API activation or project configuration.

[rickdeoliveira]

@piknockyouI shared that because I had the same issue in this thread. Even after setting up the variable and everything else, I still had the problem. However, once I completed the API setup in the Google portal, everything started working. Maybe it was just luck.

[piknockyou]

@rickdeoliveira
Are you really referring to custom paths?

[github-actions]

Closing this one out since it's been inactive for a while — not because it's a bad issue, just that older items tend to lose context over time and we'd rather start fresh if this is still a problem.

Please feel free to reopen (or open a new issue) if you're still running into this. We're happy to take another look! 🙏