Gemini CLI vs Claude Code: A Security Comparison for Enterprise Teams Choosing an AI Coding Agent

If you are choosing between them on security grounds alone: Claude Code has the safer default posture, because Anthropic documents that it "uses strict read-only permissions by default," so an unconfigured install cannot write or execute without asking. Gemini CLI has the stronger administrative story, because its settings precedence ends at a system overrides file that a developer cannot loosen from inside a repository, and Google publishes explicit guidance to allowlist rather than blocklist tools. Both shipped a serious vulnerability in 2026. Both leave the same gap in CI, and that gap, not the defaults, is where the published attacks actually happened.

One eligibility fact first, because it decides the comparison for a lot of teams. Since June 18, 2026, Gemini CLI no longer serves Google AI Pro, Google AI Ultra or the free Gemini Code Assist for individuals tier. If your developers are not on a Gemini Code Assist Standard or Enterprise license, or a paid Gemini or Gemini Enterprise Agent Platform API key, the real comparison is Claude Code against Antigravity CLI, which is a different harness with its own findings.

The comparison in one table

Both vendors write down the limits of their own controls. That is genuinely unusual in this market and it should count in both their favors.

Default posture: Claude Code wins, and it matters less than you think

Read-only by default is the right default. An engineer who installs Claude Code and points it at a repository gets a tool that reads and proposes, and has to be granted the ability to write files or run commands. Gemini CLI's default approval mode prompts before each tool call, which reaches a similar place through a different route, but it is a per-call interruption rather than a standing posture, and per-call prompts are exactly the thing humans click through when they appear forty times an hour.

Anthropic then does something worth quoting, because most vendors would not: it labels its own trust prompt "a permission gate, not a sandbox." A permission gate asks whether you meant to do this. A sandbox limits what happens when the answer was wrong or the question was never really yours. Treating the first as the second is the single most common mistake we see in coding agent rollouts.

The reason the default matters less than it seems is that neither default survives contact with a team that wants the agent to be useful. Within a month somebody has granted broad write access, somebody else has added an approval bypass to a script, and the posture you evaluated is not the posture you are running. What persists is what an administrator can enforce centrally, which is the next section.

Administrative enforcement: Gemini CLI has the better answer

Gemini CLI applies settings in four layers: system defaults, then user settings, then workspace settings, then system overrides. Google's documentation is blunt about the consequence, stating that "this means the System Overrides file has the final say." Put sandbox enforcement and a tool allowlist in that file and a developer cannot relax it by editing a settings file inside a repository, which is the loophole most agent configurations leave open.

Google is also unusually direct about which restriction model to use. On allowlists: "The most secure approach is to explicitly add the tools and commands that users are permitted to execute to an allowlist." On the alternative: "Blocklisting with excludeTools is less secure than allowlisting with coreTools, as it relies on blocking known-bad commands." Every security team knows that in the abstract, and most still ship a blocklist because it is faster. Having the vendor say it in the enterprise documentation makes the argument for you in the design review.

The countervailing caveat is in the same document and deserves equal weight: "However, they should not be considered a foolproof security boundary. A determined user with sufficient privileges on their local machine may still be able to circumvent these configurations." These are policy controls against accidents and drift, not adversary controls on a laptop the user owns.

The 2026 vulnerability record, side by side

Neither tool had a clean year, and the two failures are worth comparing because they broke differently.

Gemini CLI: CVE-2026-12537. NVD scores it 10.0 on CVSS v4.0, with a CVSS v3.1 base of 7.8 that assumes local access and user interaction. For CI runners the v4 score is the honest one. NVD's description: "Improper Neutralization used in an OS Command in the container launcher in Google Gemini CLI (versions prior to 0.39.1) and run-gemini-cli GitHub Action (versions prior to 0.1.22) on headless CI platforms allows an unprivileged attacker to achieve pre-sandbox host-level code execution a maliciously crafted .gemini/.env file." Two defects sat behind it: headless runs automatically trusted workspace folders, and tool allowlists were ignored under the yolo approval mode. Both are fixed in 0.39.1 and run-gemini-cli 0.1.22.

Claude Code: CVE-2026-54316. Presented at Black Hat USA on August 5, 2026 by researchers at Novee Security, it allowed an attacker to exfiltrate an API key character by character using a Hugging Face download counter as a side channel. It affects versions 0.2.54 through 2.1.163 and is fixed in 2.1.163. It requires untrusted content to already be in the agent's context, which is a real precondition rather than a technicality, though it is also the precondition that every indirect prompt injection satisfies by definition.

