Npm install google Gemini CLI: a working configuration, explained line by line

On this page#

• Before you install anything
• The steps
• A working configuration
• Objective
• Before proposing changes
• Repository invariants
• Commands
• Completion
• What to skip
• First real task
• FAQ

Before you install anything#

Install Gemini CLI only after you define repository rules, project context, and an initial read-only permission boundary. The command is simple; the dangerous part is letting a new agent infer your architecture while holding shell and write access. In a real repository, configuration order matters more than installation speed.

The correct sequence is:

1. Record the repository’s invariants.
2. Add project-scoped Gemini CLI settings.
3. Install the package.
4. Authenticate without storing credentials in the repository.
5. Start with a read-only task.
6. Expand permissions only when a task requires them.

This prevents the agent from learning your repository through failed edits. It also gives the second engineer a reviewable explanation of what Gemini CLI may do and why.

npm install installs packages locally unless you request a global installation. For a command-line program you intend to invoke across repositories, use:

npm install -g @google/gemini-cli

That command installs the executable. It does not configure your repository, encode its invariants, or make broad permissions sensible.

Do not put API keys, authentication tokens, or machine-specific paths in committed configuration. Authentication belongs to the developer environment. Repository behavior belongs in the repository.

Photo by Boris K. on Pexels.

The steps#

Use this order because every step removes a specific failure mode before Gemini CLI can encounter it. The objective is not merely to make the executable start; it is to create a predictable agent boundary that survives handoff, code review, and a second developer running the same tool from another machine.

1. Write GEMINI.md first — this prevents architectural guesswork.
   Define the repository’s commands, boundaries, generated files, and non-negotiable behavior before the agent reads the code.

2. Add .gemini/settings.json — this prevents accidental capability expansion.
   Begin with only repository-reading and search tools. Do not grant shell or write access because a tutorial says it is convenient.

3. Install the CLI globally — this prevents dependency noise inside the application.

   npm install -g @google/gemini-cli

   The global flag is standard npm install behavior, not a Gemini-specific installation mechanism.

4. Run Gemini CLI from the repository root — this prevents the wrong directory from becoming the working context.

   gemini

   Gemini CLI is the terminal agent documented in the official Gemini CLI documentation. Starting it from an arbitrary parent directory gives it the wrong boundary.

5. Authenticate interactively — this prevents credentials from entering version control.
   Follow the CLI’s authentication flow on each developer machine. Do not copy a token into GEMINI.md, .gemini/settings.json, or a tracked environment file.

6. Ask for a read-only repository map — this prevents premature edits.
   Make the first task expose misunderstandings while the agent is still unable to change files.

7. Grant additional tools deliberately — this prevents permanent over-permissioning.
   Add editing or shell capability only after the team agrees on what the agent may change and which commands require human approval.

If your team needs a reusable operating model around these boundaries, the PairFoundry Agent Operating Kit is the natural next layer. Installation gives you a binary; an operating kit gives humans a shared procedure.

A working configuration#

Commit two files: .gemini/settings.json for the enforceable tool boundary and GEMINI.md for repository-specific instructions. The settings file starts read-only. The context file tells Gemini CLI what “correct” means in this codebase without pretending that prose can replace actual permission controls.

Create .gemini/settings.json:

{
  "tools": {
    "core": [
      "read_file",
      "list_directory",
      "glob",
      "search_file_content"
    ]
  }
}

Line by line:

