Gemini CLI blocks build commands after untrusted file edits

Gemini CLI's September 12 nightly blocks a build command from running right after it edits the file that command depends on. The fix targets a specific bypass. An untrusted instruction buried in conversation history could rewrite package.json, Makefile, pyproject.toml or BUILD.bazel, then trigger the script it just planted with no confirmation gate.

The CLI tracks tokens pulled from <untrusted_context> blocks in conversation history. Editing package.json, Makefile, pyproject.toml or BUILD.bazel requires explicit confirmation first. Before running npm run, make, cargo or blaze, it checks for both signals at once, a build file that's been touched and untrusted flags nearby. If both are present, the command downgrades to ASK_USER. Any persistent approval already granted for that command gets suppressed, so it can't skip the confirmation prompt.

Gating on the combination is sharper than gating on either signal alone. A build-file check with no untrusted-context requirement blocks a lot of the user's routine edits. An untrusted-context check with no build-file requirement misses the case where the untrusted content is what wrote the build file in the first place.

The pull request bundles a second fix, tighter sandbox filesystem boundaries and isolated runtime state. That limits what a compromised session can reach even before the build-command check fires.

The PR doesn't say how the untrusted-context detection handles content split across multiple tool calls, an open question for anyone trying to break it.