DeveloperHA / AI agents / Gemini CLI
Open-source terminal agent · CLI agents

Gemini CLI

See how a terminal agent combines model access, built-in tools, persistent context and authentication choices, and how to keep those choices explicit in a team workflow.

Made by GoogleSeparate agent guideReviewed 2026-09-26Model ≠ harness ≠ orchestrator
Scope note This is an independent guide to a third-party project or a developer concept. Installation commands, feature boundaries, plans, model availability and security defaults change. Follow the official source links before using it with private code, credentials or automation.

What it is and who makes it

Google's open-source terminal AI agent for working with Gemini models, repository context, tools and MCP integrations.

Maker or project: Google. Classification: Open-source terminal agent; this page treats the surrounding context, tools, permissions and verification as the relevant harness boundary.

1
Run the CLI in a trusted project directory.

Run the CLI in a trusted project directory.

2
Choose an authentication and model path supported by the current project documentation.

Choose an authentication and model path supported by the current project documentation.

3
The agent uses context files and tools to inspect or change the project.

The agent uses context files and tools to inspect or change the project.

4
Use headless output and tests when integrating the CLI into automation.

Use headless output and tests when integrating the CLI into automation.

Who it may fit

Pick an agent by its control surface and trust boundary, not only by its model label.

Useful scenarios

  • Developers already using Gemini or Google Cloud
  • Terminal workflows with search, files and shell tools
  • Teams evaluating an open-source CLI agent with MCP support

Trade-offs and checks

  • Free tiers, quota, model names and authentication options change; verify current official documentation.
  • Search and web tools create an additional data path and should be governed separately from local file access.
  • Do not assume an open-source CLI means every provider request stays local.

Interactive vs headless and CI

These modes change the approval, identity and observability boundary.

Use the interactive terminal while learning the project and permissions. Use the documented prompt/headless and structured-output modes for scripts or CI, with a service account or API path that is separate from a developer login.

Request-to-verification workflow

Use this mental model when debugging a surprising edit, tool call or cost.

Input

Intent + context

Your prompt, repository instructions, selected files, history and environment become model context.

Action

Tool + permission

The harness proposes a read, edit, shell, web, MCP or other action; policy decides whether it can run.

Feedback

Result + verification

Command output, compiler errors, tests and your review return to the loop before acceptance.

Setup outline

Start with the smallest safe experiment, then follow the current official documentation for the real installation.

1
Follow the official installation and authentication guide.
2
Try the interactive CLI on a non-sensitive repository.
3
Create a small GEMINI.md or project context file only after deciding what should be shared with every session.
4
Use structured output and explicit exit handling for scripts.
Illustrative workflow
# Official quick-start style
npx @google/gemini-cli

# Ask for analysis without asking for edits
gemini -p "Map the architecture of this repository; do not change files."

# In CI, use the documented structured output and auth path.

Instructions, skills, MCP and hooks

These surfaces can shape context or add actions; they are part of the trust boundary.

Gemini CLI can load project context such as GEMINI.md and can be extended through documented tools, MCP and related configuration. Keep shared instruction files short, reviewable and free of secrets; verify current extension and hook behavior in the official docs.

Security and isolation checklist Use a disposable branch or worktree; keep secrets outside the readable path; require approval for writes, shell, network and deployment actions; inspect commands before allowing them; constrain server bindings; review MCP servers, plugins, skills, hooks and instruction files; and run tests independently of the agent's own summary.

Official sources

Use these sources for current installation, capabilities, plans, releases and security notices.

Reviewed 2026-09-26. This date is a change-tracking note, not a promise that the product remains unchanged.

Related learning

Related agent guides

Want the foundations behind the workflow?

Study AI fundamentals, prompt design, AI-assisted development, agents and MCP without a forced linear course.

Open AI learningAI tools