Gemini CLI for DevOps and security workflows A dark navy to teal title card with a faint plus-sign grid, reading “Gemini CLI” above “7 DevOps plus security workflows”, with a tha-shed.com tag in the corner. TERMINAL FIRST AGENTS Gemini CLI 7 DevOps + Security Workflows npm install -g @google/gemini-cli THA-SHED.COM open source / Apache 2.0
Featured illustration. Gemini CLI is an open-source terminal agent from Google, and this guide covers seven concrete DevOps and security workflows for it.
the shed // GEMINI CLI TUTORIAL

Gemini CLI puts a real agent in your terminal for free, with shell access, MCP servers, and a headless JSON mode that drops straight into CI. Here is how to make it earn its keep on DevOps and security work instead of just autocompleting your bash.

See the setup and two of the workflows in action, tap through the tabs below:




gemini-cli-devops.sh

// 60 seconds, node 20 or newer

npm install -g @google/gemini-cli
gemini
# pick "Sign in with Google" for the free tier
# 60 requests/min, 1,000 requests/day

// review your own diff before anyone else does

git diff main...HEAD | gemini -p "Review this diff as a
security engineer. Flag injection, secrets, broken
authz, and unsafe defaults. Cite file and line. Say
NOTHING FOUND if it is clean."

// structured output your pipeline can branch on

gemini -p "Audit terraform/ for public S3 buckets and
open security groups. Reply with findings only." \
  --output-format json | jq -r '.response' > audit.txt

test -s audit.txt || echo "clean"

Trust is the whole ballgame. Setting trust: true on an MCP server skips every tool-call confirmation for that server. Do it only for servers you wrote or fully control.

Scope your tokens. A broadly scoped personal access token handed to an MCP server can leak context between repos. Use the narrowest scope that works.

Sandbox before you script. Headless runs execute shell commands without a human in the loop, so pair them with sandboxing and trusted folders.

What Gemini CLI actually is

Gemini CLI is Google's open-source AI agent that runs in your terminal. Apache 2.0 licensed, roughly 105,000 stars on GitHub, and unlike a chat window it ships with real tools out of the box: file operations, shell commands, web fetching, and Google Search grounding. It speaks MCP, so any Model Context Protocol server you already run for another agent plugs straight in.

The part that matters for DevOps and security folks is not the chat. It is that gemini is a binary you can pipe into, script around, and drop into a CI job. That makes it a very different animal from an IDE assistant.

The free tier is generous enough to be your daily driver: sign in with a personal Google account and you get 60 requests per minute and 1,000 requests per day against Gemini 3 models with a 1M token context window. No API key management, no credit card. If you want specific model control, a Gemini API key from AI Studio gets you 1,000 requests a day across a mix of Flash and Pro. Teams running production workloads point it at Vertex AI instead.

Quick setup

You need Node 20 or newer. Three ways in, pick one:

npx @google/gemini-cli          # try it, install nothing
npm install -g @google/gemini-cli
brew install gemini-cli         # macOS and Linux

Then run gemini in a project directory and choose "Sign in with Google" when prompted. That is the whole onboarding. If your org gave you a paid Code Assist license, export GOOGLE_CLOUD_PROJECT with your project ID before launching.

Release channels are worth knowing about, because this project moves fast. Stable ships Tuesdays at 20:00 UTC, preview ships Tuesdays at 23:59 UTC, and nightly ships daily at 00:00 UTC. Pin stable on any machine that matters. Use nightly on the laptop where you like living dangerously.

The mindset: the agent is a coworker with root, not a search box

Here is the shift that makes Gemini CLI click. Most people treat AI tools as a better autocomplete. Wrong frame. Gemini CLI can read your repo, run your commands, hit your APIs, and write files. The right mental model is a fast, tireless junior engineer who has never seen your systems and will do exactly what you say, including the dumb thing.

That means two habits. First, give it context on purpose instead of hoping it guesses. A GEMINI.md file in your repo root is persistent context every session picks up, and that is where your conventions, your naming rules, and your "never touch prod without a ticket" policies belong. Second, constrain the output shape. An agent told to "check the logs" will write you an essay. An agent told to return findings only, or nothing, gives you something a script can branch on.

