How to Fix Common Gemini CLI Authentication Errors

Most Gemini CLI failures are not about your prompt; they are about authentication. A stale login, a missing key, or a hit quota all surface as confusing errors. This guide walks through the usual suspects and the exact fix for each.

What you need

• The Gemini CLI installed
• Your Google account or API key handy
• Terminal access
• About 6 minutes

Step 1: Read the error, not just the red text

Auth errors come in a few flavors. A 401 or unauthenticated message means your credentials are wrong or missing. A 403 often means the key lacks permission or the API is not enabled. A 429 means you have hit a rate or quota limit. Identify which one you have before changing anything.

Step 2: Fix a missing or wrong API key

If you authenticate with a key, confirm the variable is actually set in the shell you are running from. A common trap is exporting the key in one terminal tab and running the CLI in another. Echo it to check, and re-export if it is empty.

echo $GEMINI_API_KEY
# if empty, set it again:
export GEMINI_API_KEY="AIza...your-key..."
# verify the key itself is valid:
curl "https://generativelanguage.googleapis.com/v1beta/models?key=$GEMINI_API_KEY"

Step 3: Reset a broken Google sign-in

If you use Login with Google and tokens have gone stale, clear the cached credentials and sign in fresh. The CLI stores them under your home folder; removing that file forces a clean re-auth on next launch.

Step 4: Handle a 429 quota error

A 429 means you are sending requests faster than your tier allows, or you have used up the day's free quota. Wait for the window to reset, slow your request rate, or switch to a paid key with higher limits. Switching from Pro to Flash also helps, since Flash has more generous limits.

Result

With the error type identified, the fix is usually fast: re-export the key, reset Google sign-in from /auth, or wait out a quota window. Once credentials are sorted, the same prompt that failed will run cleanly.