Gemini CLI v0.61.0
Gemini CLI v0.61.0 adds Gemini 3.8 Flash
Plus Gemini 3.5 Flash Lite, guarded build files, and a tighter sandbox.
Gemini CLI now supports Gemini 3.8 Flash as its newest Flash model. Gemini 3.5 Flash Lite joins it, and Gemini 3.5 Flash and 3.1 Flash Lite become the base tier.
01: The new Flash models
The new Flash models.
Gemini API keys, Vertex AI and gateways get Gemini 3.8 Flash right away
With a Gemini API key, Vertex AI, or a gateway, both new models are available as soon as you upgrade. With Login with Google, they arrive when the rollout flag switches on for you.
The flash alias now resolves to Gemini 3.8 Flash
The short model names follow them. Once you have access, asking for flash gets you Gemini 3.8 Flash, and asking for flash lite gets you Gemini 3.5 Flash Lite.
The fallback model moves up from 2.5 Flash to 3.5 Flash
When Gemini CLI falls back to an older model, it now lands on Gemini 3.5 Flash instead of 2.5 Flash. That covers the flash alias without preview access, and the last resort after retries.
Two model-config conditions have new names
If you write your own model configs, useGemini3_5Flash is now useLatestFlash, and the Flash Lite condition is renamed to match. The old names still work as deprecated aliases.
02: Pinning a model
Pinning a model.
--model gemini-3.8-flash now reaches the API as written
Pin a versioned Flash model with the model flag, and that exact ID now goes out with the request. Before, Gemini CLI quietly swapped it for the Gemini 3.5 Flash rollout default.
03: Build files and outside content
Build files and outside content.
Editing a build file always asks you first
When the agent edits a build file, such as package.json, a Makefile, or build dot gradle, Gemini CLI now always stops to ask, with a security warning. In a non-interactive run, the edit is denied.
After a build file changes, the next build or test command asks too
Once a build file has changed in a session, the next build or test command, like npm, make, or cargo, asks before it runs. Allow for this session is no longer offered for it.
Flags copied from outside content trigger a critical warning
If a command's flags came from outside content, like a fetched web page, an MCP server response, or a Google Doc, Gemini CLI lists those flags in a critical warning and waits for your approval.
04: The sandbox
The sandbox.
The sandbox refuses to start from your home folder
Start a sandboxed session from the root of your home folder, from the filesystem root, or from the dot gemini folder, and it now refuses. Those folders can't be mounted into a container either.
Containers get a cleaned copy of your settings
Docker and Podman sandboxes now get a sanitized copy of your settings file, with hooks, custom tool commands, and API keys stripped out. Your real settings folder stays on the host.
macOS Seatbelt blocks your credential files
On macOS, the Seatbelt profiles now deny reading and writing your OAuth credentials, your Google accounts file, your trusted hooks, and any dot env file.
Seatbelt sessions keep their history in ~/.cache/.gemini
Seatbelt now blocks writes to the dot gemini folder, so a sandboxed session keeps its history in a dot gemini folder under dot cache, and it still carries over between runs.
Your own commands load in untrusted workspaces
Your personal commands in the dot gemini commands folder now load even in an untrusted workspace. Commands from the workspace and from extensions still depend on folder trust.
Install it from npm
To upgrade, install the Gemini CLI package globally from npm, pinned to this release.



