How a Gemini CLI request flows from prompt to output A five-stage horizontal diagram: your prompt, then GEMINI.md context, then the tool layer holding shell, files, search and MCP, then a confirmation gate, then structured output as JSON or text. Anatomy of one Gemini CLI run prompt in, structured output out

01 PROMPT gemini -p "..." or piped stdin

02 CONTEXT GEMINI.md team guardrails

03 TOOL LAYER shell file system web fetch + search MCP servers stdio / SSE / HTTP

04 CONFIRM approve / deny trust bypasses this

05 OUTPUT text / json stream-json too

Skip stage 04 with trust: true and the agent runs tools with no human in the loop. That is the whole risk surface. THA-SHED.COM

Illustration with example data. Every Gemini CLI run moves through the same five stages, and stage four is the one that decides whether an automation is safe to leave unattended.

7 workflows worth stealing

1. Review your own diff before anyone else does

The single highest-value habit. Pipe your branch diff in and ask for a security read, not a style read.

git diff main...HEAD | gemini -p "Review this diff as a security
engineer. Flag injection, secrets, broken authz, unsafe defaults.
Cite file and line. Say NOTHING FOUND if clean."

The "say NOTHING FOUND if clean" clause matters. Without it you get manufactured concerns, because the model assumes you asked for a reason.

2. Triage an incident from the logs

Point it at a log directory and let the shell tool do the grepping. Give it the shape of the answer you want.

gemini -p "Read logs/ from the last 2 hours. Give me: probable
root cause, the 3 log lines that prove it, and the one command
to confirm. No speculation beyond the evidence."

3. Turn your runbooks into custom slash commands

Custom commands are reusable prompt templates you invoke with a slash. If your team runs the same certificate expiry check every month, that is a command, not a wiki page nobody reads. Same for on-call handoff summaries and dependency audits.

4. Wire in MCP servers so it can see your real stack

This is where Gemini CLI stops being a code helper and starts being ops tooling. Add servers with the CLI rather than hand-editing JSON:

gemini mcp add --transport http monitoring https://internal.example/mcp/ \
  --header "Authorization: Bearer YOUR_TOKEN"

gemini mcp add scanner python scan_server.py --include-tools "list_findings,get_cve"
gemini mcp list

Then in session you address them directly: "@monitoring show me error rate for checkout over the last hour". Note --include-tools in that second command. It is an allowlist, and it is the cheapest safety control you get.

Example output of the slash mcp command showing server status A mock terminal window showing three example MCP servers, two connected and one disconnected, with the tools each one exposes. All names and values are invented examples. gemini -- example-project > /mcp MCP Servers Status: monitoring (CONNECTED) httpUrl: https://internal.example/mcp/ Tools: query_metrics, list_alerts, get_dashboard scanner (CONNECTED) command: python scan_server.py Tools: list_findings, get_cve (2 of 9 allowed) ticketing (DISCONNECTED) Error: Connection refused Discovery: COMPLETED THA-SHED.COM (Illustration with example data)
Illustration with example data. Running slash-mcp inside a session shows connection state per server and exactly which tools survived your allowlist, which is the fastest way to catch a server that is quietly offline.

5. Encode team guardrails in GEMINI.md

A GEMINI.md at your repo root is context every session loads. Ours reads less like documentation and more like a contract:

# Guardrails
- Never run kubectl against a context containing "prod".
- Terraform changes: output a plan, never apply.
- Secrets live in Vault. Never write literal credentials to a file.
- Prefer reading over writing. Ask before creating new files.

This one file removes most of the "why did it do that" moments. It also travels with the repo, so new hires and the agent get the same briefing.

6. Gate a pull request in CI with headless mode

Headless mode kicks in automatically in non-TTY environments or when you pass -p. Add --output-format json and you get a single object with a response field plus token and tool-usage stats, which jq can slice. There is also stream-json for newline-delimited events if you are monitoring something long-running.

gemini -p "Scan the diff for hardcoded secrets. Output only a
JSON array of findings, empty if none." --output-format json \
  | jq -r '.response' > findings.json

jq -e 'length == 0' findings.json || exit 1

Google also ships an official GitHub Action for this, which handles PR review, issue triage, and on-demand help when someone mentions the bot in a thread.

