Gemini CLI "Untrusted Command Flags Detected" in YOLO mode: how to fix it

You run Gemini CLI with --yolo, and it still stops on a git diff or an npm test and asks for approval with CRITICAL SECURITY WARNING: Untrusted Command Flags Detected. In most cases this is a false positive in version 0.63.0, the current stable release, and the fix already shipped in 0.64.0-preview.1.

This guide explains why the warning shows up, how to confirm it is your case, and the two ways to unblock your workflow. Everything was checked against the source code and releases of the google-gemini/gemini-cli repository on 2026-10-13.

What does "Untrusted Command Flags Detected" mean?

It means Gemini CLI found an argument in the command the model wants to run that also appeared in a part of the conversation marked as untrusted. It treats that as possible prompt injection and requires your approval, even in YOLO mode. The full warning:

⚠️ CRITICAL SECURITY WARNING: Untrusted Command Flags Detected
The following flags/arguments were sourced from external untrusted input (e.g., Buganizer ticket, external document):
  • .github/workflows/testhub.yml
Executing commands with flags sourced from untrusted input can execute arbitrary code on your machine.
Carefully verify these flags before approving.

The idea is sound: if a web page or an MCP response suggests a dangerous flag, the agent should not run it on its own. The problem in 0.63.0 is the number of false alarms.

Why does the warning fire on harmless commands?

Because in 0.63.0 the shell's own output is also treated as untrusted content, and any file path that appeared there now counts as "suspicious". The agent runs ls, sees package.json, and on the next command package.json already triggers the warning.

In the 0.63.0 code, the shell, web_fetch, web search and MCP tools wrap their results in <untrusted_context>. The tracker splits that text into tokens, including breaking paths at every /, and compares them with the arguments of the next command. As a result, your own project's file names become a reason to block.

Version	Behavior	Released
0.62.0	Does not have this check	2026-09-29
0.63.0 (stable, latest tag)	New check, false positives on ordinary paths, even in YOLO	2026-10-06
0.64.0-preview.1 (preview tag)	Includes the fix from PR #29672	2026-10-09
0.65.0 nightly from 10/10 on	Includes the fix	daily

Why doesn't YOLO mode skip the warning?

Because the check runs after the approval policy. When the policy says "allowed" and the command carries taint risk, Gemini CLI overrides the decision: in interactive mode it becomes a confirmation prompt, and in non-interactive mode (gemini -p) the call is denied. In a script or CI, this shows up as a tool blocked by policy, not as a prompt.

Choosing "allow always" does not help either: for a command flagged with this risk, Gemini CLI does not save the approval as a rule. It asks again every time.

How do I confirm it is the 0.63.0 false positive?

Check the installed version:

gemini --version

If it shows 0.63.0 and the warning lists paths from your own project (src/index.ts, package.json, a workflow file), it is the case described in issues #29682 and #29676. If the listed argument came from a page the agent just read, read the command before approving: then the warning is doing its job.

How do I fix "Untrusted Command Flags Detected"?

Install the preview version, which already includes the fix. If you use the npm package:

npm install -g @google/gemini-cli@preview
gemini --version

The second line should show 0.64.0-preview.1 or newer. PR #29672, which landed in that version, stops indexing path segments, limits matching to real risk patterns (URLs, absolute paths, script extensions) and exempts read-only flags such as git -C, ls -la and grep -rn.

Rather not use preview? Roll back to 0.62.0

1. Turn off auto update, otherwise Gemini CLI moves itself back to 0.63.0. In ~/.gemini/settings.json:

   {
     "general": {
       "enableAutoUpdate": false
     }
   }

   The same setting appears in /settings as Enable Auto Update.
2. Install the previous version:

   npm install -g @google/gemini-cli@0.62.0

3. Once the latest tag moves past 0.63.0, turn enableAutoUpdate back on and update.

Avoid the shortcut going around in the issue, patching the package so the check function always returns false. It disables the whole protection, including against a flag genuinely injected by a page or an MCP server.

What about "Build Configuration Was Recently Modified"?

It is another check from the same family, and the fix above does not touch it. If the agent edited a build configuration file during the session and then runs npm, make, pytest or another build or test command, Gemini CLI shows CAUTION: Build Configuration Was Recently Modified and asks for confirmation. Issue #29687, opened on 2026-10-08, reports that this warning repeats on every command, and it is still open.