# Gemini CLI for teams needs operating rules

> A practical evaluation of Gemini CLI for teams covering access, quotas, security controls, MCP, rollout policy, and its place beside Claude Code.

Gemini CLI is still a credible team tool, but only if you treat it as an execution environment with a model attached. A developer can ask it to inspect a repository, edit files, run tests, call MCP tools, and continue work in a saved session. Those actions touch source code, credentials, network services, and sometimes production-adjacent systems. The procurement question is therefore smaller than the operating question: which identity pays for each request, which tools may run, where commands run, and who can change those rules?

There is also a current product transition that invalidates many older comparisons. On June 18, 2026, the official Gemini CLI repository announced that the CLI had stopped serving free-tier, Google AI Pro, and Google AI Ultra individual accounts as Google moved its individual terminal experience to Antigravity CLI. The same announcement said enterprise users with Gemini Code Assist licenses and API-key authentication were unaffected. If a team evaluates Gemini CLI from a blog post written before that date, it may build a rollout around an authentication path that no longer works.

My practical recommendation is to evaluate Gemini CLI as a managed team client, not as a free tool that happens to scale. Give it one bounded class of engineering work, enforce a shared policy, record quality and cost, and compare the result with Claude Code on the same repository. A week of controlled use will tell you more than a feature table because the expensive failures appear in retries, review load, unsafe tool access, and work that looked complete but was not.

## Gemini CLI now has a narrower team audience

Gemini CLI makes sense today for organizations that can use a Gemini Code Assist license, a paid Gemini API key, or Vertex AI. The individual Google-account route belongs to Antigravity CLI after the June 2026 transition, even though parts of the Gemini CLI documentation still display historical individual quotas. The newer repository announcement is the operational source to follow when those pages disagree.

That distinction changes the first meeting. Do not ask developers to install the package and sign in with whatever Google account is convenient. Decide the supported authentication route before installation. A Google Workspace user with a Code Assist license normally needs a Google Cloud project. A headless job should use an API key or Vertex AI identity. Vertex AI can use Application Default Credentials, a service-account credential, or a Google Cloud API key, and it also requires a project and location.

The identity choice determines billing, quota, data controls, and incident response. A shared API key looks simple until one leaked environment variable consumes the budget and leaves no clean per-user attribution. Personal credentials make removal and centralized policy harder. For an interactive team, assigned Code Assist seats are the clean fixed-cost route. For CI or irregular heavy workloads, Vertex AI or a paid API key gives usage-based capacity, but the team must add budget alerts and ownership outside the CLI.

Treat the open-source client and the hosted model service as separate layers. You can inspect and pin the client code, but prompts and selected repository context still travel to the authenticated service. An open repository does not make hosted inference local. Security reviewers often blur those two facts, then approve the client while never documenting where inference data goes.

Before a pilot, write down four facts for every participant: login type, billing project, quota owner, and offboarding action. If one row says "developer choice," the rollout is not ready.

## Its useful unit of work is a verified repository change

Gemini CLI earns its place when it can explore code, change files, run commands, and show evidence that the change works. It has built-in file and search tools, shell execution, web capabilities, session history, planning, project memory through `GEMINI.md`, and extensions. MCP connections add external tools and data. Headless mode can emit text, JSON, or streaming JSON, which makes it usable in scripts and CI.

The unit of work should not be "produce code." Models are very good at producing plausible diffs. Ask for a verified change with explicit boundaries instead:

1. Read the issue and the nearest project instructions.
2. Inspect the relevant implementation and tests before editing.
3. Make the smallest change that satisfies the acceptance criteria.
4. Run the narrow tests, then the repository's required checks.
5. Return the changed files, commands run, results, and remaining uncertainty.

That prompt shape forces the agent to gather evidence. It also makes reviews comparable across tools. If Gemini CLI claims success after a failing command, you have found a workflow defect. If it changes six unrelated files for a two-line bug, you have found a review-cost problem. Neither problem appears in a demo where the only score is whether code appeared on screen.

Project memory is useful for stable constraints such as the package manager, test commands, generated-file rules, and architecture boundaries. Keep it short enough that a developer can audit it. Do not paste a handbook into `GEMINI.md`; stale instructions consume context and conflict with the repository. Put executable rules in linters, tests, and hooks, where a model cannot reinterpret them.

Sessions can be resumed, and checkpointing can help recover from edits, but version control remains the durable boundary. Start from a clean branch, inspect the diff before accepting it, and never treat conversation history as an audit log. The repository records what changed. The terminal transcript explains how the agent got there, which can help debugging, but it does not replace a reviewed commit.

## Authentication and quotas are one design decision

