Shared machines change the math for AI coding assistants in a way that solo workflows do not. On a solo laptop, the developer can read the diff (the line-by-line change list) before committing. On a shared CI (continuous integration, the automated build-and-test pipeline) runner, the diff is one of a hundred things happening in parallel and the only reviewer is whatever alert fires when the build breaks, which means a malicious edit only gets caught if it breaks the build, and most malicious edits are designed not to break the build. That asymmetry is the whole reason a new safeguard in Google’s Gemini CLI matters, even though the feature is going to look boring in every screenshot of it.
The Gemini CLI now pauses before editing any file that controls how a project builds, installs, or ships, and asks the human at the keyboard first. That is the whole thing. The agent does not silently rewrite dependency manifests (the files that declare which libraries a project depends on), container recipes, or CI configs when it thinks the project needs them. It asks. The pause is the feature, and the rest of this article is about why the pause is worth installing an update for.
The shape of the attack this feature blocks
The specific risk is prompt injection (an attack where hostile text in a webpage, bug report, or log file tells the model to do something the user did not ask for). Build files are a perfect target because they run on every machine that clones the repo, including production deployment pipelines. A subtle change to a Dockerfile (a recipe file that builds a container image) that pulls from a slightly wrong base image, or to a CI workflow that runs an extra step, is invisible to anyone who reviews the diff quickly. The change is just text. The damage only happens when the file runs.
The AI assistant is not the failure point here. The AI assistant is doing exactly what it was built to do, which is to apply whatever fix the user appears to be asking for. The failure point is that the user is not always who they appear to be, and the model has no way to tell. A confirmation prompt between “the model decided” and “the file changed” turns a remote attack into a local annoyance. The developer reads the diff, notices the change, says no, and the build files are exactly as they were before.
What the safeguard actually covers
The default protected list includes the files that execute code when someone clones the repo or runs the install script. Dependency manifests like the JavaScript package file, the Python requirements file, and similar files across language-specific package managers are on the list. Container recipes and compose files are on the list. CI configuration files are on the list. Makefiles and shell scripts that get sourced are on the list. Lockfiles (auto-generated companion files that pin exact versions of every dependency) sit next to their manifests and they are on the list too.
To see the full list as the tool ships, run gemini config get protectedFiles after the update. The list is editable, which matters if a project uses an unusual manifest format the defaults do not catch. If the project does, the maintainer has to add it manually, and the gap will only be discovered after the model has already touched something that should have been protected.
Tuning the rule for shared infrastructure
The default mode is ask, which means every protected file edit produces a prompt. On a solo laptop where only one person runs the agent, ask is fine. On a shared CI runner or a build server that other people can submit jobs to, ask is the wrong mode, because prompts on a shared machine do not have a human to read them.
The right mode for shared infrastructure is block, not ask. Block means the assistant refuses the edit instead of prompting for approval, and a refusal on a CI runner produces a build failure that someone has to investigate. That is the outcome wanted for a prompt injection that the model would have silently applied.
A short checklist for what to think through before relaxing the rule:
- Is this a sandbox that gets rebuilt from scratch, or a long-lived shared system? Sandbox means ask is fine. Long-lived means block.
- Is the session trusted, or is it running in an unattended loop? Trusted sessions can allowlist (mark specific files or paths as safe to edit without prompting) by exact path. Unattended loops should not have protected file access at all.
- Is dry-run mode (where the model proposes the diff without writing the file) available? Dry-run is the safest mode for seeing what the assistant would have done.
The asymmetry is real. Loosening the rule is fast. Tightening it after an incident is slow and political. Treat the allowlist like root access on a production box. Add what is needed, audit it once a quarter, and do not hand it to a long-running agent that is not being actively watched.
Trade-offs
Friction is the cost. Every protected file edit produces a confirmation prompt, and on a tight loop over a fresh project, the prompts add up. Some teams will turn the rule off because the friction feels worse than the risk, and that is a reasonable choice for a sandbox that gets rebuilt every time. It is not a reasonable choice for a shared CI runner or a repo that handles other people’s data, which is exactly where the safeguard earns its keep.
Coverage gaps are a second cost. The default protected list is correct for the common case but it does not cover every project’s quirks. If a project uses an unusual manifest format or a less common build tool, the model will not know to ask before editing it. The maintainer has to add it, and the gap will only be discovered after the assistant has already touched something that should have been protected. Running gemini config get protectedFiles once on day one, before the first session, is the cheapest way to avoid that surprise.
A short checklist for what to think about before relaxing the rule:
- Sandbox or long-lived? Sandbox means ask is fine. Long-lived shared systems should run in block mode so unattended edits fail loudly instead of silently.
- Trusted session or unattended loop? Trusted sessions can allowlist specific paths. Anything running without a human in front of it should not have protected file access at all.
- Dry-run first? To see what the assistant would have done without writing the file, this is the safest mode. Combine it with manual apply.
- Runbook ready? Without a written plan for what to do when the prompt fires unexpectedly, the prompt feels like an interruption rather than a checkpoint.
Bigger trade-off: what this safeguard does not do. It protects against the prompt injection shape where an attacker asks the model to write to a build file. It does not protect against the shape where an attacker asks the model to read a build file and exfiltrate (silently copy out) its contents through a different channel. That second shape is a real attack class and it is not what this feature is solving. Read the release notes to know exactly what is covered, and do not assume more.
Bottom line
If any AI coding assistant runs on a shared machine or a CI runner, updating Gemini CLI this week is worth the time. Run gemini config get protectedFiles to see the default list, then deliberately have the assistant edit a manifest so the prompt shows up firsthand. Once it has been seen once, it will not be forgotten, and the next time a sketchy instruction lands in the terminal, the moment before pressing y will be recognizable.
The bigger picture is that the rest of the CLI agent market is going to have to match this feature in 2026, because the alternative is to keep being the assistant that quietly rewrites someone’s build files in response to an attacker’s bug report. If CLI agents are being evaluated this year, ask each vendor what their build file policy is before trusting them with a real repo. The vendors who cannot answer that question clearly are not ready for shared machines.