7. Ground a research question in real sources

Built-in Google Search grounding means you can ask about a CVE published this morning without it hallucinating a patch version. "Search for the current status of CVE-2026-XXXXX, list affected versions, and tell me if our package.json is exposed" is a single prompt that would otherwise be twenty minutes of tab juggling.

Example CI job output from Gemini CLI headless mode A mock CI log showing a headless Gemini CLI secret scan returning a JSON object with one finding, and the pipeline step failing as a result. All values are invented examples. ci / secret-scan -- example run #418 $ gemini -p "..." --output-format json | jq -r '.response' [ { "file": "src/config/loader.ts", "line": 47, "severity": "high", "issue": "example API token committed inline" } ] step failed: 1 finding, exit 1 tokens: 14,208 prompt / 611 output duration: 6.4s THA-SHED.COM (Illustration with example data)
Illustration with example data. Headless mode plus jq turns a prompt into a pass or fail signal, so a secret scan can block a merge instead of producing prose nobody reads.

Safety and gotchas

The trust flag is the whole risk surface. Setting trust to true on an MCP server bypasses every tool-call confirmation from that server, permanently. The docs say to use it only for servers you completely control, and they mean it. A compromised or sloppy third-party server with trust enabled is arbitrary code execution wearing a helpful hat.

Token scope leaks across repos. Google's own guidance calls out that broadly scoped personal access tokens handed to MCP servers can leak information between repositories. Mint narrow tokens per server.

OAuth needs a browser. Remote MCP servers using OAuth open a local browser and expect a redirect on localhost port 7777. That does not work in headless containers or bare SSH sessions, which is exactly where you want your CI jobs to run. Plan for service account impersonation or pre-seeded tokens instead.

Sandbox and trusted folders exist for a reason. Gemini CLI supports sandboxed execution and per-folder execution policies. Turn them on before you point the thing at anything with production credentials on the box.

Tool name collisions get silently renamed. When two servers expose the same tool name, first registration wins the clean name and the rest get prefixed as servername__toolname. If a prompt suddenly stops finding a tool, check for a collision.

Quota and cost tips

The free tier caps at 60 requests per minute and 1,000 per day, which sounds like plenty until a CI pipeline starts firing on every push. Three things keep you under it. Batch related questions into one prompt instead of five. Lean on token caching, which the CLI supports and which cuts repeat context costs on long sessions. And use -m to drop to a lighter model for cheap work like log summarization, saving the heavy model for reasoning-shaped tasks.

Watch out for the sneaky one: a 1M token context window is an invitation to dump your whole monorepo into context. Do not. Use --include-directories to scope it to the two or three directories that actually matter. Narrower context is both cheaper and more accurate.

FAQ

Is Gemini CLI free for commercial use?

The tool itself is Apache 2.0 licensed, so yes. The free usage tier tied to a personal Google account has its own quota limits and terms of service, and organizations on paid Code Assist licenses or Vertex AI get different limits. Check the quota terms before you build a business process on the free tier.

How is it different from Claude Code or Cursor?

Cursor is an editor, so it optimizes for the write-code loop. Claude Code and Gemini CLI are both terminal agents, and the practical differences come down to model behavior, quota economics, and ecosystem. Gemini CLI's free tier is unusually generous, its Google Search grounding is built in rather than bolted on, and it is fully open source. If you already run MCP servers, all three can share them. Our Claude Code DevOps workflows guide covers the other side of that comparison.

Can I run it in CI without a human approving tool calls?

Yes, that is what headless mode is for, and it is also where you need to be most careful. Combine --output-format json with a tightly scoped GEMINI.md, an MCP allowlist via --include-tools, sandboxing, and a service account rather than a personal token. Never set trust to true just to make a pipeline stop prompting you.

Where to take this next

Install it, then pick exactly one workflow above and run it every day for a week. The diff review is the easiest habit to build and it pays off immediately. Once that is muscle memory, add a GEMINI.md and one MCP server, and you will feel the difference between a chatbot and an agent that can actually see your stack.

If you are building these skills toward a role in DevOps, cloud, or security, our course catalog covers the fundamentals these tools sit on top of. The agent is a force multiplier, not a substitute for knowing what a bad security group looks like.