The scoring disagreement on the Claude Code issue is instructive. Anthropic rated it 6.0 on CVSS v4; NVD rated it 9.1 on CVSS v3.1. Neither is wrong. They are answering different questions about how much you weight the precondition. When you see a large vendor-versus-NVD gap, that gap usually is the argument, and reading both scoring vectors tells you more than picking the number that suits your conclusion.

The pattern underneath both is the same one Novee's founding engineer described: "The harness is the code between the model and the real world." Neither flaw was a model failure. Both were failures in the ordinary software wrapped around the model, where a value marked safe at one stage was handed to code with more authority later.

The CI gap neither tool closes for you

This is the part that should drive your decision, and it is identical on both sides.

Claude Code disables trust verification under the non-interactive flag, which is exactly how it runs in a pipeline. Gemini CLI, before 0.39.1, auto-trusted workspace folders in headless mode. Different mechanisms, same outcome: the human-in-the-loop control that both products lean on in their marketing is the control that is absent in automation, and automation is where the credentials live.

Pillar Security demonstrated what that costs. An attacker opens a public GitHub issue with hidden instructions, a Gemini-powered triage workflow reads it, the agent reads Git credentials from .git/config and exfiltrates them, those credentials carry actions:write, a second workflow yields contents:write, and an outsider can push to main. Every step used a tool the agent was allowed to use. The researchers' own explanation of why the injection worked is the sentence to bring to your next review: "The model refused five researchers who asked for secrets by name. It ran our payload because we never mentioned secrets at all."

The practical rules follow directly, and they apply whichever tool you pick. Never let an agent read attacker-authored input while holding a write-capable token. Split the reading job and the writing job into separate workflows with separate credentials. Pin the action to an immutable reference. And if the agent's blast radius reaches the pipeline that actually ships code, the zero-downtime deployment process needs its own approval gate that does not depend on the agent having behaved.

Sandboxing: different philosophies, similar ceilings

Gemini CLI ships sandboxing in the box, using a prebuilt container image, and turns it on automatically when you use the yolo approval mode. That pairing is sensible: if you are going to auto-approve everything, at least do it somewhere disposable.

Anthropic treats isolation as a separate decision and documents the tradeoffs with numbers, which is more useful for capacity planning than a recommendation would be. Its sandbox-runtime adds very low overhead. gVisor costs roughly nothing in CPU but makes file I/O 10 to 200 times slower, which matters enormously for a coding agent that touches thousands of files. Firecracker microVMs boot in under 125 milliseconds with under 5 MiB of overhead. If you have ever watched a team abandon isolation because the agent got unusably slow, that middle row is why.

The ceiling is the same for both, and CVE-2026-12537 is the proof. That code executed in the container launcher, before the sandbox existed. A sandbox constrains what runs inside it and says nothing about the code that starts it. The same structural mistake appeared in Google's Antigravity IDE, where Pillar Security found that "native tool invocations execute before Secure Mode's restrictions are evaluated, so the security boundary never sees the call."

Which should an enterprise team pick?

For most US engineering organizations the answer is not one tool. It is both, in different teams, which means the control you standardize on has to sit above the choice rather than inside it.

What neither product fixes

Every published attack on either tool ends the same way: a hijacked agent calls a legitimate tool for an illegitimate reason. No version bump changes that, because nothing was broken. The agent did what it was permitted to do.

The controls that survive that outcome are unglamorous. Give each agent its own scoped identity instead of borrowing a developer's or a runner's credentials, so the blast radius is a decision you made rather than an inheritance. Apply a default-deny policy to the actions themselves, at the moment the call is made, not to the prompt that requested them, because the attacker writes the prompt and you write the policy. See tool permissions for how that is enforced. Gate irreversible actions on human approval based on what the action does, which is the point of human in the loop AI agents. And keep an append-only record of every allowed and denied call somewhere the developer machine and the CI runner cannot rewrite, because a compromised host edits its own logs first.

Full version floors, configuration detail and the Antigravity migration are in Gemini CLI security, the Anthropic side is in Claude agent security, and the cross-tool view including Cursor is in coding agent security. If you are running a vendor evaluation more broadly, AI agent security companies covers who actually does what.