Google Gemini CLI — All Official Extensions Collection

What Gemini CLI is

Google Gemini CLI is an open-source AI agent that brings Gemini into your terminal. If you prefer a “stay in the shell” workflow — grep, run tests, manage files, and iterate — Gemini CLI is built for that environment. (Apache-2.0 license; repo updated 2026-05-12T18:47:11Z.)

TokRepo editorial take: Gemini CLI becomes more interesting once you treat it as a platform, not a single binary. The extension system is where it turns from “chat in a terminal” into “a CLI that can learn your tools.”

Best for: developers who already live in the terminal and want a structured way to add tool integrations (including MCP servers) and repeatable command workflows.

Works with: Node.js (for npm install), and a Gemini-capable setup per the official docs.

Setup time: a few minutes for install + first auth/config, then iterative.

How extensions change the game

Gemini CLI supports an extension model that can package multiple building blocks together — prompts, custom commands, and tool integrations — into something you can install and share. The official docs describe extensions as a way to “expand the capabilities of Gemini CLI” and make them “easily installable and shareable.”

Practically, this matters because you can keep a clean separation:

• Core CLI: stable baseline behavior.
• Extensions: opinionated integrations per project/team (e.g., “our deployment commands”, “our on-call runbook”, “our database helpers”).

If you’ve ever had an AI workflow that worked once and then got lost, extensions are how you turn it into something repeatable.

How to use (quickstart)

1. Install Gemini CLI:

• npm install -g @google/gemini-cli, or
• brew install gemini-cli (platform permitting).

1. Run the CLI and follow the official onboarding flow.
2. Start with one “tight loop” task (explain a stack trace, draft a PR summary, build a small script).
3. When you find yourself repeating a pattern, move it into an extension:

• install an extension from a GitHub URL, or
• develop locally and link it for iteration.

What’s inside an extension (so you can inspect it)

Before you install any extension, it helps to know what you’re actually pulling in. The extensions reference documentation describes a gemini-extension.json manifest and explains how extensions declare capabilities and metadata. Treat that manifest like a “package contract.”

A practical inspection flow:

1. Open the extension repo on GitHub.
2. Find gemini-extension.json.
3. Check what tools/integrations it enables (especially anything that can access your filesystem, shell, or network).
4. Skim the prompts/commands it adds and confirm they match your expectations.

This is the difference between “extensions feel scary” and “extensions are just code you review.”

Example: install an extension (from docs)

gemini extensions install https://github.com/gemini-cli-extensions/workspace

After installing or updating an extension, restart the active CLI session if needed so new commands take effect.

Extension lifecycle: install, list, update, uninstall

The extensions reference documentation covers the lifecycle commands. In practice:

• Install from a GitHub URL when you want to reuse a workflow.
• List installed extensions when debugging “why is this behavior happening?”
• Update intentionally (and ideally pinned) rather than during a critical incident.
• Uninstall if you no longer trust or need the extension.

The simplest mental model is: extensions are dependencies, and dependency hygiene applies.

How to decide: extension vs prompt vs script

Use an extension when:

• you repeat a workflow across repos,
• you want a named command surface (not a one-off prompt),
• you need a shareable package teammates can install.

Use a prompt when:

• it’s exploratory,
• you’re still figuring out the workflow,
• the value is in reasoning more than automation.

Use a script when:

• you need determinism and CI-friendly execution,
• you can’t tolerate ambiguous output,
• the task is better expressed as code than instructions.

MCP servers in extensions (powerful, treat as code)

The extensions reference documentation includes support for declaring MCP servers in an extension manifest (via fields such as mcpServers). That’s a big deal: it means an extension can bundle not only prompts/commands, but also tool connectivity.

Editorial guidance: this is exactly where you should slow down.

• Review the MCP server configuration in the repo before installing.
• Prefer least-privilege scopes and explicit allowlists.
• If the extension talks to production systems, pin versions and require a human review for updates.

MCP integrations can make a terminal agent dramatically more useful, but they also expand what it can touch. Make the power visible and auditable.

If you build your own extension (keep it boring)

The extensions reference documents the extension format and variables system. If you’re building an internal extension for your team, the safest approach is to keep the surface area narrow and obvious:

• Prefer one purpose per extension (for example, “repo onboarding,” “release checklist,” or “incident triage”).
• Make commands deterministic: they should run the same way in any repo with the same tooling.
• Store the extension in a normal GitHub repo so review and pinning are natural.
• Treat variables like configuration, not secrets; keep credentials in environment variables or your secret manager.

Done well, an extension becomes a lightweight, reviewable “team playbook” you can install on day one of a new project.

Variables: portability without hardcoding

The extensions reference also documents a variables system. Even if you never build a public extension, variables are the lever that makes internal extensions portable:

• You can keep one extension repo and parameterize “repo-specific” details.
• You can reuse the same command definitions across multiple services with different paths or environments.
• You can encode simple conventions (like “run tests with this command”) without duplicating boilerplate everywhere.

Editorial guidance: don’t over-engineer it. Start with one or two variables that remove obvious copy-paste, and keep defaults sensible. If the extension needs a dozen knobs, it’s usually a sign you should split it into smaller extensions.

Debugging “why did Gemini CLI do that?”

When behavior changes unexpectedly, assume an extension is involved. The fastest debugging workflow is usually:

1. List installed extensions.
2. Temporarily disable or uninstall the one most likely responsible.
3. Re-run the same command and confirm the behavior difference.
4. If the extension is valuable, pin it and document what it changes.

This keeps you out of “terminal superstition” territory and turns the extension system into something you can reason about.

If you’re truly unsure, remove all extensions and re-add them one by one.

A safe adoption playbook (what actually works on teams)

If you want Gemini CLI to stick beyond a demo, standardize three things:

1. Pinned versions

For important extensions, pin versions (or commit hashes) so “it worked yesterday” remains true.

1. One extension per capability

Avoid monolithic extensions that do everything. Smaller units are easier to audit and replace.

1. Verification-first prompts

For engineering tasks, require proof steps (pytest, go test, npm test, docker build). Extensions help you encode those patterns, but you still need to demand the proof.

When not to use extensions

• If you can’t review the code (or the repo looks abandoned), don’t install it.
• If the extension bundles credentials or suggests unsafe copy-paste, stop and reassess.
• If you only need a one-off answer, don’t create a dependency — use the CLI directly.

Related on TokRepo

• OpenAI Codex CLI — another terminal-first coding agent with a strong verification loop story.
• Claude Code Templates — a catalog/installer approach for agents, commands, hooks, and MCP configs.
• Agent Skills Standard — a packaging mindset for reusable agent workflows.

Common pitfalls

• Installing extensions blindly. The extension gallery explicitly notes that extensions are sourced from public repositories and not guaranteed; treat extensions like any other dependency: inspect the code and permissions before installing.
• Forgetting restart semantics. Some extension management changes only apply after restarting the CLI session.
• Mixing “toy prompts” with real engineering. Make your prompts operational: include constraints, proof steps, and expected outputs.
• Losing provenance. When an extension matters, pin a version and write down why you enabled it.

FAQ

Q: What is a Gemini CLI extension?

A: An installable package (from GitHub or local paths) that adds reusable capability to Gemini CLI — including custom commands and tool integrations — as documented by the official Gemini CLI extensions docs.

Q: Where do extensions live on disk?

A: The docs describe an extensions directory under your home folder (for example ~/.gemini/extensions), with each extension containing a gemini-extension.json.

Q: How do I install an extension?

A: Use gemini extensions install <GitHub URL> as documented in the Gemini CLI extensions guide.