A quota number without its authentication method is meaningless. The official Gemini CLI quota page lists Code Assist Standard at 1,500 model requests per user per day and Code Assist Enterprise at 2,000. It also lists 250 daily requests for an unpaid Gemini API key. Paid API-key and regular Vertex AI usage vary with the applicable service limits and token-based pricing. Per-minute limits and service availability can still interrupt work before a daily ceiling does.

Those are model requests, not completed tasks. One task can cause several calls as the agent reads files, reasons about tool output, retries a command, and revises a patch. A team of ten does not possess one pool of 15,000 useful actions merely because each Standard seat lists 1,500 requests. Quotas apply per user, the complexity of work differs, and a long agent loop can burn requests while producing nothing mergeable.

Use `/stats model` during a session to see token and quota information, and capture the summary shown when the session exits. The useful pilot metrics are requests per accepted change, elapsed engineer time, review corrections, and abandoned runs. Cost per request hides the expensive part, which is usually human review and rework.

A quota failure needs a designed response. Do not tell developers to switch silently to a personal account, another project, or an untracked key. That destroys cost attribution and may change the applicable data terms. Choose one of these responses in advance: wait for reset, move an approved workload to pay-as-you-go Vertex AI, or continue manually. The correct choice depends on urgency and governance, not on which credential happens to work.

I also would not buy the largest tier before measuring real use. Higher ceilings reduce interruptions, but they can conceal looping prompts and poorly scoped tasks. A two-week pilot with visible usage often shows that prompt and repository hygiene matter more than another block of requests. Buy capacity after the workflow stops wasting it.

## Security comes from layers, not approval prompts

Gemini CLI's default confirmation prompt is useful, but it cannot carry the whole security posture. Developers approve repetitive commands quickly, and a malicious repository can place instructions in configuration, hooks, skills, extensions, or files that the model reads. The correct design combines workspace trust, a tool policy, sandboxing, identity control, secret handling, and review.

Folder trust limits what an unfamiliar repository can activate. In an untrusted workspace, the CLI ignores project settings and `.env` files, does not connect MCP servers, does not load custom commands, blocks automatic memory loading, restricts extension management, and prompts for every tool. That is a meaningful quarantine mode. The trusted-folders documentation also warns about project hooks, MCP servers, skills, custom commands, and settings overrides during discovery. Enable the feature and train developers to inspect that inventory before trusting a cloned repository.

Sandboxing limits damage after a tool receives permission. Gemini CLI supports macOS Seatbelt profiles, Docker or Podman containers, Windows native sandboxing, gVisor on Linux, and experimental LXC or LXD support. The details matter. The default permissive macOS profile restricts writes but allows broad reads and network access, so it does not protect secrets elsewhere on disk as strongly as many people assume. A container mounts the workspace read-write. A sandbox reduces reach; it does not make the workspace disposable or prevent the model from sending readable content to an allowed network destination.

The policy engine decides whether a proposed tool call is allowed, denied, or sent for confirmation. Admin rules outrank user and default rules. Enterprise admin controls can keep strict mode on, disable extensions and MCP, and define an MCP allowlist that local users cannot override. System settings help standardize machines, but Google's enterprise guide explicitly cautions that a user with sufficient local privileges may bypass them. That is an important distinction: managed service controls enforce organization policy, while a root-owned local file mostly prevents accidents.

Secret redaction is best effort. The configuration reference describes filtering environment-variable names and values that resemble tokens, passwords, private keys, and known credential patterns. Hook guidance has also documented environment redaction as a setting that teams should verify rather than assume. Keep credentials out of the repository, scope them narrowly, and test what a shell tool and each extension can actually see. A filter is a backstop, not a vault.

## A small enforced baseline beats a large shared config

A team baseline should deny catastrophic actions and expose only the tools needed for the pilot. Start with read-only repository analysis, then add file edits and selected test commands after the team can inspect logs and revoke access. A broad shared configuration copied into every project creates a large, quiet attack surface.

This policy fragment uses the documented policy-engine shape to block one destructive shell prefix:

```toml
[[rule]]
toolName = "run_shell_command"
commandPrefix = "rm -rf"
decision = "deny"
priority = 100
```

The expected behavior is a blocked tool call with the policy reason returned to the agent. Test the rule with a harmless prompt in an isolated fixture rather than trusting that the file was discovered. On Linux, admin policy files belong under `/etc/gemini-cli/policies`; the standard directory must be owned by root and must not be writable by group or others, or the CLI ignores it. macOS uses `/Library/Application Support/GeminiCli/policies`.

Blocking `rm -rf` is an artifact you can verify, not a complete policy. Destructive work can arrive through another executable, a script, an MCP tool, or a cloud API. Prefer a short allowlist for a bounded pilot over an endless catalog of forbidden strings. Google's enterprise guide makes the same practical point: an allowlist of core tools is safer than trying to anticipate every dangerous command.