| Line | Purpose | |---|---| | { | Starts the project-scoped settings object. | | "tools" | Groups the capabilities available to the agent. | | "core" | Restricts the built-in tool set instead of accepting every available capability. | | "read_file" | Allows inspection of file contents. | | "list_directory" | Allows the agent to understand repository structure. | | "glob" | Allows bounded discovery by filename pattern. | | "search_file_content" | Allows code search without invoking an unrestricted shell. | | Closing brackets | End the allowlist, tool object, and settings object. |

This is intentionally narrow. It omits file writing, shell execution, and network retrieval. Those omissions are the configuration’s main feature, not unfinished work.

The Gemini CLI documentation should remain the authority for supported settings. Keep the committed file small enough that a reviewer can compare every capability against that reference.

Then create GEMINI.md:

# Repository operating rules


![A close-up shot of a person coding on a laptop, focusing on the hands and screen. — illustrating npm install google gemi](/blog/npm-install-google-gemini-cli-2.jpg)
*Photo by Lukas Blazek on [Pexels](https://www.pexels.com/photo/person-encoding-in-laptop-574071/).*

## Objective

Work only inside this repository. Preserve existing behavior unless the task
explicitly authorizes a behavior change.

## Before proposing changes

- Read the relevant implementation, tests, and configuration.
- Identify generated files; do not edit them directly.
- State which invariant each proposed change preserves.
- Report conflicting instructions instead of guessing.


![Detailed view of Ruby on Rails code highlighting software development intricacies. — illustrating npm install google gem](/blog/npm-install-google-gemini-cli-3.jpg)
*Photo by Digital Buggu on [Pexels](https://www.pexels.com/photo/monitor-displaying-computer-application-374559/).*

## Repository invariants

- Public interfaces must remain backward compatible unless the task says otherwise.
- Existing tests are part of the specification.
- Do not add dependencies without explicit approval.
- Do not change authentication, authorization, or data-retention behavior implicitly.
- Never print, copy, or commit credentials.

## Commands

- Use the repository's documented install, test, lint, and build commands.
- Do not substitute package managers.
- Do not run destructive commands.
- Ask before running commands that modify data outside the working tree.

## Completion

- Describe changed behavior and unchanged behavior.
- List validation performed.
- Call out validation that could not be performed.
- Keep unrelated cleanup out of the patch.

Each section has one job:

• Objective establishes scope.
• Before proposing changes forces inspection ahead of implementation.
• Repository invariants records constraints that code search alone cannot reliably reveal.
• Commands prevents improvisation around package managers and destructive operations.
• Completion makes handoff evidence explicit.

Replace generic invariants with your real ones. Do not paste architecture slogans. Name the interfaces, generated directories, validation commands, and behaviors that must not move.

For a broader setup pattern, use the agent setup hub. If the team is still learning how to express repository constraints, start with the free PairFoundry foundations track.

What to skip#

Skip any setup step that increases capability without improving repository understanding or reviewability. Most installation tutorials optimize for a successful demo prompt. That is the wrong acceptance criterion for maintained software, where an unnecessary dependency, silent shell command, or generated-file edit can create durable damage.

Do not:

• Install Gemini CLI as an application dependency merely to obtain a terminal command.
• Commit credentials or tell teammates to share one authentication artifact.
• Enable blanket approval or unrestricted execution on the first run.
• Grant write access before the agent can accurately map the repository.
• Copy a giant generic GEMINI.md that says nothing about your actual invariants.
• Add model-generated style rules that conflict with existing linters or formatters.
• Let Gemini CLI choose install, test, or migration commands by intuition.
• Ask it to “improve the codebase” as its first task.
• Treat a successful launch as proof that the repository integration is correct.

Also skip duplicating the official Gemini CLI documentation inside your repository. Record only decisions specific to your project. Duplicated vendor instructions age; repository invariants remain yours to maintain.

If you want packaged workflows beyond this initial boundary, compare the three options on the PairFoundry packs overview.

First real task#

The first task should be a read-only repository map with explicit evidence, not a code change. It tests whether the agent can find the real entry points, commands, boundaries, and invariants while the configuration still prevents edits and shell execution. Misunderstandings discovered here are cheap.

Use this prompt:

Read GEMINI.md and inspect the repository without changing files.

Produce:
1. the runtime and build entry points;
2. the main module boundaries;
3. the documented install, test, lint, and build commands;
4. generated files or directories that should not be edited directly;
5. three repository invariants supported by specific file references;
6. contradictions or missing information in GEMINI.md.

Do not propose refactors. Do not infer commands that are not documented.

Review the answer for incorrect paths, invented commands, and missed generated artifacts. If the map is wrong, fix GEMINI.md or narrow the prompt. Do not reward a wrong map with write access.

Only after the map is accurate should the first change be small, reversible, and covered by existing validation. That progression is what turns npm install google gemini cli from an installation query into a maintainable team practice.

Related reading#

• How to use Claude Code effectively — what to do before you type a single prompt
• Installing Claude Code: a working configuration, explained line by line

FAQ#

How to install Gemini CLI on CMD?#

Open CMD and run npm install -g @google/gemini-cli, then run gemini from the root of the repository you want it to inspect. The command works through npm; the important repository setup remains the committed GEMINI.md and .gemini/settings.json, not CMD-specific ceremony.

How to upgrade Google Gemini CLI using npm install?#

Run npm install -g @google/gemini-cli again to install the package through npm’s global installation mechanism. Before team-wide rollout, compare any configuration changes against the official Gemini CLI documentation and review whether your allowlisted tools still mean what reviewers expect.

How to install Google Gemini?#

If you mean the terminal coding agent, install Gemini CLI with npm install -g @google/gemini-cli. “Google Gemini” also names a broader product family, so use the CLI package and the gemini command when your intended interface is the repository-aware terminal agent.

How do I install Google CLI?#

For Gemini CLI specifically, run npm install -g @google/gemini-cli. There is no useful reason to replace that precise package name with a vague “Google CLI” instruction. Install the named tool, launch gemini from the repository root, and keep permissions narrow.

How do I install Gemini CLI with npm?#

Use npm install -g @google/gemini-cli. The -g flag makes the command available across repositories, as described by the npm install documentation. Configure each real repository separately so its instructions and permission boundary remain reviewable.