Appendix B — Gemini CLI companion

This appendix is explicitly scoped to the parts of Gemini CLI that diverge from Claude’s defaults or that make Gemini a better fit for a particular workload. Convergent primitives (briefing doc at repo root, slash commands, headless mode, MCP integration) are covered in the body chapters and not repeated here. The intent is a reference that helps a practitioner who already read the book translate its concepts to Gemini specifically, not a standalone tutorial.

What Gemini CLI is

Gemini CLI is Google’s open-source command-line agent, integrating the Gemini model family with local tooling. Its natural home is workflows where the developer already operates inside Google Cloud — existing Vertex AI contracts, existing ADC (Application Default Credentials) setup, existing BigQuery / GCS / Cloud Run infrastructure. In those contexts the credential chain, billing, and deployment path are ergonomic rather than adversarial.

Key defaults at time of capture:

What’s different about context

The corollary is discipline. A long-context model tempts the anti-pattern Ch 2 warns about: adding more because the budget allows it. The right use of Gemini’s context is to reduce pre-processing (less forced summarization, less aggressive chunking) when the task genuinely needs many files in view at once, not to make context hygiene optional.

Extension model: MCP-primary

Gemini CLI leans heavily on MCP as its extension surface. Where Claude exposes skills, hooks, and MCP as three distinct surfaces, Gemini unifies most of that territory around MCP servers. The upside: a cleaner mental model — all tool extension is an MCP server. The downside: more setup cost for tasks where Claude’s skill-as-directory or command-as-Markdown would be lighter-weight.

Memory and session commands

Gemini CLI’s built-in session commands include /memory with subcommands (refresh, add, show) that manage the persistent memory surface — GEMINI.md-derived context plus any memory updates made during a session. /memory refresh re-reads the briefing doc when it’s been edited mid-session; /chat manages conversation state.

The --yolo flag hazard

Gemini CLI ships a flag — --yolo — that disables all approval prompts, letting the agent run destructive actions without pausing. For ephemeral experimentation in a throwaway environment it is convenient; for CI, for production repositories, for anything that matters, it is dangerous.

The failure mode: a well-intentioned engineer uses --yolo to unblock a specific workflow, commits the invocation to a repo script, and months later the script runs in a context where the safety it skipped was load-bearing. The fix — and it applies to similar broad-authorization flags in any tool — is to treat --yolo as a local-session affordance only, never commit invocations that include it, and audit scripts for its presence as part of the team’s governance practice (Ch 13).

Authentication chains

Gemini CLI’s default auth path is Google Cloud ADC — the same credential chain that gcloud, Cloud Run deploys, and other Google Cloud tools use. Running gcloud auth application-default login once sets the credential; subsequent Gemini invocations inherit it. For Vertex AI–backed usage this is particularly smooth because the CLI, the model endpoint, and any downstream GCP services all resolve identity through the same chain.

For teams not already in Google Cloud, the auth setup cost is real (a GCP project, ADC, Vertex access). This is one of the tradeoffs that pushes some workloads toward other tools despite Gemini’s capability advantages.

GitHub Action

Google ships an official google-gemini/gemini-cli-action for GitHub Actions. The integration pattern is convergent with Claude and Codex (Ch 12): @mention-triggered agent runs on PRs and issues, agent outputs posted as comments or inline suggestions. Configuration lives in .github/workflows/; the action exposes inputs for prompt, allowed tools, credentials, output format.

When Gemini CLI is the right fit

Situations where Gemini is a particularly strong choice:

• Existing Google Cloud investment. The credential chain, billing, and compliance path are ergonomic; switching tools would add friction for no capability gain.
• Large-context workloads. Monorepo review, whole-document synthesis, long-lived architectural investigations — the context advantage is genuinely useful here.
• MCP-heavy extension ecosystem. Teams that have already standardized on MCP servers for their internal tooling get the most leverage from Gemini’s MCP-primary model.

Situations where another tool may fit better:

• Rich hook-driven automation where Claude Code’s dedicated hook events are ergonomic.
• Teams with existing OpenAI / Codex relationships whose workflows are already integrated there.
• Narrow, specific plan-mode-style workflows where Claude’s explicit read-only mode is a primitive rather than a convention.

Quick reference

• Binary: gemini; gemini -p "<prompt>" for print mode
• Briefing doc: GEMINI.md at repo root; re-read mid-session with /memory refresh
• Slash commands: .gemini/commands/ (project) or ~/.gemini/commands/ (user)
• Extension: MCP-primary — most tool extension is an MCP server
• Auth: Google Cloud ADC chain; Vertex AI is the ergonomic backend
• Hazard: --yolo disables all approvals; treat as local-only; audit scripts for its presence
• GitHub Action: google-gemini/gemini-cli-action
• Context: multi-hundred-K to multi-million tokens; use the window to reduce pre-processing, not to skip context hygiene
• Best fit: Google-Cloud-native teams, large-context workloads, MCP-standardized extension ecosystems
• Volatility: feature-surface; audit quarterly.