Add a rollout check that developers can run and paste into the pilot record:

```text
gemini mcp list
gemini extensions list
```

The output should show only approved MCP servers and extensions. Record the pinned client version from your deployment inventory. Follow it inside the interactive session with `/stats model` to confirm the expected quota identity. If the MCP or extension inventory differs across two laptops, the team is not testing one tool configuration; it is testing two unrelated execution environments.

Keep project instructions in version control, but keep enforceable admin policy outside repository control. A pull request author should not be able to weaken the rule that evaluates the same pull request. That separation is easy to explain during an audit and hard to fake accidentally.

## MCP and extensions spend your trust budget

Every MCP server and extension adds code, tool descriptions, credentials, and often a network destination to the agent's environment. The capability may be useful, but the server is not safe merely because it speaks a standard protocol. Review who publishes it, how updates arrive, which tools it exposes, which environment variables it receives, and what those tools can change.

Gemini CLI can filter an MCP server with included and excluded tool lists. Enterprise controls can disable MCP entirely or restrict users to an administrator-defined set of remote servers. Use that mechanism. A generic "Git hosting" connector might offer read operations, comment creation, merges, branch deletion, and workflow dispatch. An agent that only needs issue text should not receive all of them. Tool-level least privilege makes a prompt-injection failure smaller.

Extensions have an even wider packaging role: they can include prompts, custom commands, MCP servers, hooks, skills, and sub-agents. Pin a reviewed source and version where possible. Turn off automatic updates during a controlled evaluation, then establish an update review rather than letting every laptop drift. A dependency scanner will not tell you that a harmless-looking prompt file instructs the model to upload a diagnostic bundle. Human review still matters.

Hooks can block or rewrite actions before a tool runs, and they are useful for deterministic checks such as preventing a commit that contains a secret. Hooks also execute code and may process prompts or tool output. Project hooks deserve the same review as build scripts. Keep stdout contracts strict, minimize logging, and assume hook telemetry can contain sensitive content unless configured otherwise.

Do not connect production systems during the first pilot. Use a test organization, read-only credentials, and synthetic data. Once a workflow proves useful, add one capability at a time and record the owner, scope, revocation method, and expected side effect. If nobody owns an MCP server, remove it.

## Gemini CLI and Claude Code can share a bench

Gemini CLI does not need to replace Claude Code to justify a seat. Both clients read repositories, edit files, run commands, use project instructions, connect through MCP, support hooks, and offer managed controls. Claude Code also has mature concepts for subagents, agent teams, permissions, sandbox boundaries, plugins, and managed settings. Gemini CLI offers a natural route for organizations already governing developer access through Google Cloud and Gemini Code Assist. The fit depends more on your identity stack, repositories, and workloads than on a universal model ranking.

Run both tools on the same task set. Choose five real jobs that represent the team's week: a localized bug, a test addition, a dependency update, an unfamiliar-code explanation, and a small refactor. Reset the branch between runs. Give both tools equivalent instructions and access, then score accepted correctness, unintended changes, commands run, review time, request usage, and security exceptions. Do not let one tool use a production MCP server while the other works from files alone.

Keep one client as the default for each workflow after the trial. Letting every developer alternate agents during one issue makes provenance difficult and doubles configuration work. A sensible split might use Gemini CLI for teams whose Google Cloud identity and Code Assist licensing already supply control and quota, while Claude Code remains the default where its managed deployment or agent workflows fit better. Another team may reach the opposite result.

Model diversity has one practical benefit: a second agent can review a patch without inheriting the first agent's conversation. It also has a cost. Two agents can agree on the same wrong assumption, and a second pass consumes quota and reviewer attention. Use cross-review for risky or ambiguous changes, not as a ritual on every typo.

Avoid maintaining two giant instruction files by hand. Store shared engineering rules in tests, linters, and concise repository documentation, then keep thin `GEMINI.md` and `CLAUDE.md` adapters where syntax or tool behavior differs. If the adapters contain competing architecture guidance, the comparison is already contaminated.

## Reliability depends on feedback, not model confidence

Gemini CLI can sound certain after a partial test, a skipped command, or a change it never inspected in the final diff. Confidence in the response is not evidence. Reliable use comes from forcing each task through feedback that the model cannot manufacture: compiler output, tests, static analysis, a clean diff, and a human review matched to the change's risk.

Consider a common failure. An agent updates a shared function and runs the nearest unit test. The test passes, so the agent reports completion. The change also alters a serialized value consumed by another package, but the agent never searches for downstream callers and never runs the integration suite. A reviewer sees tidy code and a green command in the transcript, then merges it. CI fails later, or worse, the untested consumer accepts the new shape and breaks at runtime. The model did useful work; the workflow asked the wrong question.

