Environment troubleshooting · Google docs checked Nov 3, 2026
Why does Gemini CLI skip its prompt when a CI_ variable is set?
Diagnose a Gemini CLI session that shows its welcome screen but no interactive prompt when CI, CONTINUOUS_INTEGRATION, or a CI_-prefixed variable is present. Separate accidental detection from deliberate CI automation.
What symptom points to CI environment detection?
The welcome screen appears but Gemini CLI never shows or accepts the interactive input prompt. Google's troubleshooting guide says the `is-in-ci` check detects `CI`, `CONTINUOUS_INTEGRATION`, or any variable beginning with `CI_`, and that this can prevent interactive mode from starting. This symptom is a clue, not proof; first check the environment inherited by the exact shell that launches Gemini CLI.
How can I check variable names without exposing their values?
In Bash or Zsh, list only matching names with `compgen -e | grep -E '^(CI|CONTINUOUS_INTEGRATION|CI_)'`. Do not run or share an unfiltered `env` dump: it can contain credentials. If the shell has no matching names, check the terminal launcher, IDE, task runner, or parent process that starts it, and compare with a clean terminal.
How do I test whether one CI_TOKEN variable is the cause?
On a Unix-like shell, Google documents `env -u CI_TOKEN gemini` as a way to start Gemini CLI with that one variable removed for that command. Substitute the exact incidental variable name you found. If the prompt returns, the environment-name collision is a plausible cause. This test does not establish why the variable was set, and it should not be used to remove required CI configuration from a job.
Should I unset CI variables inside a real CI job?
Usually the diagnostic's purpose is different: if the process is intentionally running in CI, use a documented non-interactive invocation rather than expecting a terminal prompt. The current CLI reference documents `gemini -p "prompt"` as non-interactive and describes `--output-format` options. Keep required job environment and credentials intact; do not unset broad variables to force a prompt in an unattended job.
What is the smallest safe reproduction?
In a disposable terminal, set a harmless name such as `CI_TOKEN=example`, launch `gemini`, and note whether the prompt appears. Then launch `env -u CI_TOKEN gemini` and compare. Do not put a real token in the test value, type secrets into a transcript, or share environment dumps. If reproducing in a real CI pipeline, avoid printing secret variables and use a minimal test job.
Does this mean Gemini CLI is generally broken in CI?
No. The documented behavior concerns interactive mode when CI indicators are present. The CLI reference separately documents `-p/--prompt` for non-interactive use. Issue #1563 reports a user environment collision, while #1864 is marked as its duplicate; they do not show that all CI jobs fail or establish a current widespread defect.
What if removing the variable does not restore the prompt?
Check for all three documented detection forms (`CI`, `CONTINUOUS_INTEGRATION`, and `CI_`-prefixed names), then compare the exact Gemini CLI version, shell, and terminal in a clean environment. If the issue remains, follow Google's troubleshooting guidance and report a minimal reproduction with variable names only, sanitized command details, CLI version, OS, and terminal. Never include variable values or tokens.
Sources
- Gemini CLI troubleshooting · CI detection and documented `env -u` example · checked Nov 3, 2026
- Gemini CLI command reference · interactive and `-p` non-interactive modes · checked Nov 3, 2026
- Gemini CLI issue #1563 · user report with `CI_TOKEN` reproduction · opened Jun 25, 2025
- Gemini CLI issue #1864 · related prompt/cursor report, closed as duplicate of #1563 · opened Jun 26, 2025