Version-aware troubleshooting · Google docs checked Nov 3, 2026
Why does Gemini CLI ask again in a new terminal?
Diagnose repeated Gemini CLI tool approval prompts across terminal sessions by checking the exact CLI version, launch mode, settings scope, and loaded policies.
Why is Gemini CLI asking me to approve the same tool in a new terminal?
The report in issue #4340 describes this symptom, but it was filed in 2025 and closed as not planned in 2026. It does not prove that current releases have a general bug. First record `gemini --version`, the exact tool or command being approved, and the project directory; then compare the two launches using the same version, directory, and settings.
Does choosing “Always” guarantee approval will persist across terminals?
The issue author says their choice did not persist. Current official docs describe persistent settings files and policy rules, but do not define that prompt choice as a cross-session persistence contract. Treat the prompt response as unverified until you reproduce it on your installed version; do not infer persistence from the word “Always.”
Which settings should I check first?
Gemini CLI documents `general.defaultApprovalMode` in `settings.json`. User settings at `~/.gemini/settings.json` apply across that user's sessions, project settings at `<project>/.gemini/settings.json` apply within that project and override user settings, and system settings may override both. Command-line arguments such as `--approval-mode` override other configuration for that launch only. Check the setting with `/settings` and compare the directory and launch command between terminals.
Could an approval policy explain the repeated prompt?
Yes. Current documentation supports persistent TOML policies in `~/.gemini/policies/*.toml`, and `/policies list` displays active policies. Rules can match a tool, command prefix, approval mode, or execution environment; a matching `ask_user` rule can keep prompting. Check loaded rules and their scope before changing them. The documentation currently marks project-level `.gemini/policies` as disabled, so do not assume a workspace policy file is loaded.
What is a safe way to reproduce the issue?
Use a harmless, read-only operation that normally triggers the same approval prompt. Record the CLI version, exact launch command, current directory, approval mode, relevant user/project settings, and `/policies list` output. Make the same approval choice, repeat once in the same process, then close and reopen the CLI in the same directory and repeat. Change only one variable at a time; stop if the prompt concerns a consequential command or file change.
Should I use `--yolo` to stop the prompts?
This guide does not recommend broad auto-approval as a persistence fix. Google documents `--approval-mode` choices and `--yolo`, but those change the approval behavior for a launch rather than establish why a prior prompt choice was not reused. Prefer diagnosing the setting or a narrowly matched policy, and review any command before authorizing it.
How can I configure an approval rule that survives new sessions?
If a persistent rule is appropriate for your use case, Google documents TOML policies under `~/.gemini/policies/`. Make a narrow rule for a specific tool or command, then check `/policies list` and verify it with a harmless example. For example, a `run_shell_command` rule with `commandPrefix = "git status"` can match commands beginning with that prefix; inspect the exact matching behavior and avoid broad write or destructive-command allowances. Policy configuration is distinct from the prompt’s “Always” selection.
Does issue #4340 confirm a current Gemini CLI bug?
No. It is a qualitative report from one environment, with follow-up comments from other users; it was closed as not planned, and the issue does not identify a current release-wide root cause or fix. Use it as a reproduction lead only, and report the installed version and minimal steps if you file a new issue.
What should I include in a useful bug report?
Include the output of `gemini --version` and `/about`, operating system and shell, exact launch command, current directory, the tool name and sanitized command, approval mode, relevant settings scope, and whether `/policies list` shows a matching rule. Say whether the permission repeats in the same process and after restarting. Remove prompts, transcripts, environment values, repository data, and credentials that are not needed to reproduce the behavior.
Sources
- Gemini CLI issue #4340 · historical cross-session report and closure · checked Nov 3, 2026
- Gemini CLI configuration reference · persistent settings and per-launch overrides · checked Nov 3, 2026
- Gemini CLI policy engine · policy files, matching, and decisions · checked Nov 3, 2026
- Gemini CLI commands reference · `/settings`, `/policies list`, and `/about` · checked Nov 3, 2026