Require the agent to name what it did not verify. A good completion record says which acceptance criteria map to which test, whether the full required suite ran, and why any check was omitted. If a command fails because the sandbox lacks network access, the report should show that failure. The developer can approve a narrow sandbox expansion, run the check outside the agent, or reject the patch. Silently translating "could not run" into "looks correct" is unacceptable.

CI should repeat the important checks on a clean runner. Local agent output can be affected by untracked files, cached artifacts, a developer's environment, or permissions that the build worker lacks. Keep required checks in repository configuration so Gemini CLI, Claude Code, and a human all face the same gate. Agent-specific instructions may tell the tool which commands to run, but the merge rule belongs to CI.

Do not give the agent permission to merge or deploy during the initial rollout. Separating creation from release preserves an independent decision point and limits the damage of prompt injection. Later, a mature team may allow a tightly scoped automation identity to open a pull request or update a test environment. Production deployment, database migration, credential rotation, and access-policy changes should keep explicit ownership and stronger review because their consequences extend beyond the working tree.

Review depth should follow blast radius. A documentation edit may need a diff check and formatting test. Authentication, billing, persistence, infrastructure, and public API changes need an engineer who understands the affected system, regardless of how convincing the agent's explanation sounds. AI review can add another perspective, but it cannot accept accountability for the release.

Measure false completion reports during the pilot. Count a run as false completion when the agent says the task is done but required tests fail, acceptance criteria remain unmet, or the diff contains unrelated changes. That rate is more revealing than lines generated. A tool that writes quickly and sends every second task back for repair has moved work into review, not removed it.

Reliability improves when tasks are small enough to verify yet large enough to matter. Give the agent one coherent change with observable acceptance criteria. Split a migration into independently testable stages. If the task requires guessing an undocumented product decision, stop the run and ask the owner; more model turns will only turn the guess into polished code.

Ownership of generated changes must stay visible. Require the developer who starts a run to review and present the patch as their work. Do not add an "AI approved" label that lets authors and reviewers assume somebody else checked it. The pull request should describe evidence, unusual tool access, and any generated migration or dependency change that deserves extra attention.

Pinning the CLI client does not pin every component of the result. The selected model alias can resolve differently, an MCP server can update, package registries can change, and a network search can return new material. For repeatable regulated work, record the resolved model where the service exposes it, pin extension and server versions, use lock files, and archive the test output that supports the decision. Exact reproduction may remain impossible, but unexplained drift is avoidable.

Agent output also needs the same supply-chain controls as human output. Run secret scanning, dependency review, license checks, and static analysis on the resulting diff. Inspect new scripts before executing them with broader permissions. If the agent adds a package to avoid writing a few lines, ask whether the maintenance and attack surface justify it. Generated code does not receive a waiver from engineering policy.

Finally, keep a manual path for every approved workflow. Service outages, quota exhaustion, authentication failures, and policy bugs will happen. A team that cannot ship a small fix without its coding agent has exchanged one bottleneck for another. The agent should reduce labor while the repository, build, and operating knowledge remain usable by engineers.

## A team pilot must end in an operating decision

A good pilot answers whether Gemini CLI lowers total engineering effort for a defined class of work without expanding risk beyond what the company can manage. It is not a vote on whether developers enjoyed the chat interface. Define the decision before anyone starts.

Use a small repository with representative tests and no production credentials. Assign named participants, one authentication route, a pinned version, a fixed tool policy, and a short task set. Record baseline time for comparable manual work. During the pilot, capture accepted changes, review corrections, failed runs, requests, security prompts, policy blocks, and setup problems. A developer's impression belongs in the notes, but it cannot replace the diff and test output.

Stop the pilot on any of these conditions: credentials appear in model-visible output, the policy cannot be enforced consistently, billing identity is unclear, or the team cannot reconstruct what tools ran. Fix the control before continuing. Shipping faster does not compensate for an execution environment nobody can account for.

At the end, choose one of three outcomes: approve for the tested workflow, extend the trial with one named uncertainty, or reject it for now. Avoid "approved for experimentation," which usually means unlimited use without an owner. An approval should name permitted repositories, authentication, tools, sandbox mode, model or quota route, review requirements, telemetry handling, and a date for policy review.

This is the same evidence-first test I use in a Team & AI Audit: a tool has to remove payroll-heavy work while preserving output and uptime, not merely create more code. Gemini CLI can pass that test for a licensed, well-governed team. If the team cannot keep identities, tools, and review rules consistent across five pilot tasks, the correct decision is to postpone adoption and fix the operating system around engineering first.