gemini-cli - 💡(How to fix) Fix OAuth-authenticated CLI hangs on SSH TTY but works from RDP/desktop terminal

Description

Gemini CLI hangs during startup when launched from an SSH TTY, even after OAuth login has completed successfully from a desktop/RDP terminal. The same cached OAuth state works when Gemini CLI is launched from the RDP/desktop terminal environment.

This looks like startup/session-environment handling rather than an OAuth token problem: after successful desktop login, ~/.gemini/google_accounts.json contains an active account, and a prompt succeeds when launched with the desktop terminal's environment. In SSH, startup hangs before writing new useful logs and before a model request appears to complete.

Personal details redacted below.

Environment

• Gemini CLI: 0.41.2
• Also tested briefly with 0.42.0-preview.2; the startup/OAuth behavior did not improve, so I reverted to stable.
• Node.js: v22.22.1
• npm: 10.9.4
• OS: Ubuntu 24.04.4 LTS (noble)
• Kernel: Linux 6.17.0-22-generic x86_64
• Auth mode: security.auth.selectedType = "oauth-personal"
• Account type: personal Google account with Google One / Google AI Pro subscription

Cached auth state after successful desktop/RDP login

~/.gemini/settings.json:

{
  "security": {
    "auth": {
      "selectedType": "oauth-personal"
    }
  }
}

~/.gemini/google_accounts.json:

{
  "active": "<personal-gmail-with-google-one-ai-pro>",
  "old": []
}

~/.gemini/oauth_creds.json was also written after the RDP/desktop login.

Reproduction

1. SSH into the Ubuntu host.
2. Run gemini in the SSH TTY.
3. Choose Google OAuth login, or run after OAuth has already been completed from desktop/RDP.
4. Observe that gemini hangs during startup in SSH.
5. Start an RDP session on the same host, open a desktop terminal, run gemini, and complete OAuth login.
6. From the RDP desktop terminal, Gemini CLI works and can make a model call using the OAuth account.
7. From SSH again, gemini still hangs on startup unless launched with environment variables copied from the RDP desktop session.

Observed behavior

In SSH, gemini starts a parent and child Node process and then hangs. It often requires:

pkill -9 -f /home/<user>/.npm-global/bin/gemini

The SSH environment includes:

DBUS_SESSION_BUS_ADDRESS=unix:path=/run/user/1000/bus
SSH_TTY=/dev/pts/2
TERM=xterm-256color

The RDP/desktop terminal environment includes:

DISPLAY=:10.0
DBUS_SESSION_BUS_ADDRESS=unix:path=/tmp/dbus-<redacted>,guid=<redacted>

A wrapper that reuses the RDP terminal's DISPLAY and DBUS_SESSION_BUS_ADDRESS from /proc/<gnome-terminal-server-pid>/environ allows an SSH-launched headless prompt to succeed:

timeout 45s gemini-ssh -p 'Say ok' --output-format json

That returns a successful response ("ok"). This strongly suggests the cached OAuth credentials are valid and the failure is tied to SSH/TTY startup/session integration.

Expected behavior

After OAuth credentials have been cached locally, Gemini CLI should be usable from an SSH TTY on the same host without requiring a live RDP/desktop terminal environment.

If a browser/desktop session is needed only for the initial OAuth callback, subsequent runs should not depend on the desktop DISPLAY/DBus session.

Additional notes

• NO_BROWSER=true did not avoid the startup hang in SSH.
• Running with DBUS_SESSION_BUS_ADDRESS unset did not fully resolve it.
• A short strace showed activity against DBus/Freedesktop paths before the hang, but no useful CLI error was printed.
• gemini --help works normally; the hang appears in normal startup/auth/model initialization paths.

Impact

This blocks using Gemini CLI from normal SSH sessions on a remote Linux workstation, even though OAuth login and model calls work from a desktop terminal on the same machine.