OAuth succeeds and credentials are saved, but Gemini CLI 0.50.0 keeps re-entering auth flow on macOS

### What happened?

Gemini CLI 0.50.0 on macOS repeatedly re-enters the Google OAuth authentication flow even though OAuth appears to succeed and credentials are saved locally.
This does not appear to be a browser callback or localhost listener failure. I verified that the local callback endpoint receives the authorization code, the CLI redirects to the Gemini Code Assist success page, and the CLI logs Authentication succeeded.
However, subsequent runs still start a new OAuth flow instead of reusing the saved OAuth credentials.
I also tested API-key authentication during troubleshooting, so I cannot treat later successful chat/session logs as proof that oauth-personal reached a usable session. This report is specifically about OAuth success, saved OAuth credentials, and repeated re-authentication.
Relevant verified behavior:
Attempting to open authentication page in your browser.
Waiting for authentication...
Authentication succeeded

Attempting to open authentication page in your browser.
Waiting for authentication...
Authentication succeeded

Attempting to open authentication page in your browser.
Waiting for authentication...
Authentication succeeded
In the actual log, each OAuth attempt uses a different local callback port and a different state value.

### What did you expect to happen?

After OAuth succeeds and credentials are saved, subsequent runs should reuse the saved OAuth credentials and enter the CLI session without prompting for Google login again.

### Client information

* Gemini CLI version: 0.50.0
* OS: macOS / darwin
* Architecture: arm64
* Install method: npm global
* Node version: v25.9.0
Configured auth mode in ~/.gemini/settings.json:
{
"security": {
"auth": {
"selectedType": "oauth-personal",
"enforcedType": "oauth-personal"
}
},
"selectedAuthType": "oauth-personal"
}
I am aware that Node v25.9.0 is a non-LTS/current release. I have not yet verified whether the same behavior occurs on Node 22 LTS or Node 20 LTS.

### Login information

Login method: Google OAuth / oauth-personal
The local OAuth callback reaches Gemini CLI. I forced a fixed callback port and captured loopback traffic.
Sanitized callback request:
GET /oauth2callback?code=&state= HTTP/1.1
Host: 127.0.0.1:
Sanitized callback response:
HTTP/1.1 301 Moved Permanently
Location: https://developers.google.com/gemini-code-assist/auth_success_gemini
After authentication, ~/.gemini/oauth_creds.json exists and contains these keys:
access_token
expiry_date
id_token
refresh_token
scope
token_type
The saved scope includes:
https://www.googleapis.com/auth/cloud-platform
openid
https://www.googleapis.com/auth/userinfo.email
https://www.googleapis.com/auth/userinfo.profile
~/.gemini/google_accounts.json also exists and contains:
active
old
Environment and config pollution checks:
env | grep -Ei 'GEMINI|GOOGLE|VERTEX|CLOUD|APPLICATION_CREDENTIALS'
This returns no output.
I also checked shell config files and found no relevant entries:
grep -nEi 'GEMINI_API_KEY|GOOGLE_API_KEY|GOOGLE_GENAI_USE_VERTEXAI|GOOGLE_CLOUD_PROJECT|GOOGLE_CLOUD_PROJECT_ID|GOOGLE_CLOUD_QUOTA_PROJECT|GOOGLE_APPLICATION_CREDENTIALS|CLOUDSDK_CONFIG' \
~/.zshrc ~/.zprofile ~/.zshenv ~/.bash_profile ~/.bashrc ~/.profile 2>/dev/null
I checked for relevant .env files and found no relevant API-key or Google credential entries.

### Anything else we need to know?

Running Gemini CLI with a clean environment still re-enters the auth flow:
GEMINI_BIN="$(command -v gemini)"

env -i \
HOME="$HOME" \
USER="$USER" \
SHELL="$SHELL" \
TERM="$TERM" \
PATH="/opt/homebrew/bin:/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin" \
"$GEMINI_BIN" --debug
I also tested with an isolated temporary HOME:
TMPHOME="$(mktemp -d)"
mkdir -p "$TMPHOME/.gemini"

cat > "$TMPHOME/.gemini/settings.json" <<'JSON'
{
"security": {
"auth": {
"selectedType": "oauth-personal",
"enforcedType": "oauth-personal"
}
},
"selectedAuthType": "oauth-personal"
}
JSON

chmod 700 "$TMPHOME/.gemini"
chmod 600 "$TMPHOME/.gemini/settings.json"

env -i \
HOME="$TMPHOME" \
USER="$USER" \
SHELL="$SHELL" \
TERM="$TERM" \
PATH="/opt/homebrew/bin:/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin" \
NO_BROWSER=true \
"$(command -v gemini)" --debug
This also did not produce a stable reusable OAuth session. The CLI still returned to an authentication flow instead of persisting a usable oauth-personal session.
During troubleshooting, I also tested API-key authentication. Some later chat/session logs may have been generated under API-key authentication, so I am not using those as evidence that oauth-personal reached a usable chat session.
The reliable evidence is:
* local OAuth callback receives code=
* local server redirects to auth_success_gemini
* CLI logs Authentication succeeded
* oauth_creds.json is created with access_token, refresh_token, and id_token
* settings.json is set to oauth-personal
* environment variables, shell configs, and .env files do not appear to override auth
* clean environment still reproduces the auth loop
* isolated temporary HOME still does not produce a stable reusable OAuth session
This looks like an OAuth credential reuse, session validation, or Code Assist account resolution issue rather than a browser, localhost, or local credential file creation issue.

Start by reproducing with Gemini CLI 0.50.0 on macOS using the clean-environment and isolated temporary HOME commands from the report. Inspect how ~/.gemini/oauth_creds.json and settings.json are loaded and validated after oauth-personal login; done means a successful OAuth flow reuses the saved credentials on subsequent runs without prompting again.

Written by the indexing model from the issue text.