chore: import upstream snapshot with attribution
This commit is contained in:
wehub-resource-sync
Symlink
+1
@@ -0,0 +1 @@
|
||||
../CONTRIBUTING.md
|
||||
@@ -0,0 +1,176 @@
|
||||
# Enterprise Admin Controls
|
||||
|
||||
Gemini CLI empowers enterprise administrators to manage and enforce security
|
||||
policies and configuration settings across their entire organization. Secure
|
||||
defaults are enabled automatically for all enterprise users, but can be
|
||||
customized via the [Management Console](https://goo.gle/manage-gemini-cli).
|
||||
|
||||
**Enterprise Admin Controls are enforced globally and cannot be overridden by
|
||||
users locally**, ensuring a consistent security posture.
|
||||
|
||||
## Admin Controls vs. System Settings
|
||||
|
||||
While [System-wide settings](../cli/settings.md) act as convenient configuration
|
||||
overrides, they can still be modified by users with sufficient privileges. In
|
||||
contrast, admin controls are immutable at the local level, making them the
|
||||
preferred method for enforcing policy.
|
||||
|
||||
## Available Controls
|
||||
|
||||
### Strict Mode
|
||||
|
||||
**Enabled/Disabled** | Default: enabled
|
||||
|
||||
If enabled, users will not be able to enter yolo mode.
|
||||
|
||||
### Extensions
|
||||
|
||||
**Enabled/Disabled** | Default: disabled
|
||||
|
||||
If disabled, users will not be able to use or install extensions. See
|
||||
[Extensions](../extensions/index.md) for more details.
|
||||
|
||||
### MCP
|
||||
|
||||
#### Enabled/Disabled
|
||||
|
||||
**Enabled/Disabled** | Default: disabled
|
||||
|
||||
If disabled, users will not be able to use MCP servers. See
|
||||
[MCP Server Integration](../tools/mcp-server.md) for more details.
|
||||
|
||||
#### MCP Servers (preview)
|
||||
|
||||
**Default**: empty
|
||||
|
||||
Allows administrators to define an explicit allowlist of MCP servers. This
|
||||
guarantees that users can only connect to trusted MCP servers defined by the
|
||||
organization.
|
||||
|
||||
**Allowlist Format:**
|
||||
|
||||
```json
|
||||
{
|
||||
"mcpServers": {
|
||||
"external-provider": {
|
||||
"url": "https://api.mcp-provider.com",
|
||||
"type": "sse",
|
||||
"trust": true,
|
||||
"includeTools": ["toolA", "toolB"],
|
||||
"excludeTools": []
|
||||
},
|
||||
"internal-corp-tool": {
|
||||
"url": "https://mcp.internal-tool.corp",
|
||||
"type": "http",
|
||||
"includeTools": [],
|
||||
"excludeTools": ["adminTool"]
|
||||
}
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
**Supported Fields:**
|
||||
|
||||
- `url`: (Required) The full URL of the MCP server endpoint.
|
||||
- `type`: (Required) The connection type (for example, `sse` or `http`).
|
||||
- `trust`: (Optional) If set to `true`, the server is trusted and tool execution
|
||||
will not require user approval.
|
||||
- `includeTools`: (Optional) An explicit list of tool names to allow. If
|
||||
specified, only these tools will be available.
|
||||
- `excludeTools`: (Optional) A list of tool names to hide. These tools will be
|
||||
blocked.
|
||||
|
||||
**Client Enforcement Logic:**
|
||||
|
||||
- **Empty Allowlist**: If the admin allowlist is empty, the client uses the
|
||||
user’s local configuration as is (unless the MCP toggle above is disabled).
|
||||
- **Active Allowlist**: If the allowlist contains one or more servers, **all
|
||||
locally configured servers not present in the allowlist are ignored**.
|
||||
- **Configuration Merging**: For a server to be active, it must exist in
|
||||
**both** the admin allowlist and the user’s local configuration (matched by
|
||||
name). The client merges these definitions as follows:
|
||||
- **Override Fields**: The `url`, `type`, & `trust` are always taken from the
|
||||
admin allowlist, overriding any local values.
|
||||
- **Tools Filtering**: If `includeTools` or `excludeTools` are defined in the
|
||||
allowlist, the admin’s rules are used exclusively. If both are undefined in
|
||||
the admin allowlist, the client falls back to the user’s local tool
|
||||
settings.
|
||||
- **Cleared Fields**: To ensure security and consistency, the client
|
||||
automatically clears local execution fields (`command`, `args`, `env`,
|
||||
`cwd`, `httpUrl`, `tcp`). This prevents users from overriding the connection
|
||||
method.
|
||||
- **Other Fields**: All other MCP fields are pulled from the user’s local
|
||||
configuration.
|
||||
- **Missing Allowlisted Servers**: If a server appears in the admin allowlist
|
||||
but is missing from the local configuration, it will not be initialized. This
|
||||
ensures users maintain final control over which permitted servers are actually
|
||||
active in their environment.
|
||||
|
||||
#### Required MCP Servers (preview)
|
||||
|
||||
**Default**: empty
|
||||
|
||||
Allows administrators to define MCP servers that are **always injected** into
|
||||
the user's environment. Unlike the allowlist (which filters user-configured
|
||||
servers), required servers are automatically added regardless of the user's
|
||||
local configuration.
|
||||
|
||||
**Required Servers Format:**
|
||||
|
||||
```json
|
||||
{
|
||||
"requiredMcpServers": {
|
||||
"corp-compliance-tool": {
|
||||
"url": "https://mcp.corp/compliance",
|
||||
"type": "http",
|
||||
"trust": true,
|
||||
"description": "Corporate compliance tool"
|
||||
},
|
||||
"internal-registry": {
|
||||
"url": "https://registry.corp/mcp",
|
||||
"type": "sse",
|
||||
"authProviderType": "google_credentials",
|
||||
"oauth": {
|
||||
"scopes": ["https://www.googleapis.com/auth/scope"]
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
**Supported Fields:**
|
||||
|
||||
- `url`: (Required) The full URL of the MCP server endpoint.
|
||||
- `type`: (Required) The connection type (`sse` or `http`).
|
||||
- `trust`: (Optional) If set to `true`, tool execution will not require user
|
||||
approval. Defaults to `true` for required servers.
|
||||
- `description`: (Optional) Human-readable description of the server.
|
||||
- `authProviderType`: (Optional) Authentication provider (`dynamic_discovery`,
|
||||
`google_credentials`, or `service_account_impersonation`).
|
||||
- `oauth`: (Optional) OAuth configuration including `scopes`, `clientId`, and
|
||||
`clientSecret`.
|
||||
- `targetAudience`: (Optional) OAuth target audience for service-to-service
|
||||
auth.
|
||||
- `targetServiceAccount`: (Optional) Service account email to impersonate.
|
||||
- `headers`: (Optional) Additional HTTP headers to send with requests.
|
||||
- `includeTools` / `excludeTools`: (Optional) Tool filtering lists.
|
||||
- `timeout`: (Optional) Timeout in milliseconds for MCP requests.
|
||||
|
||||
**Client Enforcement Logic:**
|
||||
|
||||
- Required servers are injected **after** allowlist filtering, so they are
|
||||
always available even if the allowlist is active.
|
||||
- If a required server has the **same name** as a locally configured server, the
|
||||
admin configuration **completely overrides** the local one.
|
||||
- Required servers only support remote transports (`sse`, `http`). Local
|
||||
execution fields (`command`, `args`, `env`, `cwd`) are not supported.
|
||||
- Required servers can coexist with allowlisted servers — both features work
|
||||
independently.
|
||||
|
||||
### Unmanaged Capabilities
|
||||
|
||||
**Enabled/Disabled** | Default: disabled
|
||||
|
||||
If disabled, users will not be able to use certain features. Currently, this
|
||||
control disables Agent Skills. See [Agent Skills](../cli/skills.md) for more
|
||||
details.
|
||||
Binary file not shown.
|
After Width: | Height: | Size: 119 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 60 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 110 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 58 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 54 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 381 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 154 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 141 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 151 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 146 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 137 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 259 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 155 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 144 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 156 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 154 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 135 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 134 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 163 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 158 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 146 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 138 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 54 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 120 KiB |
File diff suppressed because it is too large
Load Diff
@@ -0,0 +1,34 @@
|
||||
# Latest stable release: v0.50.0
|
||||
|
||||
Released: July 08, 2026
|
||||
|
||||
For most users, our latest stable release is the recommended release. Install
|
||||
the latest stable version with:
|
||||
|
||||
```
|
||||
npm install -g @google/gemini-cli
|
||||
```
|
||||
|
||||
## Highlights
|
||||
|
||||
- **Tool Registry Discovery:** Introduced tool registry discovery capabilities,
|
||||
enabling automatic detection and registration of tools to improve
|
||||
extensibility.
|
||||
- **Release Verification Improvements:** Enhanced release verification by
|
||||
ignoring scripts during `npm ci` and preventing workspace binary shadowing.
|
||||
- **CI Pipeline Safeguards:** Strengthened the CI pipeline to prevent bad NPM
|
||||
releases and ensure promote job failures are correctly surfaced.
|
||||
|
||||
## What's Changed
|
||||
|
||||
- fix/verify release npm ci ignore scripts by @rmedranollamas in
|
||||
[#28116](https://github.com/google-gemini/gemini-cli/pull/28116)
|
||||
- fix(ci): prevent workspace binary shadowing in release verification by
|
||||
@galdawave in [#28132](https://github.com/google-gemini/gemini-cli/pull/28132)
|
||||
- Feat/tool registry discovery by @ved015 in
|
||||
[#28113](https://github.com/google-gemini/gemini-cli/pull/28113)
|
||||
- fix(ci): prevent bad NPM releases and promote job crashes by @galdawave in
|
||||
[#28147](https://github.com/google-gemini/gemini-cli/pull/28147)
|
||||
|
||||
**Full Changelog**:
|
||||
https://github.com/google-gemini/gemini-cli/compare/v0.49.0...v0.50.0
|
||||
@@ -0,0 +1,65 @@
|
||||
# Preview release: v0.51.0-preview.0
|
||||
|
||||
Released: July 8, 2026
|
||||
|
||||
Our preview release includes the latest, new, and experimental features. This
|
||||
release may not be as stable as our [latest weekly release](latest.md).
|
||||
|
||||
To install the preview release:
|
||||
|
||||
```
|
||||
npm install -g @google/gemini-cli@preview
|
||||
```
|
||||
|
||||
## Highlights
|
||||
|
||||
- **Caretaker Cloud Run Services**: Implemented a Cloud Run webhook ingestion
|
||||
service and egress service skeleton to support advanced caretaker features.
|
||||
- **Enhanced Security & Sandbox Hardening**: Enforced a case-insensitive
|
||||
sensitive path blocklist and VS Code human-in-the-loop (HITL) checks, resolved
|
||||
a directory escape vulnerability in the memory import processor, and marked
|
||||
`~/.gitconfig` as read-only within the macOS sandbox.
|
||||
- **Improved Thought Leakage and Escape Handling**: Resolved potential thought
|
||||
leakage by stripping thinking/thought processes from scrubbed history turns,
|
||||
and ensured escape sequences in string literals are correctly preserved for
|
||||
modern models.
|
||||
- **Robust Path & API Updates**: Enhanced defensive path resolution for
|
||||
at-reference files, and updated the Vertex AI base URL configuration to
|
||||
support the latest API updates.
|
||||
|
||||
## What's Changed
|
||||
|
||||
- Changelog for v0.50.0-preview.1 by @gemini-cli-robot in
|
||||
[#28150](https://github.com/google-gemini/gemini-cli/pull/28150)
|
||||
- Fix no_proxy test by @jerrylin3321 in
|
||||
[#28131](https://github.com/google-gemini/gemini-cli/pull/28131)
|
||||
- chore(release): bump version to 0.51.0-nightly.20260625.g3fbf93e26 by
|
||||
@gemini-cli-robot in
|
||||
[#28151](https://github.com/google-gemini/gemini-cli/pull/28151)
|
||||
- Vertex base url update by @DavidAPierce in
|
||||
[#28145](https://github.com/google-gemini/gemini-cli/pull/28145)
|
||||
- fix(security): enforce case-insensitive sensitive path blocklist and vscode
|
||||
hitl by @luisfelipe-alt in
|
||||
[#27966](https://github.com/google-gemini/gemini-cli/pull/27966)
|
||||
- fix(core-tools): resolve defensive path resolution for at-reference files and
|
||||
fix macOS tests by @luisfelipe-alt in
|
||||
[#28053](https://github.com/google-gemini/gemini-cli/pull/28053)
|
||||
- feat(caretaker): implement Cloud Run webhook ingestion service by @chadd28 in
|
||||
[#28015](https://github.com/google-gemini/gemini-cli/pull/28015)
|
||||
- fix(core): resolve symbolic link directory escape in memory import processor
|
||||
by @luisfelipe-alt in
|
||||
[#28233](https://github.com/google-gemini/gemini-cli/pull/28233)
|
||||
- feat(caretaker): egress cloud run service skeleton by @chadd28 in
|
||||
[#28167](https://github.com/google-gemini/gemini-cli/pull/28167)
|
||||
- fix(sandbox): make ~/.gitconfig read-only in the macOS sandbox by
|
||||
@ompatel-aiml in
|
||||
[#28221](https://github.com/google-gemini/gemini-cli/pull/28221)
|
||||
- fix(core): preserve escape sequences in string literals for modern models by
|
||||
@luisfelipe-alt in
|
||||
[#28299](https://github.com/google-gemini/gemini-cli/pull/28299)
|
||||
- fix(core): strip thoughts from scrubbed history turns and resolve thought
|
||||
leakage by @amelidev in
|
||||
[#27971](https://github.com/google-gemini/gemini-cli/pull/27971)
|
||||
|
||||
**Full Changelog**:
|
||||
https://github.com/google-gemini/gemini-cli/compare/v0.50.0-preview.1...v0.51.0-preview.0
|
||||
@@ -0,0 +1,126 @@
|
||||
# ACP Mode
|
||||
|
||||
ACP (Agent Client Protocol) mode is a special operational mode of Gemini CLI
|
||||
designed for programmatic control, primarily for IDE and other developer tool
|
||||
integrations. It uses a JSON-RPC protocol over stdio to communicate between
|
||||
Gemini CLI agent and a client.
|
||||
|
||||
To start Gemini CLI in ACP mode, use the `--acp` flag:
|
||||
|
||||
```bash
|
||||
gemini --acp
|
||||
```
|
||||
|
||||
## Agent Client Protocol (ACP)
|
||||
|
||||
ACP is an open protocol that standardizes how AI coding agents communicate with
|
||||
code editors and IDEs. It addresses the challenge of fragmented distribution,
|
||||
where agents traditionally needed custom integrations for each client. With ACP,
|
||||
developers can implement their agent once, and it becomes compatible with any
|
||||
ACP-compliant editor.
|
||||
|
||||
For a comprehensive introduction to ACP, including its architecture and
|
||||
benefits, refer to the official
|
||||
[ACP Introduction](https://agentclientprotocol.com/get-started/introduction)
|
||||
documentation.
|
||||
|
||||
### Existing integrations using ACP
|
||||
|
||||
The ACP Agent Registry simplifies the distribution and management of
|
||||
ACP-compatible agents across various IDEs. Gemini CLI is an ACP-compatible agent
|
||||
and can be found in this registry.
|
||||
|
||||
For more general information about the registry, and how to use it with specific
|
||||
IDEs like JetBrains and Zed, refer to the
|
||||
[IDE Integration](../ide-integration/index.md) documentation.
|
||||
|
||||
You can also find more information on the official
|
||||
[ACP Agent Registry](https://agentclientprotocol.com/get-started/registry) page.
|
||||
|
||||
## Architecture and protocol basics
|
||||
|
||||
ACP mode establishes a client-server relationship between your tool (the client)
|
||||
and Gemini CLI (the server).
|
||||
|
||||
- **Communication:** The entire communication happens over standard input/output
|
||||
(stdio) using the JSON-RPC 2.0 protocol.
|
||||
- **Client's role:** The client is responsible for sending requests (for
|
||||
example, prompts) and handling responses and notifications from Gemini CLI.
|
||||
- **Gemini CLI's role:** In ACP mode, Gemini CLI listens for incoming JSON-RPC
|
||||
requests, processes them, and sends back responses.
|
||||
|
||||
The core of the ACP implementation can be found in
|
||||
`packages/cli/src/acp/acpClient.ts`.
|
||||
|
||||
### Extending with MCP
|
||||
|
||||
ACP can be used with the Model Context Protocol (MCP). This lets an ACP client
|
||||
(like an IDE) expose its own functionality as "tools" that the Gemini model can
|
||||
use.
|
||||
|
||||
1. The client implements an **MCP server** that advertises its tools.
|
||||
2. During the ACP `initialize` handshake, the client provides the connection
|
||||
details for its MCP server.
|
||||
3. Gemini CLI connects to the MCP server, discovers the available tools, and
|
||||
makes them available to the AI model.
|
||||
4. When the model decides to use one of these tools, Gemini CLI sends a tool
|
||||
call request to the MCP server.
|
||||
|
||||
This mechanism lets for a powerful, two-way integration where the agent can
|
||||
leverage the IDE's capabilities to perform tasks. The MCP client logic is in
|
||||
`packages/core/src/tools/mcp-client.ts`.
|
||||
|
||||
## Capabilities and supported methods
|
||||
|
||||
The ACP protocol exposes a number of methods for ACP clients (for example IDEs)
|
||||
to control Gemini CLI.
|
||||
|
||||
### Core methods
|
||||
|
||||
- `initialize`: Establishes the initial connection and lets the client to
|
||||
register its MCP server.
|
||||
- `authenticate`: Authenticates the user.
|
||||
- `newSession`: Starts a new chat session.
|
||||
- `loadSession`: Loads a previous session.
|
||||
- `prompt`: Sends a prompt to the agent.
|
||||
- `cancel`: Cancels an ongoing prompt.
|
||||
|
||||
### Session control
|
||||
|
||||
- `setSessionMode`: Allows changing the approval level for tool calls (for
|
||||
example, to `auto-approve`).
|
||||
- `unstable_setSessionModel`: Changes the model for the current session.
|
||||
|
||||
### File system proxy
|
||||
|
||||
ACP includes a proxied file system service. This means that when the agent needs
|
||||
to read or write files, it does so through the ACP client. This is a security
|
||||
feature that ensures the agent only has access to the files that the client (and
|
||||
by extension, the user) has explicitly allowed.
|
||||
|
||||
## Debugging and telemetry
|
||||
|
||||
You can get insights into the ACP communication and the agent's behavior through
|
||||
debugging logs and telemetry.
|
||||
|
||||
### Debugging logs
|
||||
|
||||
To enable general debugging logs, start Gemini CLI with the `--debug` flag:
|
||||
|
||||
```bash
|
||||
gemini --acp --debug
|
||||
```
|
||||
|
||||
### Telemetry
|
||||
|
||||
For more detailed telemetry, you can use the following environment variables to
|
||||
capture telemetry data to a file:
|
||||
|
||||
- `GEMINI_TELEMETRY_ENABLED=true`
|
||||
- `GEMINI_TELEMETRY_TARGET=local`
|
||||
- `GEMINI_TELEMETRY_OUTFILE=/path/to/your/log.json`
|
||||
|
||||
This will write a JSON log file containing detailed information about all the
|
||||
events happening within the agent, including ACP requests and responses. The
|
||||
integration test `integration-tests/acp-telemetry.test.ts` provides a working
|
||||
example of how to set this up.
|
||||
@@ -0,0 +1,164 @@
|
||||
# Auto Memory
|
||||
|
||||
Auto Memory is an experimental feature that mines your past Gemini CLI sessions
|
||||
in the background and proposes durable memory updates and reusable
|
||||
[Agent Skills](./skills.md). You review each candidate before it becomes
|
||||
available to future sessions: apply memory updates, promote skills, or discard
|
||||
anything you do not want.
|
||||
|
||||
<!-- prettier-ignore -->
|
||||
> [!NOTE]
|
||||
> This is an experimental feature currently under active development.
|
||||
|
||||
## Overview
|
||||
|
||||
Every session you run with Gemini CLI is recorded locally as a transcript. Auto
|
||||
Memory scans those transcripts for durable facts, preferences, workflow
|
||||
constraints, and procedural patterns that recur across sessions. It can draft
|
||||
memory updates as unified diff `.patch` files and draft reusable procedures as
|
||||
`SKILL.md` files. All candidates are held in a project-local inbox until you
|
||||
approve or discard them.
|
||||
|
||||
You'll use Auto Memory when you want to:
|
||||
|
||||
- **Capture team workflows** that you find yourself walking the agent through
|
||||
more than once.
|
||||
- **Preserve durable project context** such as repeated verification commands,
|
||||
local constraints, or personal project notes.
|
||||
- **Codify hard-won fixes** for project-specific landmines so future sessions
|
||||
avoid them.
|
||||
- **Bootstrap a skills library** without writing every `SKILL.md` by hand.
|
||||
|
||||
Auto Memory complements direct memory-file editing. The agent can still persist
|
||||
explicit user instructions by editing the appropriate Markdown memory file; Auto
|
||||
Memory infers candidates from past sessions, writes reviewable patches or skill
|
||||
drafts, and never applies them without your approval.
|
||||
|
||||
## Prerequisites
|
||||
|
||||
- Gemini CLI installed and authenticated.
|
||||
- At least one idle project session with 10 or more user messages. Auto Memory
|
||||
ignores active, trivial, and sub-agent sessions.
|
||||
|
||||
## How to enable Auto Memory
|
||||
|
||||
Auto Memory is off by default. Enable it in your settings file:
|
||||
|
||||
1. Open your global settings file at `~/.gemini/settings.json`. If you only
|
||||
want Auto Memory in one project, edit `.gemini/settings.json` in that
|
||||
project instead.
|
||||
|
||||
2. Add the experimental flag:
|
||||
|
||||
```json
|
||||
{
|
||||
"experimental": {
|
||||
"autoMemory": true
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
3. Restart Gemini CLI. The flag requires a restart because the extraction
|
||||
service starts during session boot.
|
||||
|
||||
## How Auto Memory works
|
||||
|
||||
Auto Memory runs as a background task on session startup. It does not block the
|
||||
UI, consume your interactive turns, or surface tool prompts.
|
||||
|
||||
1. **Eligibility scan.** The service indexes recent sessions from
|
||||
`~/.gemini/tmp/<project>/chats/`. Sessions are eligible only if they have
|
||||
been idle for at least three hours and contain at least 10 user messages.
|
||||
2. **Lock acquisition.** A lock file in the project's memory directory
|
||||
coordinates across multiple CLI instances so extraction runs at most once at
|
||||
a time. A state file records processed session versions, and extraction is
|
||||
throttled so short back-to-back CLI launches do not repeatedly scan history.
|
||||
3. **Candidate extraction.** A background extraction agent reviews the session
|
||||
index, reads any sessions that look like they contain durable memory or
|
||||
repeated procedural workflows, and drafts candidates. It defaults to
|
||||
creating no artifacts unless the evidence is strong, so many runs produce no
|
||||
inbox items.
|
||||
4. **Safety boundaries.** Auto Memory writes candidates to a review inbox. It
|
||||
cannot directly edit active memory files, settings, credentials, or project
|
||||
`GEMINI.md` files.
|
||||
5. **Patch validation.** Skill update patches are parsed and dry-run before
|
||||
they are surfaced. Memory patches are parsed, target-allowlisted, and
|
||||
applied atomically only when you approve them from the inbox.
|
||||
6. **Notification.** When a run produces new candidates, Gemini CLI surfaces an
|
||||
inline message telling you how many items are waiting.
|
||||
|
||||
## How to review extracted items
|
||||
|
||||
Use the `/memory inbox` slash command to open the inbox dialog at any time:
|
||||
|
||||
**Command:** `/memory inbox`
|
||||
|
||||
The dialog groups pending items into new skills, skill updates, and memory
|
||||
updates. From there you can:
|
||||
|
||||
- **Read** the full `SKILL.md` body before deciding.
|
||||
- **Promote** a skill to your user (`~/.gemini/skills/`) or workspace
|
||||
(`.gemini/skills/`) directory.
|
||||
- **Discard** a skill you do not want.
|
||||
- **Apply** or reject a `.patch` proposal against an existing skill.
|
||||
- **Review** memory diffs before they touch active files.
|
||||
- **Apply** or dismiss private and global memory patches. Private patches target
|
||||
the project memory directory; global patches target only your personal
|
||||
`~/.gemini/GEMINI.md` file.
|
||||
|
||||
Promoted skills become discoverable in the next session and follow the standard
|
||||
[skill discovery precedence](./skills.md#skill-discovery-tiers). Applied memory
|
||||
patches update the underlying memory files and reload memory for the current
|
||||
session.
|
||||
|
||||
## How to disable Auto Memory
|
||||
|
||||
To turn off background extraction, set the flag back to `false` in your settings
|
||||
file and restart Gemini CLI:
|
||||
|
||||
```json
|
||||
{
|
||||
"experimental": {
|
||||
"autoMemory": false
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
Disabling the flag stops the background service immediately on the next session
|
||||
start. Existing inbox items remain on disk; you can either drain them with
|
||||
`/memory inbox` first or remove the project memory directory manually.
|
||||
|
||||
## Data and privacy
|
||||
|
||||
- Auto Memory only reads session files that already exist locally on your
|
||||
machine.
|
||||
- Auto Memory uses model calls to analyze selected local transcript content
|
||||
during extraction. No candidates are applied automatically, but transcript
|
||||
excerpts may be sent to the configured model as part of those calls.
|
||||
- The extraction agent is instructed to redact secrets, tokens, and credentials
|
||||
it encounters and to never copy large tool outputs verbatim.
|
||||
- Drafted skills and memory patches live in your project's memory directory
|
||||
until you promote, apply, dismiss, or discard them. They are not automatically
|
||||
loaded into any session.
|
||||
|
||||
## Limitations
|
||||
|
||||
- The extraction agent runs on a preview Gemini Flash model. Extraction quality
|
||||
depends on the model's ability to recognize durable patterns versus one-off
|
||||
incidents.
|
||||
- Auto Memory does not extract memory or skills from the current session. It
|
||||
only considers sessions that have been idle for three hours or more.
|
||||
- Project or workspace shared instructions in project `GEMINI.md` files are not
|
||||
auto-extractable. Auto Memory can propose private project memory, global
|
||||
personal memory, and skills.
|
||||
- Inbox items are stored per project. Skills extracted in one workspace are not
|
||||
visible from another until you promote them to the user-scope skills
|
||||
directory.
|
||||
|
||||
## Next steps
|
||||
|
||||
- Learn how skills are discovered and activated in [Agent Skills](./skills.md).
|
||||
- Explore the [memory management tutorial](./tutorials/memory-management.md) for
|
||||
the complementary explicit-memory and `GEMINI.md` workflows.
|
||||
- Review the experimental settings catalog in
|
||||
[Settings](./settings.md#experimental).
|
||||
@@ -0,0 +1,95 @@
|
||||
# Checkpointing
|
||||
|
||||
Gemini CLI includes a Checkpointing feature that automatically saves a snapshot
|
||||
of your project's state before any file modifications are made by AI-powered
|
||||
tools. This lets you safely experiment with and apply code changes, knowing you
|
||||
can instantly revert back to the state before the tool was run.
|
||||
|
||||
## How it works
|
||||
|
||||
When you approve a tool that modifies the file system (like `write_file` or
|
||||
`replace`), the CLI automatically creates a "checkpoint." This checkpoint
|
||||
includes:
|
||||
|
||||
1. **A Git snapshot:** A commit is made in a special, shadow Git repository
|
||||
located in your home directory (`~/.gemini/history/<project_hash>`). This
|
||||
snapshot captures the complete state of your project files at that moment.
|
||||
It does **not** interfere with your own project's Git repository.
|
||||
2. **Conversation history:** The entire conversation you've had with the agent
|
||||
up to that point is saved.
|
||||
3. **The tool call:** The specific tool call that was about to be executed is
|
||||
also stored.
|
||||
|
||||
If you want to undo the change or simply go back, you can use the `/restore`
|
||||
command. Restoring a checkpoint will:
|
||||
|
||||
- Revert all files in your project to the state captured in the snapshot.
|
||||
- Restore the conversation history in the CLI.
|
||||
- Re-propose the original tool call, allowing you to run it again, modify it, or
|
||||
simply ignore it.
|
||||
|
||||
All checkpoint data, including the Git snapshot and conversation history, is
|
||||
stored locally on your machine. The Git snapshot is stored in the shadow
|
||||
repository while the conversation history and tool calls are saved in a JSON
|
||||
file in your project's temporary directory, typically located at
|
||||
`~/.gemini/tmp/<project_hash>/checkpoints`.
|
||||
|
||||
## Enabling the feature
|
||||
|
||||
The Checkpointing feature is disabled by default. To enable it, you need to edit
|
||||
your `settings.json` file.
|
||||
|
||||
<!-- prettier-ignore -->
|
||||
> [!CAUTION]
|
||||
> The `--checkpointing` command-line flag was removed in version
|
||||
> 0.11.0. Checkpointing can now only be enabled through the `settings.json`
|
||||
> configuration file.
|
||||
|
||||
Add the following key to your `settings.json`:
|
||||
|
||||
```json
|
||||
{
|
||||
"general": {
|
||||
"checkpointing": {
|
||||
"enabled": true
|
||||
}
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
## Using the `/restore` command
|
||||
|
||||
Once enabled, checkpoints are created automatically. To manage them, you use the
|
||||
`/restore` command.
|
||||
|
||||
### List available checkpoints
|
||||
|
||||
To see a list of all saved checkpoints for the current project, simply run:
|
||||
|
||||
```
|
||||
/restore
|
||||
```
|
||||
|
||||
The CLI will display a list of available checkpoint files. These file names are
|
||||
typically composed of a timestamp, the name of the file being modified, and the
|
||||
name of the tool that was about to be run (for example,
|
||||
`2025-06-22T10-00-00_000Z-my-file.txt-write_file`).
|
||||
|
||||
### Restore a specific checkpoint
|
||||
|
||||
To restore your project to a specific checkpoint, use the checkpoint file from
|
||||
the list:
|
||||
|
||||
```
|
||||
/restore <checkpoint_file>
|
||||
```
|
||||
|
||||
For example:
|
||||
|
||||
```
|
||||
/restore 2025-06-22T10-00-00_000Z-my-file.txt-write_file
|
||||
```
|
||||
|
||||
After running the command, your files and conversation will be immediately
|
||||
restored to the state they were in when the checkpoint was created, and the
|
||||
original tool prompt will reappear.
|
||||
@@ -0,0 +1,134 @@
|
||||
# Gemini CLI cheatsheet
|
||||
|
||||
This page provides a reference for commonly used Gemini CLI commands, options,
|
||||
and parameters.
|
||||
|
||||
## CLI commands
|
||||
|
||||
| Command | Description | Example |
|
||||
| ---------------------------------- | ---------------------------------- | ------------------------------------------------------------ |
|
||||
| `gemini` | Start interactive REPL | `gemini` |
|
||||
| `gemini -p "query"` | Query non-interactively | `gemini -p "summarize README.md"` |
|
||||
| gemini "query" | Query and continue interactively | gemini "explain this project" |
|
||||
| `cat file \| gemini` | Process piped content | `cat logs.txt \| gemini`<br>`Get-Content logs.txt \| gemini` |
|
||||
| `gemini -i "query"` | Execute and continue interactively | `gemini -i "What is the purpose of this project?"` |
|
||||
| `gemini -r "latest"` | Continue most recent session | `gemini -r "latest"` |
|
||||
| `gemini -r "latest" "query"` | Continue session with a new prompt | `gemini -r "latest" "Check for type errors"` |
|
||||
| `gemini -r "<session-id>" "query"` | Resume session by ID | `gemini -r "abc123" "Finish this PR"` |
|
||||
| `gemini update` | Update to latest version | `gemini update` |
|
||||
| `gemini extensions` | Manage extensions | See [Extensions Management](#extensions-management) |
|
||||
| `gemini mcp` | Configure MCP servers | See [MCP Server Management](#mcp-server-management) |
|
||||
|
||||
### Positional arguments
|
||||
|
||||
| Argument | Type | Description |
|
||||
| -------- | ----------------- | ---------------------------------------------------------------------------------------------------------- |
|
||||
| `query` | string (variadic) | Positional prompt. Defaults to interactive mode in a TTY. Use `-p/--prompt` for non-interactive execution. |
|
||||
|
||||
## Interactive commands
|
||||
|
||||
These commands are available within the interactive REPL.
|
||||
|
||||
| Command | Description |
|
||||
| -------------------- | ----------------------------------------------- |
|
||||
| `/skills reload` | Reload discovered skills from disk |
|
||||
| `/agents reload` | Reload the agent registry |
|
||||
| `/commands list` | List available custom slash commands |
|
||||
| `/commands reload` | Reload custom slash commands |
|
||||
| `/memory reload` | Reload context files (for example, `GEMINI.md`) |
|
||||
| `/mcp reload` | Restart and reload MCP servers |
|
||||
| `/extensions reload` | Reload all active extensions |
|
||||
| `/help` | Show help for all commands |
|
||||
| `/quit` | Exit the interactive session |
|
||||
|
||||
## CLI Options
|
||||
|
||||
| Option | Alias | Type | Default | Description |
|
||||
| -------------------------------- | ----- | ------- | --------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
|
||||
| `--debug` | `-d` | boolean | `false` | Run in debug mode with verbose logging |
|
||||
| `--version` | `-v` | - | - | Show CLI version number and exit |
|
||||
| `--help` | `-h` | - | - | Show help information |
|
||||
| `--model` | `-m` | string | `auto` | Model to use. See [Model Selection](#model-selection) for available values. |
|
||||
| `--prompt` | `-p` | string | - | Prompt text. Appended to stdin input if provided. Forces non-interactive mode. |
|
||||
| `--prompt-interactive` | `-i` | string | - | Execute prompt and continue in interactive mode |
|
||||
| `--worktree` | `-w` | string | - | Start Gemini in a new git worktree. If no name is provided, one is generated automatically. Requires `experimental.worktrees: true` in settings. |
|
||||
| `--sandbox` | `-s` | boolean | `false` | Run in a sandboxed environment for safer execution |
|
||||
| `--skip-trust` | - | boolean | `false` | Trust the current workspace for this session, skipping the folder trust check. |
|
||||
| `--approval-mode` | - | string | `default` | Approval mode for tool execution. Choices: `default`, `auto_edit`, `yolo`, `plan` |
|
||||
| `--yolo` | `-y` | boolean | `false` | **Deprecated.** Auto-approve all actions. Use `--approval-mode=yolo` instead. |
|
||||
| `--experimental-acp` | - | boolean | - | Start in ACP (Agent Code Pilot) mode. **Experimental feature.** |
|
||||
| `--experimental-zed-integration` | - | boolean | - | Run in Zed editor integration mode. **Experimental feature.** |
|
||||
| `--allowed-mcp-server-names` | - | array | - | Allowed MCP server names (comma-separated or multiple flags) |
|
||||
| `--allowed-tools` | - | array | - | **Deprecated.** Use the [Policy Engine](../reference/policy-engine.md) instead. Tools that are allowed to run without confirmation (comma-separated or multiple flags) |
|
||||
| `--extensions` | `-e` | array | - | List of extensions to use. If not provided, all extensions are enabled (comma-separated or multiple flags) |
|
||||
| `--list-extensions` | `-l` | boolean | - | List all available extensions and exit |
|
||||
| `--resume` | `-r` | string | - | Resume a previous session. Use `"latest"` for most recent or index number (for example `--resume 5`) |
|
||||
| `--list-sessions` | - | boolean | - | List available sessions for the current project and exit |
|
||||
| `--delete-session` | - | string | - | Delete a session by index number (use `--list-sessions` to see available sessions) |
|
||||
| `--include-directories` | - | array | - | Additional directories to include in the workspace (comma-separated or multiple flags) |
|
||||
| `--screen-reader` | - | boolean | - | Enable screen reader mode for accessibility |
|
||||
| `--output-format` | `-o` | string | `text` | The format of the CLI output. Choices: `text`, `json`, `stream-json` |
|
||||
|
||||
## Model selection
|
||||
|
||||
The `--model` (or `-m`) flag lets you specify which Gemini model to use. You can
|
||||
use either model aliases (user-friendly names) or concrete model names.
|
||||
|
||||
### Model aliases
|
||||
|
||||
These are convenient shortcuts that map to specific models:
|
||||
|
||||
| Alias | Resolves To | Description |
|
||||
| ------------ | ------------------------------------------ | ------------------------------------------------------------------------------------------------------------------------- |
|
||||
| `auto` | `gemini-2.5-pro` or `gemini-3-pro-preview` | **Default.** Resolves to the preview model if preview features are enabled, otherwise resolves to the standard pro model. |
|
||||
| `pro` | `gemini-2.5-pro` or `gemini-3-pro-preview` | For complex reasoning tasks. Uses preview model if enabled. |
|
||||
| `flash` | `gemini-2.5-flash` | Fast, balanced model for most tasks. |
|
||||
| `flash-lite` | `gemini-2.5-flash-lite` | Fastest model for simple tasks. |
|
||||
|
||||
## Extensions management
|
||||
|
||||
| Command | Description | Example |
|
||||
| -------------------------------------------------- | -------------------------------------------- | ------------------------------------------------------------------------------ |
|
||||
| `gemini extensions install <source>` | Install extension from Git URL or local path | `gemini extensions install https://github.com/user/my-extension` |
|
||||
| `gemini extensions install <source> --ref <ref>` | Install from specific branch/tag/commit | `gemini extensions install https://github.com/user/my-extension --ref develop` |
|
||||
| `gemini extensions install <source> --auto-update` | Install with auto-update enabled | `gemini extensions install https://github.com/user/my-extension --auto-update` |
|
||||
| `gemini extensions uninstall <name>` | Uninstall one or more extensions | `gemini extensions uninstall my-extension` |
|
||||
| `gemini extensions list` | List all installed extensions | `gemini extensions list` |
|
||||
| `gemini extensions update <name>` | Update a specific extension | `gemini extensions update my-extension` |
|
||||
| `gemini extensions update --all` | Update all extensions | `gemini extensions update --all` |
|
||||
| `gemini extensions enable <name>` | Enable an extension | `gemini extensions enable my-extension` |
|
||||
| `gemini extensions disable <name>` | Disable an extension | `gemini extensions disable my-extension` |
|
||||
| `gemini extensions link <path>` | Link local extension for development | `gemini extensions link /path/to/extension` |
|
||||
| `gemini extensions new <path>` | Create new extension from template | `gemini extensions new ./my-extension` |
|
||||
| `gemini extensions validate <path>` | Validate extension structure | `gemini extensions validate ./my-extension` |
|
||||
|
||||
See [Extensions Documentation](../extensions/index.md) for more details.
|
||||
|
||||
## MCP server management
|
||||
|
||||
| Command | Description | Example |
|
||||
| ------------------------------------------------------------- | ------------------------------- | ---------------------------------------------------------------------------------------------------- |
|
||||
| `gemini mcp add <name> <command>` | Add stdio-based MCP server | `gemini mcp add github npx -y @modelcontextprotocol/server-github` |
|
||||
| `gemini mcp add <name> <url> --transport http` | Add HTTP-based MCP server | `gemini mcp add api-server http://localhost:3000 --transport http` |
|
||||
| `gemini mcp add <name> <command> --env KEY=value` | Add with environment variables | `gemini mcp add slack node server.js --env SLACK_TOKEN=xoxb-xxx` |
|
||||
| `gemini mcp add <name> <command> --scope user` | Add with user scope | `gemini mcp add db node db-server.js --scope user` |
|
||||
| `gemini mcp add <name> <command> --include-tools tool1,tool2` | Add with specific tools | `gemini mcp add github npx -y @modelcontextprotocol/server-github --include-tools list_repos,get_pr` |
|
||||
| `gemini mcp remove <name>` | Remove an MCP server | `gemini mcp remove github` |
|
||||
| `gemini mcp list` | List all configured MCP servers | `gemini mcp list` |
|
||||
|
||||
See [MCP Server Integration](../tools/mcp-server.md) for more details.
|
||||
|
||||
## Skills management
|
||||
|
||||
| Command | Description | Example |
|
||||
| -------------------------------- | ------------------------------------- | ------------------------------------------------- |
|
||||
| `gemini skills list` | List all discovered agent skills | `gemini skills list` |
|
||||
| `gemini skills install <source>` | Install skill from Git, path, or file | `gemini skills install https://github.com/u/repo` |
|
||||
| `gemini skills link <path>` | Link local agent skills via symlink | `gemini skills link /path/to/my-skills` |
|
||||
| `gemini skills uninstall <name>` | Uninstall an agent skill | `gemini skills uninstall my-skill` |
|
||||
| `gemini skills enable <name>` | Enable an agent skill | `gemini skills enable my-skill` |
|
||||
| `gemini skills disable <name>` | Disable an agent skill | `gemini skills disable my-skill` |
|
||||
| `gemini skills enable --all` | Enable all skills | `gemini skills enable --all` |
|
||||
| `gemini skills disable --all` | Disable all skills | `gemini skills disable --all` |
|
||||
|
||||
See [Agent Skills Documentation](./skills.md) for more details.
|
||||
@@ -0,0 +1,207 @@
|
||||
# Creating Agent Skills
|
||||
|
||||
Agent Skills let you extend Gemini CLI with specialized expertise, procedural
|
||||
workflows, and task-specific resources. This guide walks you through both
|
||||
automated and manual methods for creating and organizing your skills.
|
||||
|
||||
## Quickstart: Create a skill with a prompt
|
||||
|
||||
The fastest way to create a new skill is to use the built-in `skill-creator`.
|
||||
This meta-skill guides you through designing, scaffolding, and validating your
|
||||
expertise.
|
||||
|
||||
Simply ask Gemini CLI to create a skill for you:
|
||||
|
||||
> "Create a new skill called 'code-reviewer' that analyzes local files for
|
||||
> common errors and style violations."
|
||||
|
||||
Gemini will then:
|
||||
|
||||
1. Generate a new directory for your skill (for example, `my-new-skill/`).
|
||||
2. Create a `SKILL.md` file with the necessary YAML frontmatter (`name` and
|
||||
`description`).
|
||||
3. Create the standard resource directories: `scripts/`, `references/`, and
|
||||
`assets/`.
|
||||
|
||||
Once created, you can find your new skill in `.gemini/skills/code-reviewer/`.
|
||||
|
||||
## Manual creation
|
||||
|
||||
1. **Create a directory** for your skill (for example, `my-new-skill/`).
|
||||
2. **Create a `SKILL.md` file** inside the new directory.
|
||||
|
||||
### 1. Create the directory structure
|
||||
|
||||
The first step is to create the necessary folders for your skill and its
|
||||
scripts.
|
||||
|
||||
**macOS/Linux**
|
||||
|
||||
```bash
|
||||
mkdir -p .gemini/skills/code-reviewer/scripts
|
||||
```
|
||||
|
||||
**Windows (PowerShell)**
|
||||
|
||||
```powershell
|
||||
New-Item -ItemType Directory -Force -Path ".gemini\skills\code-reviewer\scripts"
|
||||
```
|
||||
|
||||
### 2. Define the skill (`SKILL.md`)
|
||||
|
||||
The `SKILL.md` file defines the skill's purpose and instructions for the agent.
|
||||
Create a file at `.gemini/skills/code-reviewer/SKILL.md`.
|
||||
|
||||
```markdown
|
||||
---
|
||||
name: code-reviewer
|
||||
description:
|
||||
Expertise in reviewing code changes for correctness, security, and style. Use
|
||||
when the user asks to "review" their code or a PR.
|
||||
---
|
||||
|
||||
# Code Reviewer Instructions
|
||||
|
||||
You act as a senior software engineer specialized in code quality. When this
|
||||
skill is active, you MUST:
|
||||
|
||||
1. **Analyze**: Review the provided code for logical errors, security
|
||||
vulnerabilities, and style violations.
|
||||
2. **Review**: Use the bundled `scripts/review.js` utility to perform an
|
||||
automated check.
|
||||
3. **Feedback**: Provide constructive feedback, clearly distinguishing between
|
||||
critical issues and minor improvements.
|
||||
```
|
||||
|
||||
### 3. Add the tool logic
|
||||
|
||||
Skills can bundle resources like scripts to perform deterministic tasks. Create
|
||||
a file at `.gemini/skills/code-reviewer/scripts/review.js`.
|
||||
|
||||
```javascript
|
||||
// .gemini/skills/code-reviewer/scripts/review.js
|
||||
const file = process.argv[2];
|
||||
|
||||
if (!file) {
|
||||
console.error('Usage: node review.js <file>');
|
||||
process.exit(1);
|
||||
}
|
||||
|
||||
console.log(`Reviewing ${file}...`);
|
||||
// Simple mock review logic
|
||||
setTimeout(() => {
|
||||
console.log(`Result: Success (No major issues found in ${file})`);
|
||||
}, 500);
|
||||
```
|
||||
|
||||
### 4. Test the skill
|
||||
|
||||
Gemini CLI automatically discovers skills in the `.gemini/skills` directory.
|
||||
|
||||
1. Start a new session and ask a question that triggers the skill's
|
||||
description: "Can you review index.js"
|
||||
2. Gemini identifies the request matches the `code-reviewer` description and
|
||||
asks for permission to activate it.
|
||||
3. Once you approve, Gemini executes the bundled script:
|
||||
`node .gemini/skills/code-reviewer/scripts/review.js index.js`
|
||||
|
||||
To determine whether your skill has been correctly loaded, run the command:
|
||||
|
||||
```bash
|
||||
/skills
|
||||
```
|
||||
|
||||
### 5. Optional: Share your skill
|
||||
|
||||
You can share your skills in several ways depending on your target audience.
|
||||
|
||||
- **Workspace skills**: Commit your skill to a `.gemini/skills/` directory in
|
||||
your project repository.
|
||||
- **Extensions**: Bundle your skill within a
|
||||
[Gemini CLI extension](../extensions/writing-extensions.md).
|
||||
- **Git repositories**: Share the skill directory as a standalone Git repo and
|
||||
install it using `gemini skills install <url>`.
|
||||
|
||||
---
|
||||
|
||||
## Core concepts
|
||||
|
||||
Now that you've built your first skill, let's explore the core components and
|
||||
workflows for developing more complex expertise.
|
||||
|
||||
### Skill structure
|
||||
|
||||
While a `SKILL.md` file is the only required component, we recommend the
|
||||
following structure for organizing your skill's resources.
|
||||
|
||||
```text
|
||||
my-skill/
|
||||
├── SKILL.md (Required) Instructions and metadata
|
||||
├── scripts/ (Optional) Executable scripts
|
||||
├── references/ (Optional) Static documentation
|
||||
└── assets/ (Optional) Templates and other resources
|
||||
```
|
||||
|
||||
When a skill is activated, the model is granted access to this entire directory.
|
||||
You can instruct the model to use the tools and files found within these
|
||||
folders.
|
||||
|
||||
### Metadata and triggers
|
||||
|
||||
The `SKILL.md` file uses YAML frontmatter for metadata.
|
||||
|
||||
- **`name`**: A unique identifier for the skill. This should match the directory
|
||||
name.
|
||||
- **`description`**: **CRITICAL.** This is how Gemini decides when to use the
|
||||
skill. Be specific about the tasks it handles and the keywords that should
|
||||
trigger it.
|
||||
|
||||
### Discovery tiers
|
||||
|
||||
Gemini CLI discovers skills from several locations, following a specific order
|
||||
of precedence (lowest to highest):
|
||||
|
||||
1. **Built-in Skills**: Included with Gemini CLI (pre-approved).
|
||||
2. **Extension Skills**: Bundled within [extensions](../extensions/).
|
||||
3. **User Skills**: `~/.gemini/skills/` or the `~/.agents/skills/` alias.
|
||||
4. **Workspace Skills**: `.gemini/skills/` or the `.agents/skills/` alias.
|
||||
|
||||
### Discovery aliases
|
||||
|
||||
You can use `.agents/skills` as an alternative to `.gemini/skills`. This alias
|
||||
is compatible with other AI agent tools following the
|
||||
[Agent Skills](https://agentskills.io) standard.
|
||||
|
||||
## Advanced development
|
||||
|
||||
Once you've built a basic skill, you can use specialized scripts and workflows
|
||||
to streamline your development process.
|
||||
|
||||
### Creation scripts
|
||||
|
||||
If you are developing a skill and want to use the same scripts the built-in
|
||||
tools use, you can find them in the core package. These scripts help automate
|
||||
the initialization, validation, and packaging of skills.
|
||||
|
||||
- **Initialize**: `node scripts/init_skill.cjs <name> --path <dir>`
|
||||
- **Validate**: `node scripts/validate_skill.cjs <path/to/skill>`
|
||||
- **Package**: `node scripts/package_skill.cjs <path/to/skill>` (Creates a
|
||||
`.skill` zip file)
|
||||
|
||||
### Linking for local development
|
||||
|
||||
If you are developing a skill in a separate directory, you can link it to your
|
||||
user skills directory for testing:
|
||||
|
||||
```bash
|
||||
gemini skills link .
|
||||
```
|
||||
|
||||
## Next steps
|
||||
|
||||
- [Skill best practices](./skills-best-practices.md): Learn strategies for
|
||||
building reliable and effective skills.
|
||||
- [Agent Skills overview](./skills.md): Deep dive into discovery tiers and the
|
||||
skill lifecycle.
|
||||
- [Get started with Agent Skills](./tutorials/skills-getting-started.md): A
|
||||
quick walkthrough of triggering and using skills.
|
||||
@@ -0,0 +1,331 @@
|
||||
# Custom commands
|
||||
|
||||
Custom commands let you save and reuse your favorite or most frequently used
|
||||
prompts as personal shortcuts within Gemini CLI. You can create commands that
|
||||
are specific to a single project or commands that are available globally across
|
||||
all your projects, streamlining your workflow and ensuring consistency.
|
||||
|
||||
## File locations and precedence
|
||||
|
||||
Gemini CLI discovers commands from two locations, loaded in a specific order:
|
||||
|
||||
1. **User commands (global):** Located in `~/.gemini/commands/`. These commands
|
||||
are available in any project you are working on.
|
||||
2. **Project commands (local):** Located in
|
||||
`<your-project-root>/.gemini/commands/`. These commands are specific to the
|
||||
current project and can be checked into version control to be shared with
|
||||
your team.
|
||||
|
||||
If a command in the project directory has the same name as a command in the user
|
||||
directory, the **project command will always be used.** This allows projects to
|
||||
override global commands with project-specific versions.
|
||||
|
||||
## Naming and namespacing
|
||||
|
||||
The name of a command is determined by its file path relative to its `commands`
|
||||
directory. Subdirectories are used to create namespaced commands, with the path
|
||||
separator (`/` or `\`) being converted to a colon (`:`).
|
||||
|
||||
- A file at `~/.gemini/commands/test.toml` becomes the command `/test`.
|
||||
- A file at `<project>/.gemini/commands/git/commit.toml` becomes the namespaced
|
||||
command `/git:commit`.
|
||||
|
||||
<!-- prettier-ignore -->
|
||||
> [!TIP]
|
||||
> After creating or modifying `.toml` command files, run
|
||||
> `/commands reload` to pick up your changes without restarting the CLI.
|
||||
> To see all available command files, run `/commands list`.
|
||||
|
||||
## TOML file format (v1)
|
||||
|
||||
Your command definition files must be written in the TOML format and use the
|
||||
`.toml` file extension.
|
||||
|
||||
### Required fields
|
||||
|
||||
- `prompt` (String): The prompt that will be sent to the Gemini model when the
|
||||
command is executed. This can be a single-line or multi-line string.
|
||||
|
||||
### Optional fields
|
||||
|
||||
- `description` (String): A brief, one-line description of what the command
|
||||
does. This text will be displayed next to your command in the `/help` menu.
|
||||
**If you omit this field, a generic description will be generated from the
|
||||
filename.**
|
||||
|
||||
## Handling arguments
|
||||
|
||||
Custom commands support two powerful methods for handling arguments. The CLI
|
||||
automatically chooses the correct method based on the content of your command's
|
||||
`prompt`.
|
||||
|
||||
### 1. Context-aware injection with `{{args}}`
|
||||
|
||||
If your `prompt` contains the special placeholder `{{args}}`, the CLI will
|
||||
replace that placeholder with the text the user typed after the command name.
|
||||
|
||||
The behavior of this injection depends on where it is used:
|
||||
|
||||
**A. Raw injection (outside shell commands)**
|
||||
|
||||
When used in the main body of the prompt, the arguments are injected exactly as
|
||||
the user typed them.
|
||||
|
||||
**Example (`git/fix.toml`):**
|
||||
|
||||
```toml
|
||||
# Invoked via: /git:fix "Button is misaligned"
|
||||
|
||||
description = "Generates a fix for a given issue."
|
||||
prompt = "Please provide a code fix for the issue described here: {{args}}."
|
||||
```
|
||||
|
||||
The model receives:
|
||||
`Please provide a code fix for the issue described here: "Button is misaligned".`
|
||||
|
||||
**B. Using arguments in shell commands (inside `!{...}` blocks)**
|
||||
|
||||
When you use `{{args}}` inside a shell injection block (`!{...}`), the arguments
|
||||
are automatically **shell-escaped** before replacement. This lets you safely
|
||||
pass arguments to shell commands, ensuring the resulting command is
|
||||
syntactically correct and secure while preventing command injection
|
||||
vulnerabilities.
|
||||
|
||||
**Example (`/grep-code.toml`):**
|
||||
|
||||
```toml
|
||||
prompt = """
|
||||
Please summarize the findings for the pattern `{{args}}`.
|
||||
|
||||
Search Results:
|
||||
!{grep -r {{args}} .}
|
||||
"""
|
||||
```
|
||||
|
||||
When you run `/grep-code It's complicated`:
|
||||
|
||||
1. The CLI sees `{{args}}` used both outside and inside `!{...}`.
|
||||
2. Outside: The first `{{args}}` is replaced raw with `It's complicated`.
|
||||
3. Inside: The second `{{args}}` is replaced with the escaped version (for
|
||||
example, on Linux: `"It\'s complicated"`).
|
||||
4. The command executed is `grep -r "It's complicated" .`.
|
||||
5. The CLI prompts you to confirm this exact, secure command before execution.
|
||||
6. The final prompt is sent.
|
||||
|
||||
### 2. Default argument handling
|
||||
|
||||
If your `prompt` does **not** contain the special placeholder `{{args}}`, the
|
||||
CLI uses a default behavior for handling arguments.
|
||||
|
||||
If you provide arguments to the command (for example, `/mycommand arg1`), the
|
||||
CLI will append the full command you typed to the end of the prompt, separated
|
||||
by two newlines. This allows the model to see both the original instructions and
|
||||
the specific arguments you just provided.
|
||||
|
||||
If you do **not** provide any arguments (for example, `/mycommand`), the prompt
|
||||
is sent to the model exactly as it is, with nothing appended.
|
||||
|
||||
**Example (`changelog.toml`):**
|
||||
|
||||
This example shows how to create a robust command by defining a role for the
|
||||
model, explaining where to find the user's input, and specifying the expected
|
||||
format and behavior.
|
||||
|
||||
```toml
|
||||
# In: <project>/.gemini/commands/changelog.toml
|
||||
# Invoked via: /changelog 1.2.0 added "Support for default argument parsing."
|
||||
|
||||
description = "Adds a new entry to the project's CHANGELOG.md file."
|
||||
prompt = """
|
||||
# Task: Update Changelog
|
||||
|
||||
You are an expert maintainer of this software project. A user has invoked a command to add a new entry to the changelog.
|
||||
|
||||
**The user's raw command is appended below your instructions.**
|
||||
|
||||
Your task is to parse the `<version>`, `<change_type>`, and `<message>` from their input and use the `write_file` tool to correctly update the `CHANGELOG.md` file.
|
||||
|
||||
## Expected Format
|
||||
The command follows this format: `/changelog <version> <type> <message>`
|
||||
- `<type>` must be one of: "added", "changed", "fixed", "removed".
|
||||
|
||||
## Behavior
|
||||
1. Read the `CHANGELOG.md` file.
|
||||
2. Find the section for the specified `<version>`.
|
||||
3. Add the `<message>` under the correct `<type>` heading.
|
||||
4. If the version or type section doesn't exist, create it.
|
||||
5. Adhere strictly to the "Keep a Changelog" format.
|
||||
"""
|
||||
```
|
||||
|
||||
When you run `/changelog 1.2.0 added "New feature"`, the final text sent to the
|
||||
model will be the original prompt followed by two newlines and the command you
|
||||
typed.
|
||||
|
||||
### 3. Executing shell commands with `!{...}`
|
||||
|
||||
You can make your commands dynamic by executing shell commands directly within
|
||||
your `prompt` and injecting their output. This is ideal for gathering context
|
||||
from your local environment, like reading file content or checking the status of
|
||||
Git.
|
||||
|
||||
When a custom command attempts to execute a shell command, Gemini CLI will now
|
||||
prompt you for confirmation before proceeding. This is a security measure to
|
||||
ensure that only intended commands can be run.
|
||||
|
||||
**How it works:**
|
||||
|
||||
1. **Inject commands:** Use the `!{...}` syntax.
|
||||
2. **Argument substitution:** If `{{args}}` is present inside the block, it is
|
||||
automatically shell-escaped (see
|
||||
[Context-Aware Injection](#1-context-aware-injection-with-args) above).
|
||||
3. **Robust parsing:** The parser correctly handles complex shell commands that
|
||||
include nested braces, such as JSON payloads. The content inside `!{...}`
|
||||
must have balanced braces (`{` and `}`). If you need to execute a command
|
||||
containing unbalanced braces, consider wrapping it in an external script
|
||||
file and calling the script within the `!{...}` block.
|
||||
4. **Security check and confirmation:** The CLI performs a security check on
|
||||
the final, resolved command (after arguments are escaped and substituted). A
|
||||
dialog will appear showing the exact command(s) to be executed.
|
||||
5. **Execution and error reporting:** The command is executed. If the command
|
||||
fails, the output injected into the prompt will include the error messages
|
||||
(stderr) followed by a status line, for example,
|
||||
`[Shell command exited with code 1]`. This helps the model understand the
|
||||
context of the failure.
|
||||
|
||||
**Example (`git/commit.toml`):**
|
||||
|
||||
This command gets the staged git diff and uses it to ask the model to write a
|
||||
commit message.
|
||||
|
||||
````toml
|
||||
# In: <project>/.gemini/commands/git/commit.toml
|
||||
# Invoked via: /git:commit
|
||||
|
||||
description = "Generates a Git commit message based on staged changes."
|
||||
|
||||
# The prompt uses !{...} to execute the command and inject its output.
|
||||
prompt = """
|
||||
Please generate a Conventional Commit message based on the following git diff:
|
||||
|
||||
```diff
|
||||
!{git diff --staged}
|
||||
```
|
||||
|
||||
"""
|
||||
|
||||
````
|
||||
|
||||
When you run `/git:commit`, the CLI first executes `git diff --staged`, then
|
||||
replaces `!{git diff --staged}` with the output of that command before sending
|
||||
the final, complete prompt to the model.
|
||||
|
||||
### 4. Injecting file content with `@{...}`
|
||||
|
||||
You can directly embed the content of a file or a directory listing into your
|
||||
prompt using the `@{...}` syntax. This is useful for creating commands that
|
||||
operate on specific files.
|
||||
|
||||
**How it works:**
|
||||
|
||||
- **File injection**: `@{path/to/file.txt}` is replaced by the content of
|
||||
`file.txt`.
|
||||
- **Multimodal support**: If the path points to a supported image (for example,
|
||||
PNG, JPEG), PDF, audio, or video file, it will be correctly encoded and
|
||||
injected as multimodal input. Other binary files are handled gracefully and
|
||||
skipped.
|
||||
- **Directory listing**: `@{path/to/dir}` is traversed and each file present
|
||||
within the directory and all subdirectories is inserted into the prompt. This
|
||||
respects `.gitignore` and `.geminiignore` if enabled.
|
||||
- **Workspace-aware**: The command searches for the path in the current
|
||||
directory and any other workspace directories. Absolute paths are allowed if
|
||||
they are within the workspace.
|
||||
- **Processing order**: File content injection with `@{...}` is processed
|
||||
_before_ shell commands (`!{...}`) and argument substitution (`{{args}}`).
|
||||
- **Parsing**: The parser requires the content inside `@{...}` (the path) to
|
||||
have balanced braces (`{` and `}`).
|
||||
|
||||
**Example (`review.toml`):**
|
||||
|
||||
This command injects the content of a _fixed_ best practices file
|
||||
(`docs/best-practices.md`) and uses the user's arguments to provide context for
|
||||
the review.
|
||||
|
||||
```toml
|
||||
# In: <project>/.gemini/commands/review.toml
|
||||
# Invoked via: /review FileCommandLoader.ts
|
||||
|
||||
description = "Reviews the provided context using a best practice guide."
|
||||
prompt = """
|
||||
You are an expert code reviewer.
|
||||
|
||||
Your task is to review {{args}}.
|
||||
|
||||
Use the following best practices when providing your review:
|
||||
|
||||
@{docs/best-practices.md}
|
||||
"""
|
||||
```
|
||||
|
||||
When you run `/review FileCommandLoader.ts`, the `@{docs/best-practices.md}`
|
||||
placeholder is replaced by the content of that file, and `{{args}}` is replaced
|
||||
by the text you provided, before the final prompt is sent to the model.
|
||||
|
||||
---
|
||||
|
||||
## Example: A "Pure Function" refactoring command
|
||||
|
||||
Let's create a global command that asks the model to refactor a piece of code.
|
||||
|
||||
**1. Create the file and directories:**
|
||||
|
||||
First, ensure the user commands directory exists, then create a `refactor`
|
||||
subdirectory for organization and the final TOML file.
|
||||
|
||||
**macOS/Linux**
|
||||
|
||||
```bash
|
||||
mkdir -p ~/.gemini/commands/refactor
|
||||
touch ~/.gemini/commands/refactor/pure.toml
|
||||
```
|
||||
|
||||
**Windows (PowerShell)**
|
||||
|
||||
```powershell
|
||||
New-Item -ItemType Directory -Force -Path "$env:USERPROFILE\.gemini\commands\refactor"
|
||||
New-Item -ItemType File -Force -Path "$env:USERPROFILE\.gemini\commands\refactor\pure.toml"
|
||||
```
|
||||
|
||||
**2. Add the content to the file:**
|
||||
|
||||
Open `~/.gemini/commands/refactor/pure.toml` in your editor and add the
|
||||
following content. We are including the optional `description` for best
|
||||
practice.
|
||||
|
||||
```toml
|
||||
# In: ~/.gemini/commands/refactor/pure.toml
|
||||
# This command will be invoked via: /refactor:pure
|
||||
|
||||
description = "Asks the model to refactor the current context into a pure function."
|
||||
|
||||
prompt = """
|
||||
Please analyze the code I've provided in the current context.
|
||||
Refactor it into a pure function.
|
||||
|
||||
Your response should include:
|
||||
1. The refactored, pure function code block.
|
||||
2. A brief explanation of the key changes you made and why they contribute to purity.
|
||||
"""
|
||||
```
|
||||
|
||||
**3. Run the command:**
|
||||
|
||||
That's it! You can now run your command in the CLI. First, you might add a file
|
||||
to the context, and then invoke your command:
|
||||
|
||||
```
|
||||
> @my-messy-function.js
|
||||
> /refactor:pure
|
||||
```
|
||||
|
||||
Gemini CLI will then execute the multi-line prompt defined in your TOML file.
|
||||
@@ -0,0 +1,613 @@
|
||||
# Gemini CLI for the enterprise
|
||||
|
||||
This document outlines configuration patterns and best practices for deploying
|
||||
and managing Gemini CLI in an enterprise environment. By leveraging system-level
|
||||
settings, administrators can enforce security policies, manage tool access, and
|
||||
ensure a consistent experience for all users.
|
||||
|
||||
<!-- prettier-ignore -->
|
||||
> [!WARNING]
|
||||
> The patterns described in this document are intended to help
|
||||
> administrators create a more controlled and secure environment for using
|
||||
> Gemini CLI. However, they should not be considered a foolproof security
|
||||
> boundary. A determined user with sufficient privileges on their local machine
|
||||
> may still be able to circumvent these configurations. These measures are
|
||||
> designed to prevent accidental misuse and enforce corporate policy in a
|
||||
> managed environment, not to defend against a malicious actor with local
|
||||
> administrative rights.
|
||||
|
||||
## Centralized configuration: The system settings file
|
||||
|
||||
The most powerful tools for enterprise administration are the system-wide
|
||||
settings files. These files allow you to define a baseline configuration
|
||||
(`system-defaults.json`) and a set of overrides (`settings.json`) that apply to
|
||||
all users on a machine. For a complete overview of configuration options, see
|
||||
the [Configuration documentation](../reference/configuration.md).
|
||||
|
||||
Settings are merged from four files. The precedence order for single-value
|
||||
settings (like `theme`) is:
|
||||
|
||||
1. System Defaults (`system-defaults.json`)
|
||||
2. User Settings (`~/.gemini/settings.json`)
|
||||
3. Workspace Settings (`<project>/.gemini/settings.json`)
|
||||
4. System Overrides (`settings.json`)
|
||||
|
||||
This means the System Overrides file has the final say. For settings that are
|
||||
arrays (`includeDirectories`) or objects (`mcpServers`), the values are merged.
|
||||
|
||||
**Example of merging and precedence:**
|
||||
|
||||
Here is how settings from different levels are combined.
|
||||
|
||||
- **System defaults `system-defaults.json`:**
|
||||
|
||||
```json
|
||||
{
|
||||
"ui": {
|
||||
"theme": "default-corporate-theme"
|
||||
},
|
||||
"context": {
|
||||
"includeDirectories": ["/etc/gemini-cli/common-context"]
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
- **User `settings.json` (`~/.gemini/settings.json`):**
|
||||
|
||||
```json
|
||||
{
|
||||
"ui": {
|
||||
"theme": "user-preferred-dark-theme"
|
||||
},
|
||||
"mcpServers": {
|
||||
"corp-server": {
|
||||
"command": "/usr/local/bin/corp-server-dev"
|
||||
},
|
||||
"user-tool": {
|
||||
"command": "npm start --prefix ~/tools/my-tool"
|
||||
}
|
||||
},
|
||||
"context": {
|
||||
"includeDirectories": ["~/gemini-context"]
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
- **Workspace `settings.json` (`<project>/.gemini/settings.json`):**
|
||||
|
||||
```json
|
||||
{
|
||||
"ui": {
|
||||
"theme": "project-specific-light-theme"
|
||||
},
|
||||
"mcpServers": {
|
||||
"project-tool": {
|
||||
"command": "npm start"
|
||||
}
|
||||
},
|
||||
"context": {
|
||||
"includeDirectories": ["./project-context"]
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
- **System overrides `settings.json`:**
|
||||
```json
|
||||
{
|
||||
"ui": {
|
||||
"theme": "system-enforced-theme"
|
||||
},
|
||||
"mcpServers": {
|
||||
"corp-server": {
|
||||
"command": "/usr/local/bin/corp-server-prod"
|
||||
}
|
||||
},
|
||||
"context": {
|
||||
"includeDirectories": ["/etc/gemini-cli/global-context"]
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
This results in the following merged configuration:
|
||||
|
||||
- **Final merged configuration:**
|
||||
```json
|
||||
{
|
||||
"ui": {
|
||||
"theme": "system-enforced-theme"
|
||||
},
|
||||
"mcpServers": {
|
||||
"corp-server": {
|
||||
"command": "/usr/local/bin/corp-server-prod"
|
||||
},
|
||||
"user-tool": {
|
||||
"command": "npm start --prefix ~/tools/my-tool"
|
||||
},
|
||||
"project-tool": {
|
||||
"command": "npm start"
|
||||
}
|
||||
},
|
||||
"context": {
|
||||
"includeDirectories": [
|
||||
"/etc/gemini-cli/common-context",
|
||||
"~/gemini-context",
|
||||
"./project-context",
|
||||
"/etc/gemini-cli/global-context"
|
||||
]
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
**Why:**
|
||||
|
||||
- **`theme`**: The value from the system overrides (`system-enforced-theme`) is
|
||||
used, as it has the highest precedence.
|
||||
- **`mcpServers`**: The objects are merged. The `corp-server` definition from
|
||||
the system overrides takes precedence over the user's definition. The unique
|
||||
`user-tool` and `project-tool` are included.
|
||||
- **`includeDirectories`**: The arrays are concatenated in the order of System
|
||||
Defaults, User, Workspace, and then System Overrides.
|
||||
|
||||
- **Location**:
|
||||
- **Linux**: `/etc/gemini-cli/settings.json`
|
||||
- **Windows**: `C:\ProgramData\gemini-cli\settings.json`
|
||||
- **macOS**: `/Library/Application Support/GeminiCli/settings.json`
|
||||
- The path can be overridden using the `GEMINI_CLI_SYSTEM_SETTINGS_PATH`
|
||||
environment variable.
|
||||
- **Control**: This file should be managed by system administrators and
|
||||
protected with appropriate file permissions to prevent unauthorized
|
||||
modification by users.
|
||||
|
||||
By using the system settings file, you can enforce the security and
|
||||
configuration patterns described below.
|
||||
|
||||
### Enforcing system settings with a wrapper script
|
||||
|
||||
While the `GEMINI_CLI_SYSTEM_SETTINGS_PATH` environment variable provides
|
||||
flexibility, a user could potentially override it to point to a different
|
||||
settings file, bypassing the centrally managed configuration. To mitigate this,
|
||||
enterprises can deploy a wrapper script or alias that ensures the environment
|
||||
variable is always set to the corporate-controlled path.
|
||||
|
||||
This approach ensures that no matter how the user calls the `gemini` command,
|
||||
the enterprise settings are always loaded with the highest precedence.
|
||||
|
||||
**Example wrapper script:**
|
||||
|
||||
Administrators can create a script named `gemini` and place it in a directory
|
||||
that appears earlier in the user's `PATH` than the actual Gemini CLI binary (for
|
||||
example, `/usr/local/bin/gemini`).
|
||||
|
||||
```bash
|
||||
#!/bin/bash
|
||||
|
||||
# Enforce the path to the corporate system settings file.
|
||||
# This ensures that the company's configuration is always applied.
|
||||
export GEMINI_CLI_SYSTEM_SETTINGS_PATH="/etc/gemini-cli/settings.json"
|
||||
|
||||
# Find the original gemini executable.
|
||||
# This is a simple example; a more robust solution might be needed
|
||||
# depending on the installation method.
|
||||
REAL_GEMINI_PATH=$(type -aP gemini | grep -v "^$(type -P gemini)$" | head -n 1)
|
||||
|
||||
if [ -z "$REAL_GEMINI_PATH" ]; then
|
||||
echo "Error: The original 'gemini' executable was not found." >&2
|
||||
exit 1
|
||||
fi
|
||||
|
||||
# Pass all arguments to the real Gemini CLI executable.
|
||||
exec "$REAL_GEMINI_PATH" "$@"
|
||||
```
|
||||
|
||||
By deploying this script, the `GEMINI_CLI_SYSTEM_SETTINGS_PATH` is set within
|
||||
the script's environment, and the `exec` command replaces the script process
|
||||
with the actual Gemini CLI process, which inherits the environment variable.
|
||||
This makes it significantly more difficult for a user to bypass the enforced
|
||||
settings.
|
||||
|
||||
**PowerShell Profile (Windows alternative):**
|
||||
|
||||
On Windows, administrators can achieve similar results by adding the environment
|
||||
variable to the system-wide or user-specific PowerShell profile:
|
||||
|
||||
```powershell
|
||||
Add-Content -Path $PROFILE -Value '$env:GEMINI_CLI_SYSTEM_SETTINGS_PATH="C:\ProgramData\gemini-cli\settings.json"'
|
||||
```
|
||||
|
||||
## User isolation in shared environments
|
||||
|
||||
In shared compute environments (like ML experiment runners or shared build
|
||||
servers), you can isolate Gemini CLI state by overriding the user's home
|
||||
directory.
|
||||
|
||||
By default, Gemini CLI stores configuration and history in `~/.gemini`. You can
|
||||
use the `GEMINI_CLI_HOME` environment variable to point to a unique directory
|
||||
for a specific user or job. The CLI will create a `.gemini` folder inside the
|
||||
specified path.
|
||||
|
||||
**macOS/Linux**
|
||||
|
||||
```bash
|
||||
# Isolate state for a specific job
|
||||
export GEMINI_CLI_HOME="/tmp/gemini-job-123"
|
||||
gemini
|
||||
```
|
||||
|
||||
**Windows (PowerShell)**
|
||||
|
||||
```powershell
|
||||
# Isolate state for a specific job
|
||||
$env:GEMINI_CLI_HOME="C:\temp\gemini-job-123"
|
||||
gemini
|
||||
```
|
||||
|
||||
## Restricting tool access
|
||||
|
||||
You can significantly enhance security by controlling which tools the Gemini
|
||||
model can use. This is achieved through the `tools.core` setting and the
|
||||
[Policy Engine](../reference/policy-engine.md). For a list of available tools,
|
||||
see the [Tools reference](../reference/tools.md).
|
||||
|
||||
### Allowlisting with `coreTools`
|
||||
|
||||
The most secure approach is to explicitly add the tools and commands that users
|
||||
are permitted to execute to an allowlist. This prevents the use of any tool not
|
||||
on the approved list.
|
||||
|
||||
**Example:** Allow only safe, read-only file operations and listing files.
|
||||
|
||||
```json
|
||||
{
|
||||
"tools": {
|
||||
"core": ["ReadFileTool", "GlobTool", "ShellTool(ls)"]
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
### Blocklisting with `excludeTools` (Deprecated)
|
||||
|
||||
> **Deprecated:** Use the [Policy Engine](../reference/policy-engine.md) for
|
||||
> more robust control.
|
||||
|
||||
Alternatively, you can add specific tools that are considered dangerous in your
|
||||
environment to a blocklist.
|
||||
|
||||
**Example:** Prevent the use of the shell tool for removing files.
|
||||
|
||||
```json
|
||||
{
|
||||
"tools": {
|
||||
"exclude": ["ShellTool(rm -rf)"]
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
<!-- prettier-ignore -->
|
||||
> [!WARNING]
|
||||
> Blocklisting with `excludeTools` is less secure than
|
||||
> allowlisting with `tools.core`, as it relies on blocking known-bad commands,
|
||||
> and clever users may find ways to bypass simple string-based blocks.
|
||||
> **Allowlisting is the recommended approach.**
|
||||
|
||||
### Disabling YOLO mode
|
||||
|
||||
To ensure that users cannot bypass the confirmation prompt for tool execution,
|
||||
you can disable YOLO mode at the policy level. This adds a critical layer of
|
||||
safety, as it prevents the model from executing tools without explicit user
|
||||
approval.
|
||||
|
||||
**Example:** Force all tool executions to require user confirmation.
|
||||
|
||||
```json
|
||||
{
|
||||
"security": {
|
||||
"disableYoloMode": true
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
This setting is highly recommended in an enterprise environment to prevent
|
||||
unintended tool execution.
|
||||
|
||||
## Managing custom tools (MCP servers)
|
||||
|
||||
If your organization uses custom tools via
|
||||
[Model-Context Protocol (MCP) servers](../tools/mcp-server.md), it is crucial to
|
||||
understand how server configurations are managed to apply security policies
|
||||
effectively.
|
||||
|
||||
### How MCP server configurations are merged
|
||||
|
||||
Gemini CLI loads `settings.json` files from three levels: System, Workspace, and
|
||||
User. When it comes to the `mcpServers` object, these configurations are
|
||||
**merged**:
|
||||
|
||||
1. **Merging:** The lists of servers from all three levels are combined into a
|
||||
single list.
|
||||
2. **Precedence:** If a server with the **same name** is defined at multiple
|
||||
levels (for example, a server named `corp-api` exists in both system and
|
||||
user settings), the definition from the highest-precedence level is used.
|
||||
The order of precedence is: **System > Workspace > User**.
|
||||
|
||||
This means a user **cannot** override the definition of a server that is already
|
||||
defined in the system-level settings. However, they **can** add new servers with
|
||||
unique names.
|
||||
|
||||
### Enforcing a catalog of tools
|
||||
|
||||
The security of your MCP tool ecosystem depends on a combination of defining the
|
||||
canonical servers and adding their names to an allowlist.
|
||||
|
||||
### Restricting tools within an MCP server
|
||||
|
||||
For even greater security, especially when dealing with third-party MCP servers,
|
||||
you can restrict which specific tools from a server are exposed to the model.
|
||||
This is done using the `includeTools` and `excludeTools` properties within a
|
||||
server's definition. This lets you use a subset of tools from a server without
|
||||
allowing potentially dangerous ones.
|
||||
|
||||
Following the principle of least privilege, it is highly recommended to use
|
||||
`includeTools` to create an allowlist of only the necessary tools.
|
||||
|
||||
**Example:** Only allow the `code-search` and `get-ticket-details` tools from a
|
||||
third-party MCP server, even if the server offers other tools like
|
||||
`delete-ticket`.
|
||||
|
||||
```json
|
||||
{
|
||||
"mcp": {
|
||||
"allowed": ["third-party-analyzer"]
|
||||
},
|
||||
"mcpServers": {
|
||||
"third-party-analyzer": {
|
||||
"command": "/usr/local/bin/start-3p-analyzer.sh",
|
||||
"includeTools": ["code-search", "get-ticket-details"]
|
||||
}
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
#### More secure pattern: Define and add to allowlist in system settings
|
||||
|
||||
To create a secure, centrally-managed catalog of tools, the system administrator
|
||||
**must** do both of the following in the system-level `settings.json` file:
|
||||
|
||||
1. **Define the full configuration** for every approved server in the
|
||||
`mcpServers` object. This ensures that even if a user defines a server with
|
||||
the same name, the secure system-level definition will take precedence.
|
||||
2. **Add the names** of those servers to an allowlist using the `mcp.allowed`
|
||||
setting. This is a critical security step that prevents users from running
|
||||
any servers that are not on this list. If this setting is omitted, the CLI
|
||||
will merge and allow any server defined by the user.
|
||||
|
||||
**Example system `settings.json`:**
|
||||
|
||||
1. Add the _names_ of all approved servers to an allowlist. This will prevent
|
||||
users from adding their own servers.
|
||||
|
||||
2. Provide the canonical _definition_ for each server on the allowlist.
|
||||
|
||||
```json
|
||||
{
|
||||
"mcp": {
|
||||
"allowed": ["corp-data-api", "source-code-analyzer"]
|
||||
},
|
||||
"mcpServers": {
|
||||
"corp-data-api": {
|
||||
"command": "/usr/local/bin/start-corp-api.sh",
|
||||
"timeout": 5000
|
||||
},
|
||||
"source-code-analyzer": {
|
||||
"command": "/usr/local/bin/start-analyzer.sh"
|
||||
}
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
This pattern is more secure because it uses both definition and an allowlist.
|
||||
Any server a user defines will either be overridden by the system definition (if
|
||||
it has the same name) or blocked because its name is not in the `mcp.allowed`
|
||||
list.
|
||||
|
||||
### Less secure pattern: Omitting the allowlist
|
||||
|
||||
If the administrator defines the `mcpServers` object but fails to also specify
|
||||
the `mcp.allowed` allowlist, users may add their own servers.
|
||||
|
||||
**Example system `settings.json`:**
|
||||
|
||||
This configuration defines servers but does not enforce the allowlist. The
|
||||
administrator has NOT included the "mcp.allowed" setting.
|
||||
|
||||
```json
|
||||
{
|
||||
"mcpServers": {
|
||||
"corp-data-api": {
|
||||
"command": "/usr/local/bin/start-corp-api.sh"
|
||||
}
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
In this scenario, a user can add their own server in their local
|
||||
`settings.json`. Because there is no `mcp.allowed` list to filter the merged
|
||||
results, the user's server will be added to the list of available tools and
|
||||
allowed to run.
|
||||
|
||||
## Enforcing sandboxing for security
|
||||
|
||||
To mitigate the risk of potentially harmful operations, you can enforce the use
|
||||
of sandboxing for all tool execution. The sandbox isolates tool execution in a
|
||||
containerized environment.
|
||||
|
||||
**Example:** Force all tool execution to happen within a Docker sandbox.
|
||||
|
||||
```json
|
||||
{
|
||||
"tools": {
|
||||
"sandbox": "docker"
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
You can also specify a custom, hardened Docker image for the sandbox by building
|
||||
a custom `sandbox.Dockerfile` as described in the
|
||||
[Sandboxing documentation](./sandbox.md).
|
||||
|
||||
## Controlling network access via proxy
|
||||
|
||||
In corporate environments with strict network policies, you can configure Gemini
|
||||
CLI to route all outbound traffic through a corporate proxy. This can be set via
|
||||
an environment variable, but it can also be enforced for custom tools via the
|
||||
`mcpServers` configuration.
|
||||
|
||||
**Example (for an MCP server):**
|
||||
|
||||
```json
|
||||
{
|
||||
"mcpServers": {
|
||||
"proxied-server": {
|
||||
"command": "node",
|
||||
"args": ["mcp_server.js"],
|
||||
"env": {
|
||||
"HTTP_PROXY": "http://proxy.example.com:8080",
|
||||
"HTTPS_PROXY": "http://proxy.example.com:8080"
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
## Telemetry and auditing
|
||||
|
||||
For auditing and monitoring purposes, you can configure Gemini CLI to send
|
||||
telemetry data to a central location. This lets you track tool usage and other
|
||||
events. For more information, see the [telemetry documentation](./telemetry.md).
|
||||
|
||||
**Example:** Enable telemetry and send it to a local OTLP collector. If
|
||||
`otlpEndpoint` is not specified, it defaults to `http://localhost:4317`.
|
||||
|
||||
```json
|
||||
{
|
||||
"telemetry": {
|
||||
"enabled": true,
|
||||
"target": "gcp",
|
||||
"logPrompts": false
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
<!-- prettier-ignore -->
|
||||
> [!NOTE]
|
||||
> Ensure that `logPrompts` is set to `false` in an enterprise setting to
|
||||
> avoid collecting potentially sensitive information from user prompts.
|
||||
|
||||
## Authentication
|
||||
|
||||
You can enforce a specific authentication method for all users by setting the
|
||||
`security.auth.enforcedType` in the system-level `settings.json` file. This
|
||||
prevents users from choosing a different authentication method. See the
|
||||
[Authentication docs](../get-started/authentication.mdx) for more details.
|
||||
|
||||
**Example:** Enforce the use of Google login for all users.
|
||||
|
||||
```json
|
||||
{
|
||||
"security": {
|
||||
"auth": {
|
||||
"enforcedType": "oauth-personal"
|
||||
}
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
If a user has a different authentication method configured, they will be
|
||||
prompted to switch to the enforced method. In non-interactive mode, the CLI will
|
||||
exit with an error if the configured authentication method does not match the
|
||||
enforced one.
|
||||
|
||||
### Restricting logins to corporate domains
|
||||
|
||||
For enterprises using Google Workspace, you can enforce that users only
|
||||
authenticate with their corporate Google accounts. This is a network-level
|
||||
control that is configured on a proxy server, not within Gemini CLI itself. It
|
||||
works by intercepting authentication requests to Google and adding a special
|
||||
HTTP header.
|
||||
|
||||
This policy prevents users from logging in with personal Gmail accounts or other
|
||||
non-corporate Google accounts.
|
||||
|
||||
For detailed instructions, see the Google Workspace Admin Help article on
|
||||
[blocking access to consumer accounts](https://support.google.com/a/answer/1668854?hl=en#zippy=%2Cstep-choose-a-web-proxy-server%2Cstep-configure-the-network-to-block-certain-accounts).
|
||||
|
||||
The general steps are as follows:
|
||||
|
||||
1. **Intercept Requests**: Configure your web proxy to intercept all requests
|
||||
to `google.com`.
|
||||
2. **Add HTTP Header**: For each intercepted request, add the
|
||||
`X-GoogApps-Allowed-Domains` HTTP header.
|
||||
3. **Specify Domains**: The value of the header should be a comma-separated
|
||||
list of your approved Google Workspace domain names.
|
||||
|
||||
**Example header:**
|
||||
|
||||
```
|
||||
X-GoogApps-Allowed-Domains: my-corporate-domain.com, secondary-domain.com
|
||||
```
|
||||
|
||||
When this header is present, Google's authentication service will only allow
|
||||
logins from accounts belonging to the specified domains.
|
||||
|
||||
## Putting it all together: example system `settings.json`
|
||||
|
||||
Here is an example of a system `settings.json` file that combines several of the
|
||||
patterns discussed above to create a secure, controlled environment for Gemini
|
||||
CLI.
|
||||
|
||||
```json
|
||||
{
|
||||
"tools": {
|
||||
"sandbox": "docker",
|
||||
"core": [
|
||||
"ReadFileTool",
|
||||
"GlobTool",
|
||||
"ShellTool(ls)",
|
||||
"ShellTool(cat)",
|
||||
"ShellTool(grep)"
|
||||
]
|
||||
},
|
||||
"mcp": {
|
||||
"allowed": ["corp-tools"]
|
||||
},
|
||||
"mcpServers": {
|
||||
"corp-tools": {
|
||||
"command": "/opt/gemini-tools/start.sh",
|
||||
"timeout": 5000
|
||||
}
|
||||
},
|
||||
"telemetry": {
|
||||
"enabled": true,
|
||||
"target": "gcp",
|
||||
"otlpEndpoint": "https://telemetry-prod.example.com:4317",
|
||||
"logPrompts": false
|
||||
},
|
||||
"advanced": {
|
||||
"bugCommand": {
|
||||
"urlTemplate": "https://servicedesk.example.com/new-ticket?title={title}&details={info}"
|
||||
}
|
||||
},
|
||||
"privacy": {
|
||||
"usageStatisticsEnabled": false
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
This configuration:
|
||||
|
||||
- Forces all tool execution into a Docker sandbox.
|
||||
- Strictly uses an allowlist for a small set of safe shell commands and file
|
||||
tools.
|
||||
- Defines and allows a single corporate MCP server for custom tools.
|
||||
- Enables telemetry for auditing, without logging prompt content.
|
||||
- Redirects the `/bug` command to an internal ticketing system.
|
||||
- Disables general usage statistics collection.
|
||||
@@ -0,0 +1,71 @@
|
||||
# Ignoring files
|
||||
|
||||
This document provides an overview of the Gemini Ignore (`.geminiignore`)
|
||||
feature of Gemini CLI.
|
||||
|
||||
Gemini CLI includes the ability to automatically ignore files, similar to
|
||||
`.gitignore` (used by Git) and `.aiexclude` (used by Gemini Code Assist). Adding
|
||||
paths to your `.geminiignore` file will exclude them from tools that support
|
||||
this feature, although they will still be visible to other services (such as
|
||||
Git).
|
||||
|
||||
## How it works
|
||||
|
||||
When you add a path to your `.geminiignore` file, tools that respect this file
|
||||
will exclude matching files and directories from their operations. For example,
|
||||
when you use the `@` command to share files, any paths in your `.geminiignore`
|
||||
file will be automatically excluded.
|
||||
|
||||
For the most part, `.geminiignore` follows the conventions of `.gitignore`
|
||||
files:
|
||||
|
||||
- Blank lines and lines starting with `#` are ignored.
|
||||
- Standard glob patterns are supported (such as `*`, `?`, and `[]`).
|
||||
- Putting a `/` at the end will only match directories.
|
||||
- Putting a `/` at the beginning anchors the path relative to the
|
||||
`.geminiignore` file.
|
||||
- `!` negates a pattern.
|
||||
|
||||
You can update your `.geminiignore` file at any time. To apply the changes, you
|
||||
must restart your Gemini CLI session.
|
||||
|
||||
## How to use `.geminiignore`
|
||||
|
||||
To enable `.geminiignore`:
|
||||
|
||||
1. Create a file named `.geminiignore` in the root of your project directory.
|
||||
|
||||
To add a file or directory to `.geminiignore`:
|
||||
|
||||
1. Open your `.geminiignore` file.
|
||||
2. Add the path or file you want to ignore, for example: `/archive/` or
|
||||
`apikeys.txt`.
|
||||
|
||||
### `.geminiignore` examples
|
||||
|
||||
You can use `.geminiignore` to ignore directories and files:
|
||||
|
||||
```
|
||||
# Exclude your /packages/ directory and all subdirectories
|
||||
/packages/
|
||||
|
||||
# Exclude your apikeys.txt file
|
||||
apikeys.txt
|
||||
```
|
||||
|
||||
You can use wildcards in your `.geminiignore` file with `*`:
|
||||
|
||||
```
|
||||
# Exclude all .md files
|
||||
*.md
|
||||
```
|
||||
|
||||
Finally, you can exclude files and directories from exclusion with `!`:
|
||||
|
||||
```
|
||||
# Exclude all .md files except README.md
|
||||
*.md
|
||||
!README.md
|
||||
```
|
||||
|
||||
To remove paths from your `.geminiignore` file, delete the relevant lines.
|
||||
@@ -0,0 +1,116 @@
|
||||
# Provide context with GEMINI.md files
|
||||
|
||||
Context files, which use the default name `GEMINI.md`, are a powerful feature
|
||||
for providing instructional context to the Gemini model. You can use these files
|
||||
to give project-specific instructions, define a persona, or provide coding style
|
||||
guides to make the AI's responses more accurate and tailored to your needs.
|
||||
|
||||
Instead of repeating instructions in every prompt, you can define them once in a
|
||||
context file.
|
||||
|
||||
## Understand the context hierarchy
|
||||
|
||||
The CLI uses a hierarchical system to source context. It loads various context
|
||||
files from several locations, concatenates the contents of all found files, and
|
||||
sends them to the model with every prompt. The CLI loads files in the following
|
||||
order:
|
||||
|
||||
1. **Global context file:**
|
||||
|
||||
- **Location:** `~/.gemini/GEMINI.md` (in your user home directory).
|
||||
- **Scope:** Provides default instructions for all your projects.
|
||||
|
||||
2. **Environment and workspace context files:**
|
||||
|
||||
- **Location:** The CLI searches for `GEMINI.md` files in your configured
|
||||
workspace directories and their parent directories.
|
||||
- **Scope:** Provides context relevant to the projects you are currently
|
||||
working on.
|
||||
|
||||
3. **Just-in-time (JIT) context files:**
|
||||
- **Location:** When a tool accesses a file or directory, the CLI
|
||||
automatically scans for `GEMINI.md` files in that directory and its
|
||||
ancestors up to a trusted root.
|
||||
- **Scope:** Lets the model discover highly specific instructions for
|
||||
particular components only when they are needed.
|
||||
|
||||
The CLI footer displays the number of loaded context files, which gives you a
|
||||
quick visual cue of the active instructional context.
|
||||
|
||||
### Example `GEMINI.md` file
|
||||
|
||||
Here is an example of what you can include in a `GEMINI.md` file at the root of
|
||||
a TypeScript project:
|
||||
|
||||
```markdown
|
||||
# Project: My TypeScript Library
|
||||
|
||||
## General Instructions
|
||||
|
||||
- When you generate new TypeScript code, follow the existing coding style.
|
||||
- Ensure all new functions and classes have JSDoc comments.
|
||||
- Prefer functional programming paradigms where appropriate.
|
||||
|
||||
## Coding Style
|
||||
|
||||
- Use 2 spaces for indentation.
|
||||
- Prefix interface names with `I` (for example, `IUserService`).
|
||||
- Always use strict equality (`===` and `!==`).
|
||||
```
|
||||
|
||||
## Manage context with the `/memory` command
|
||||
|
||||
You can interact with the loaded context files by using the `/memory` command.
|
||||
|
||||
- **`/memory show`**: Displays the full, concatenated content of the current
|
||||
hierarchical memory. This lets you inspect the exact instructional context
|
||||
being provided to the model.
|
||||
- **`/memory reload`**: Forces a re-scan and reload of all `GEMINI.md` files
|
||||
from all configured locations.
|
||||
|
||||
## Modularize context with imports
|
||||
|
||||
You can break down large `GEMINI.md` files into smaller, more manageable
|
||||
components by importing content from other files using the `@file.md` syntax.
|
||||
This feature supports both relative and absolute paths.
|
||||
|
||||
**Example `GEMINI.md` with imports:**
|
||||
|
||||
```markdown
|
||||
# Main GEMINI.md file
|
||||
|
||||
This is the main content.
|
||||
|
||||
@./components/instructions.md
|
||||
|
||||
More content here.
|
||||
|
||||
@../shared/style-guide.md
|
||||
```
|
||||
|
||||
For more details, see the [Memory Import Processor](../reference/memport.md)
|
||||
documentation.
|
||||
|
||||
## Customize the context file name
|
||||
|
||||
While `GEMINI.md` is the default filename, you can configure this in your
|
||||
`settings.json` file. To specify a different name or a list of names, use the
|
||||
`context.fileName` property.
|
||||
|
||||
**Example `settings.json`:**
|
||||
|
||||
```json
|
||||
{
|
||||
"context": {
|
||||
"fileName": ["AGENTS.md", "CONTEXT.md", "GEMINI.md"]
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
## Next steps
|
||||
|
||||
- Learn about [Ignoring files](./gemini-ignore.md) to exclude content from the
|
||||
context system.
|
||||
- Explore the [Memory tool](../tools/memory.md) to save persistent memories.
|
||||
- See how to use [Custom commands](./custom-commands.md) to automate common
|
||||
prompts.
|
||||
@@ -0,0 +1,212 @@
|
||||
# Advanced Model Configuration
|
||||
|
||||
This guide details the Model Configuration system within Gemini CLI. Designed
|
||||
for researchers, AI quality engineers, and advanced users, this system provides
|
||||
a rigorous framework for managing generative model hyperparameters and
|
||||
behaviors.
|
||||
|
||||
<!-- prettier-ignore -->
|
||||
> [!WARNING]
|
||||
> This is a power-user feature. Configuration values are passed
|
||||
> directly to the model provider with minimal validation. Incorrect settings
|
||||
> (for example, incompatible parameter combinations) may result in runtime
|
||||
> errors from the API.
|
||||
|
||||
## 1. System Overview
|
||||
|
||||
The Model Configuration system (`ModelConfigService`) enables deterministic
|
||||
control over model generation. It decouples the requested model identifier (for
|
||||
example, a CLI flag or agent request) from the underlying API configuration.
|
||||
This allows for:
|
||||
|
||||
- **Precise Hyperparameter Tuning**: Direct control over `temperature`, `topP`,
|
||||
`thinkingBudget`, and other SDK-level parameters.
|
||||
- **Environment-Specific Behavior**: Distinct configurations for different
|
||||
operating contexts (for example, testing vs. production).
|
||||
- **Agent-Scoped Customization**: Applying specific settings only when a
|
||||
particular agent is active.
|
||||
|
||||
The system operates on two core primitives: **Aliases** and **Overrides**.
|
||||
|
||||
## 2. Configuration Primitives
|
||||
|
||||
These settings are located under the `modelConfigs` key in your configuration
|
||||
file.
|
||||
|
||||
### Aliases (`customAliases`)
|
||||
|
||||
Aliases are named, reusable configuration presets. Users should define their own
|
||||
aliases (or override system defaults) in the `customAliases` map.
|
||||
|
||||
- **Inheritance**: An alias can `extends` another alias (including system
|
||||
defaults like `chat-base`), inheriting its `modelConfig`. Child aliases can
|
||||
overwrite or augment inherited settings.
|
||||
- **Abstract Aliases**: An alias is not required to specify a concrete `model`
|
||||
if it serves purely as a base for other aliases.
|
||||
|
||||
**Example Hierarchy**:
|
||||
|
||||
```json
|
||||
"modelConfigs": {
|
||||
"customAliases": {
|
||||
"base": {
|
||||
"modelConfig": {
|
||||
"generateContentConfig": { "temperature": 0.0 }
|
||||
}
|
||||
},
|
||||
"chat-base": {
|
||||
"extends": "base",
|
||||
"modelConfig": {
|
||||
"generateContentConfig": { "temperature": 0.7 }
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
### Overrides (`overrides`)
|
||||
|
||||
Overrides are conditional rules that inject configuration based on the runtime
|
||||
context. They are evaluated dynamically for each model request.
|
||||
|
||||
- **Match Criteria**: Overrides apply when the request context matches the
|
||||
specified `match` properties.
|
||||
- `model`: Matches the requested model name or alias.
|
||||
- `overrideScope`: Matches the distinct scope of the request (typically the
|
||||
agent name, for example, `codebaseInvestigator`).
|
||||
|
||||
**Example Override**:
|
||||
|
||||
```json
|
||||
"modelConfigs": {
|
||||
"overrides": [
|
||||
{
|
||||
"match": {
|
||||
"overrideScope": "codebaseInvestigator"
|
||||
},
|
||||
"modelConfig": {
|
||||
"generateContentConfig": { "temperature": 0.1 }
|
||||
}
|
||||
}
|
||||
]
|
||||
}
|
||||
```
|
||||
|
||||
## 3. Resolution Strategy
|
||||
|
||||
The `ModelConfigService` resolves the final configuration through a two-step
|
||||
process:
|
||||
|
||||
### Step 1: Alias Resolution
|
||||
|
||||
The requested model string is looked up in the merged map of system `aliases`
|
||||
and user `customAliases`.
|
||||
|
||||
1. If found, the system recursively resolves the `extends` chain.
|
||||
2. Settings are merged from parent to child (child wins).
|
||||
3. This results in a base `ResolvedModelConfig`.
|
||||
4. If not found, the requested string is treated as the raw model name.
|
||||
|
||||
### Step 2: Override Application
|
||||
|
||||
The system evaluates the `overrides` list against the request context (`model`
|
||||
and `overrideScope`).
|
||||
|
||||
1. **Filtering**: All matching overrides are identified.
|
||||
2. **Sorting**: Matches are prioritized by **specificity** (the number of
|
||||
matched keys in the `match` object).
|
||||
- Specific matches (for example, `model` + `overrideScope`) override broad
|
||||
matches (for example, `model` only).
|
||||
- Tie-breaking: If specificity is equal, the order of definition in the
|
||||
`overrides` array is preserved (last one wins).
|
||||
3. **Merging**: The configurations from the sorted overrides are merged
|
||||
sequentially onto the base configuration.
|
||||
|
||||
## 4. Configuration Reference
|
||||
|
||||
The configuration follows the `ModelConfigServiceConfig` interface.
|
||||
|
||||
### `ModelConfig` Object
|
||||
|
||||
Defines the actual parameters for the model.
|
||||
|
||||
| Property | Type | Description |
|
||||
| :---------------------- | :------- | :------------------------------------------------------------------------ |
|
||||
| `model` | `string` | The identifier of the model to be called (for example, `gemini-2.5-pro`). |
|
||||
| `generateContentConfig` | `object` | The configuration object passed to the `@google/genai` SDK. |
|
||||
|
||||
### `GenerateContentConfig` (Common Parameters)
|
||||
|
||||
Directly maps to the SDK's `GenerateContentConfig`. Common parameters include:
|
||||
|
||||
- **`temperature`**: (`number`) Controls output randomness. Lower values (0.0)
|
||||
are deterministic; higher values (>0.7) are creative.
|
||||
- **`topP`**: (`number`) Nucleus sampling probability.
|
||||
- **`maxOutputTokens`**: (`number`) Limit on generated response length.
|
||||
- **`thinkingConfig`**: (`object`) Configuration for models with reasoning
|
||||
capabilities (for example, `thinkingBudget`, `includeThoughts`).
|
||||
|
||||
## 5. Practical Examples
|
||||
|
||||
### Defining a Deterministic Baseline
|
||||
|
||||
Create an alias for tasks requiring high precision, extending the standard chat
|
||||
configuration but enforcing zero temperature.
|
||||
|
||||
```json
|
||||
"modelConfigs": {
|
||||
"customAliases": {
|
||||
"precise-mode": {
|
||||
"extends": "chat-base",
|
||||
"modelConfig": {
|
||||
"generateContentConfig": {
|
||||
"temperature": 0.0,
|
||||
"topP": 1.0
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
### Agent-Specific Parameter Injection
|
||||
|
||||
Enforce extended thinking budgets for a specific agent without altering the
|
||||
global default, for example for the `codebaseInvestigator`.
|
||||
|
||||
```json
|
||||
"modelConfigs": {
|
||||
"overrides": [
|
||||
{
|
||||
"match": {
|
||||
"overrideScope": "codebaseInvestigator"
|
||||
},
|
||||
"modelConfig": {
|
||||
"generateContentConfig": {
|
||||
"thinkingConfig": { "thinkingBudget": 4096 }
|
||||
}
|
||||
}
|
||||
}
|
||||
]
|
||||
}
|
||||
```
|
||||
|
||||
### Experimental Model Evaluation
|
||||
|
||||
Route traffic for a specific alias to a preview model for A/B testing, without
|
||||
changing client code.
|
||||
|
||||
```json
|
||||
"modelConfigs": {
|
||||
"overrides": [
|
||||
{
|
||||
"match": {
|
||||
"model": "gemini-2.5-pro"
|
||||
},
|
||||
"modelConfig": {
|
||||
"model": "gemini-2.5-pro-experimental-001"
|
||||
}
|
||||
}
|
||||
]
|
||||
}
|
||||
```
|
||||
@@ -0,0 +1,107 @@
|
||||
# Git Worktrees (experimental)
|
||||
|
||||
When working on multiple tasks at once, you can use Git worktrees to give each
|
||||
Gemini session its own copy of the codebase. Git worktrees create separate
|
||||
working directories that each have their own files and branch while sharing the
|
||||
same repository history. This prevents changes in one session from colliding
|
||||
with another.
|
||||
|
||||
Learn more about [session management](./session-management.md).
|
||||
|
||||
<!-- prettier-ignore -->
|
||||
> [!NOTE]
|
||||
> This is an experimental feature currently under active development. Your
|
||||
> feedback is invaluable as we refine this feature. If you have ideas,
|
||||
> suggestions, or encounter issues:
|
||||
>
|
||||
> - [Open an issue](https://github.com/google-gemini/gemini-cli/issues/new?template=bug_report.yml) on GitHub.
|
||||
> - Use the **/bug** command within Gemini CLI to file an issue.
|
||||
|
||||
Learn more in the official Git worktree
|
||||
[documentation](https://git-scm.com/docs/git-worktree).
|
||||
|
||||
## How to enable Git worktrees
|
||||
|
||||
Git worktrees are an experimental feature. You must enable them in your settings
|
||||
using the `/settings` command or by manually editing your `settings.json` file.
|
||||
|
||||
1. Use the `/settings` command.
|
||||
2. Search for and set **Enable Git Worktrees** to `true`.
|
||||
|
||||
Alternatively, add the following to your `settings.json`:
|
||||
|
||||
```json
|
||||
{
|
||||
"experimental": {
|
||||
"worktrees": true
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
## How to use Git worktrees
|
||||
|
||||
Use the `--worktree` (`-w`) flag to create an isolated worktree and start Gemini
|
||||
CLI in it.
|
||||
|
||||
- **Start with a specific name:** The value you pass becomes both the directory
|
||||
name (within `.gemini/worktrees/`) and the branch name.
|
||||
|
||||
```bash
|
||||
gemini --worktree feature-search
|
||||
```
|
||||
|
||||
- **Start with a random name:** If you omit the name, Gemini generates a random
|
||||
one automatically (for example, `worktree-a1b2c3d4`).
|
||||
|
||||
```bash
|
||||
gemini --worktree
|
||||
```
|
||||
|
||||
<!-- prettier-ignore -->
|
||||
> [!NOTE]
|
||||
> Remember to initialize your development environment in each new
|
||||
> worktree according to your project's setup. Depending on your stack, this
|
||||
> might include running dependency installation (`npm install`, `yarn`), setting
|
||||
> up virtual environments, or following your project's standard build process.
|
||||
|
||||
## How to exit a Git worktree session
|
||||
|
||||
When you exit a worktree session (using `/quit` or `Ctrl+C`), Gemini leaves the
|
||||
worktree intact so your work is not lost. This includes your uncommitted changes
|
||||
(modified files, staged changes, or untracked files) and any new commits you
|
||||
have made.
|
||||
|
||||
Gemini prioritizes a fast and safe exit: it **does not automatically delete**
|
||||
your worktree or branch. You are responsible for cleaning up your worktrees
|
||||
manually once you are finished with them.
|
||||
|
||||
When you exit, Gemini displays instructions on how to resume your work or how to
|
||||
manually remove the worktree if you no longer need it.
|
||||
|
||||
## Resuming work in a Git worktree
|
||||
|
||||
To resume a session in a worktree, navigate to the worktree directory and start
|
||||
Gemini CLI with the `--resume` flag and the session ID:
|
||||
|
||||
```bash
|
||||
cd .gemini/worktrees/feature-search
|
||||
gemini --resume <session_id>
|
||||
```
|
||||
|
||||
## Managing Git worktrees manually
|
||||
|
||||
For more control over worktree location and branch configuration, or to clean up
|
||||
a preserved worktree, you can use Git directly:
|
||||
|
||||
- **Clean up a preserved Git worktree:**
|
||||
```bash
|
||||
git worktree remove .gemini/worktrees/feature-search --force
|
||||
git branch -D worktree-feature-search
|
||||
```
|
||||
- **Create a Git worktree manually:**
|
||||
```bash
|
||||
git worktree add ../project-feature-search -b feature-search
|
||||
cd ../project-feature-search && gemini
|
||||
```
|
||||
|
||||
[Open an issue]: https://github.com/google-gemini/gemini-cli/issues
|
||||
@@ -0,0 +1,51 @@
|
||||
# Headless mode reference
|
||||
|
||||
Headless mode provides a programmatic interface to Gemini CLI, returning
|
||||
structured text or JSON output without an interactive terminal UI.
|
||||
|
||||
## Technical reference
|
||||
|
||||
Headless mode is triggered when the CLI is run in a non-TTY environment or when
|
||||
providing a query with the `-p` (or `--prompt`) flag.
|
||||
|
||||
### Output formats
|
||||
|
||||
You can specify the output format using the `--output-format` flag.
|
||||
|
||||
#### JSON output
|
||||
|
||||
Returns a single JSON object containing the response and usage statistics.
|
||||
|
||||
- **Schema:**
|
||||
- `response`: (string) The model's final answer.
|
||||
- `stats`: (object) Token usage and API latency metrics.
|
||||
- `error`: (object, optional) Error details if the request failed.
|
||||
|
||||
#### Streaming JSON output
|
||||
|
||||
Returns a stream of newline-delimited JSON (JSONL) events.
|
||||
|
||||
- **Event types:**
|
||||
- `init`: Session metadata (session ID, model).
|
||||
- `message`: User and assistant message chunks.
|
||||
- `tool_use`: Tool call requests with arguments.
|
||||
- `tool_result`: Output from executed tools.
|
||||
- `error`: Non-fatal warnings and system errors.
|
||||
- `result`: Final outcome with aggregated statistics and per-model token usage
|
||||
breakdowns.
|
||||
|
||||
## Exit codes
|
||||
|
||||
The CLI returns standard exit codes to indicate the result of the headless
|
||||
execution:
|
||||
|
||||
- `0`: Success.
|
||||
- `1`: General error or API failure.
|
||||
- `42`: Input error (invalid prompt or arguments).
|
||||
- `53`: Turn limit exceeded.
|
||||
|
||||
## Next steps
|
||||
|
||||
- Follow the [Automation tutorial](./tutorials/automation.md) for practical
|
||||
scripting examples.
|
||||
- See the [CLI reference](./cli-reference.md) for all available flags.
|
||||
@@ -0,0 +1,59 @@
|
||||
# Model routing
|
||||
|
||||
Gemini CLI includes a model routing feature that automatically switches to a
|
||||
fallback model in case of a model failure. This feature is enabled by default
|
||||
and provides resilience when the primary model is unavailable.
|
||||
|
||||
## How it works
|
||||
|
||||
Model routing is managed by the `ModelAvailabilityService`, which monitors model
|
||||
health and automatically routes requests to available models based on defined
|
||||
policies.
|
||||
|
||||
1. **Model failure:** If the currently selected model fails (for example, due
|
||||
to quota or server errors), the CLI will initiate the fallback process.
|
||||
|
||||
2. **User consent:** Depending on the failure and the model's policy, the CLI
|
||||
may prompt you to switch to a fallback model (by default always prompts
|
||||
you).
|
||||
|
||||
Some internal utility calls (such as prompt completion and classification)
|
||||
use a silent fallback chain for `gemini-2.5-flash-lite` and will fall back
|
||||
to `gemini-2.5-flash` and `gemini-2.5-pro` without prompting or changing the
|
||||
configured model.
|
||||
|
||||
3. **Model switch:** If approved, or if the policy allows for silent fallback,
|
||||
the CLI will use an available fallback model for the current turn or the
|
||||
remainder of the session.
|
||||
|
||||
### Local Model Routing (Experimental)
|
||||
|
||||
Gemini CLI supports using a local model for routing decisions. When configured,
|
||||
Gemini CLI will use a locally-running **Gemma** model to make routing decisions
|
||||
(instead of sending routing decisions to a hosted model). This feature can help
|
||||
reduce costs associated with hosted model usage while offering similar routing
|
||||
decision latency and quality.
|
||||
|
||||
The easiest way to set this up is using the automated `gemini gemma setup`
|
||||
command.
|
||||
|
||||
For more details on how to configure local model routing, see
|
||||
[`gemini gemma` — Local Model Routing Setup](../core/gemma-setup.md).
|
||||
|
||||
### Model selection precedence
|
||||
|
||||
The model used by Gemini CLI is determined by the following order of precedence:
|
||||
|
||||
1. **`--model` command-line flag:** A model specified with the `--model` flag
|
||||
when launching the CLI will always be used.
|
||||
2. **`GEMINI_MODEL` environment variable:** If the `--model` flag is not used,
|
||||
the CLI will use the model specified in the `GEMINI_MODEL` environment
|
||||
variable.
|
||||
3. **`model.name` in `settings.json`:** If neither of the above are set, the
|
||||
model specified in the `model.name` property of your `settings.json` file
|
||||
will be used.
|
||||
4. **Local model (experimental):** If the Gemma local model router is enabled
|
||||
in your `settings.json` file, the CLI will use the local Gemma model
|
||||
(instead of Gemini models) to route the request to an appropriate model.
|
||||
5. **Default model:** If none of the above are set, the default model will be
|
||||
used. The default model is `auto`
|
||||
@@ -0,0 +1,80 @@
|
||||
# Model steering (experimental)
|
||||
|
||||
Model steering lets you provide real-time guidance and feedback to Gemini CLI
|
||||
while it is actively executing a task. This lets you correct course, add missing
|
||||
context, or skip unnecessary steps without having to stop and restart the agent.
|
||||
|
||||
<!-- prettier-ignore -->
|
||||
> [!NOTE]
|
||||
> This is an experimental feature currently under active development and
|
||||
> may need to be enabled under `/settings`.
|
||||
|
||||
Model steering is particularly useful during complex [Plan Mode](./plan-mode.md)
|
||||
workflows or long-running subagent executions where you want to ensure the agent
|
||||
stays on the right track.
|
||||
|
||||
## Enabling model steering
|
||||
|
||||
Model steering is an experimental feature and is disabled by default. You can
|
||||
enable it using the `/settings` command or by updating your `settings.json`
|
||||
file.
|
||||
|
||||
1. Type `/settings` in Gemini CLI.
|
||||
2. Search for **Model Steering**.
|
||||
3. Set the value to **true**.
|
||||
|
||||
Alternatively, add the following to your `settings.json`:
|
||||
|
||||
```json
|
||||
{
|
||||
"experimental": {
|
||||
"modelSteering": true
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
## Using model steering
|
||||
|
||||
When model steering is enabled, Gemini CLI treats any text you type while the
|
||||
agent is working as a steering hint.
|
||||
|
||||
1. Start a task (for example, "Refactor the database service").
|
||||
2. While the agent is working (the spinner is visible), type your feedback in
|
||||
the input box.
|
||||
3. Press **Enter**.
|
||||
|
||||
Gemini CLI acknowledges your hint with a brief message and injects it directly
|
||||
into the model's context for the very next turn. The model then re-evaluates its
|
||||
current plan and adjusts its actions accordingly.
|
||||
|
||||
### Common use cases
|
||||
|
||||
You can use steering hints to guide the model in several ways:
|
||||
|
||||
- **Correcting a path:** "Actually, the utilities are in `src/common/utils`."
|
||||
- **Skipping a step:** "Skip the unit tests for now and just focus on the
|
||||
implementation."
|
||||
- **Adding context:** "The `User` type is defined in `packages/core/types.ts`."
|
||||
- **Redirecting the effort:** "Stop searching the codebase and start drafting
|
||||
the plan now."
|
||||
- **Handling ambiguity:** "Use the existing `Logger` class instead of creating a
|
||||
new one."
|
||||
|
||||
## How it works
|
||||
|
||||
When you submit a steering hint, Gemini CLI performs the following actions:
|
||||
|
||||
1. **Immediate acknowledgment:** It uses a small, fast model to generate a
|
||||
one-sentence acknowledgment so you know your hint was received.
|
||||
2. **Context injection:** It prepends an internal instruction to your hint that
|
||||
tells the main agent to:
|
||||
- Re-evaluate the active plan.
|
||||
- Classify the update (for example, as a new task or extra context).
|
||||
- Apply minimal-diff changes to affected tasks.
|
||||
3. **Real-time update:** The hint is delivered to the agent at the beginning of
|
||||
its next turn, ensuring the most immediate course correction possible.
|
||||
|
||||
## Next steps
|
||||
|
||||
- Tackle complex tasks with [Plan Mode](./plan-mode.md).
|
||||
- Build custom [Agent Skills](./skills.md).
|
||||
@@ -0,0 +1,55 @@
|
||||
# Gemini CLI model selection (`/model` command)
|
||||
|
||||
Select your Gemini CLI model. The `/model` command lets you configure the model
|
||||
used by Gemini CLI, giving you more control over your results. Use **Pro**
|
||||
models for complex tasks and reasoning, **Flash** models for high speed results,
|
||||
or the (recommended) **Auto** setting to choose the best model for your tasks.
|
||||
|
||||
<!-- prettier-ignore -->
|
||||
> [!NOTE]
|
||||
> The `/model` command (and the `--model` flag) does not override the
|
||||
> model used by sub-agents. Consequently, even when using the `/model` flag you
|
||||
> may see other models used in your model usage reports.
|
||||
|
||||
## How to use the `/model` command
|
||||
|
||||
Use the following command in Gemini CLI:
|
||||
|
||||
```
|
||||
/model
|
||||
```
|
||||
|
||||
Running this command will open a dialog with your options:
|
||||
|
||||
| Option | Description | Models |
|
||||
| ----------------- | -------------------------------------------------------------- | -------------------------------------------- |
|
||||
| Auto (Gemini 3) | Let the system choose the best Gemini 3 model for your task. | gemini-3-pro-preview, gemini-3-flash-preview |
|
||||
| Auto (Gemini 2.5) | Let the system choose the best Gemini 2.5 model for your task. | gemini-2.5-pro, gemini-2.5-flash |
|
||||
| Manual | Select a specific model. | Any available model. |
|
||||
|
||||
We recommend selecting one of the above **Auto** options. However, you can
|
||||
select **Manual** to select a specific model from those available.
|
||||
|
||||
You can also use the `--model` flag to specify a particular Gemini model on
|
||||
startup. For more details, refer to the
|
||||
[configuration documentation](../reference/configuration.md).
|
||||
|
||||
Changes to these settings will be applied to all subsequent interactions with
|
||||
Gemini CLI.
|
||||
|
||||
## Best practices for model selection
|
||||
|
||||
- **Default to Auto.** For most users, the _Auto_ option model provides a
|
||||
balance between speed and performance, automatically selecting the correct
|
||||
model based on the complexity of the task. Example: Developing a web
|
||||
application could include a mix of complex tasks (building architecture and
|
||||
scaffolding the project) and simple tasks (generating CSS).
|
||||
|
||||
- **Switch to Pro if you aren't getting the results you want.** If you think you
|
||||
need your model to be a little "smarter," you can manually select Pro. Pro
|
||||
will provide you with the highest levels of reasoning and creativity. Example:
|
||||
A complex or multi-stage debugging task.
|
||||
|
||||
- **Switch to Flash or Flash-Lite if you need faster results.** If you need a
|
||||
simple response quickly, Flash or Flash-Lite is the best option. Example:
|
||||
Converting a JSON object to a YAML string.
|
||||
@@ -0,0 +1,59 @@
|
||||
# Notifications (experimental)
|
||||
|
||||
Gemini CLI can send system notifications to alert you when a session completes
|
||||
or when it needs your attention, such as when it's waiting for you to approve a
|
||||
tool call.
|
||||
|
||||
<!-- prettier-ignore -->
|
||||
> [!NOTE]
|
||||
> This is an experimental feature currently under active development and
|
||||
> may need to be enabled under `/settings`.
|
||||
|
||||
Notifications are particularly useful when running long-running tasks or using
|
||||
[Plan Mode](./plan-mode.md), letting you switch to other windows while Gemini
|
||||
CLI works in the background.
|
||||
|
||||
## Requirements
|
||||
|
||||
### Terminal support
|
||||
|
||||
The CLI uses the OSC 9 terminal escape sequence to trigger system notifications.
|
||||
This is supported by several modern terminal emulators including iTerm2,
|
||||
WezTerm, Ghostty, and Kitty. If your terminal does not support OSC 9
|
||||
notifications, Gemini CLI falls back to a terminal bell (BEL) to get your
|
||||
attention. Most terminals respond to BEL with a taskbar flash or system alert
|
||||
sound.
|
||||
|
||||
## Enable notifications
|
||||
|
||||
Notifications are disabled by default. You can enable them using the `/settings`
|
||||
command or by updating your `settings.json` file.
|
||||
|
||||
1. Open the settings dialog by typing `/settings` in an interactive session.
|
||||
2. Navigate to the **General** category.
|
||||
3. Toggle the **Enable Notifications** setting to **On**.
|
||||
|
||||
Alternatively, add the following to your `settings.json`:
|
||||
|
||||
```json
|
||||
{
|
||||
"general": {
|
||||
"enableNotifications": true
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
## Types of notifications
|
||||
|
||||
Gemini CLI sends notifications for the following events:
|
||||
|
||||
- **Action required:** Triggered when the model is waiting for user input or
|
||||
tool approval. This helps you know when the CLI has paused and needs you to
|
||||
intervene.
|
||||
- **Session complete:** Triggered when a session finishes successfully. This is
|
||||
useful for tracking the completion of automated tasks.
|
||||
|
||||
## Next steps
|
||||
|
||||
- Start planning with [Plan Mode](./plan-mode.md).
|
||||
- Configure your experience with other [settings](./settings.md).
|
||||
@@ -0,0 +1,509 @@
|
||||
# Plan Mode
|
||||
|
||||
Plan Mode is a read-only environment for architecting robust solutions before
|
||||
implementation. With Plan Mode, you can:
|
||||
|
||||
- **Research:** Explore the project in a read-only state to prevent accidental
|
||||
changes.
|
||||
- **Design:** Understand problems, evaluate trade-offs, and choose a solution.
|
||||
- **Plan:** Align on an execution strategy before any code is modified.
|
||||
|
||||
Plan Mode is enabled by default. You can manage this setting using the
|
||||
`/settings` command.
|
||||
|
||||
## How to enter Plan Mode
|
||||
|
||||
Plan Mode integrates seamlessly into your workflow, letting you switch between
|
||||
planning and execution as needed.
|
||||
|
||||
You can either configure Gemini CLI to start in Plan Mode by default or enter
|
||||
Plan Mode manually during a session.
|
||||
|
||||
### Launch in Plan Mode
|
||||
|
||||
To start Gemini CLI directly in Plan Mode by default:
|
||||
|
||||
1. Use the `/settings` command.
|
||||
2. Set **Default Approval Mode** to `Plan`.
|
||||
|
||||
To launch Gemini CLI in Plan Mode once:
|
||||
|
||||
1. Use `gemini --approval-mode=plan` when launching Gemini CLI.
|
||||
|
||||
### Enter Plan Mode manually
|
||||
|
||||
To start Plan Mode while using Gemini CLI:
|
||||
|
||||
- **Keyboard shortcut:** Press `Shift+Tab` to cycle through approval modes
|
||||
(`Default` -> `Auto-Edit` -> `Plan`). Plan Mode is automatically removed from
|
||||
the rotation when Gemini CLI is actively processing or showing confirmation
|
||||
dialogs.
|
||||
|
||||
- **Command:** Type `/plan [goal]` in the input box. The `[goal]` is optional;
|
||||
for example, `/plan implement authentication` will switch to Plan Mode and
|
||||
immediately submit the prompt to the model.
|
||||
|
||||
- **Natural Language:** Ask Gemini CLI to "start a plan for...". Gemini CLI
|
||||
calls the
|
||||
[`enter_plan_mode`](../tools/planning.md#1-enter_plan_mode-enterplanmode) tool
|
||||
to switch modes. This tool is not available when Gemini CLI is in
|
||||
[YOLO mode](../reference/configuration.md#command-line-arguments).
|
||||
|
||||
## How to use Plan Mode
|
||||
|
||||
Plan Mode lets you collaborate with Gemini CLI to design a solution before
|
||||
Gemini CLI takes action.
|
||||
|
||||
1. **Provide a goal:** Start by describing what you want to achieve. Gemini CLI
|
||||
will then enter Plan Mode (if it's not already) to research the task.
|
||||
2. **Discuss and agree on strategy:** As Gemini CLI analyzes your codebase, it
|
||||
will discuss its findings and proposed strategy with you to ensure
|
||||
alignment. It may ask you questions or present different implementation
|
||||
options using [`ask_user`](../tools/ask-user.md). **Gemini CLI will stop and
|
||||
wait for your confirmation** before drafting the formal plan. You should
|
||||
reach an informal agreement on the approach before proceeding.
|
||||
3. **Review the plan:** Once you've agreed on the strategy, Gemini CLI creates
|
||||
a detailed implementation plan as a Markdown file in your plans directory.
|
||||
|
||||
- **View:** You can open and read this file to understand the proposed
|
||||
changes.
|
||||
- **Edit:** Press `Ctrl+X` to open the plan directly in your configured
|
||||
external editor.
|
||||
|
||||
4. **Approve or iterate:** Gemini CLI will present the finalized plan for your
|
||||
formal approval.
|
||||
- **Approve:** If you're satisfied with the plan, approve it to start the
|
||||
implementation immediately: **Yes, automatically accept edits** or **Yes,
|
||||
manually accept edits**.
|
||||
- **Iterate:** If the plan needs adjustments, provide feedback in the input
|
||||
box or [edit the plan file directly](#collaborative-plan-editing). Gemini
|
||||
CLI will refine the strategy and update the plan.
|
||||
- **Cancel:** You can cancel your plan with `Esc`.
|
||||
|
||||
For more complex or specialized planning tasks, you can
|
||||
[customize the planning workflow with skills](#custom-planning-with-skills).
|
||||
|
||||
### Collaborative plan editing
|
||||
|
||||
You can collaborate with Gemini CLI by making direct changes or leaving comments
|
||||
in the implementation plan. This is often faster and more precise than
|
||||
describing complex changes in natural language.
|
||||
|
||||
1. **Open the plan:** Press `Ctrl+X` when Gemini CLI presents a plan for
|
||||
review.
|
||||
2. **Edit or comment:** The plan opens in your configured external editor (for
|
||||
example, VS Code or Vim). You can:
|
||||
- **Modify steps:** Directly reorder, delete, or rewrite implementation
|
||||
steps.
|
||||
- **Leave comments:** Add inline questions or feedback (for example, "Wait,
|
||||
shouldn't we use the existing `Logger` class here?").
|
||||
3. **Save and close:** Save your changes and close the editor.
|
||||
4. **Review and refine:** Gemini CLI automatically detects the changes, reviews
|
||||
your comments, and adjusts the implementation strategy. It then presents the
|
||||
refined plan for your final approval.
|
||||
|
||||
## How to exit Plan Mode
|
||||
|
||||
You can exit Plan Mode at any time, whether you have finalized a plan or want to
|
||||
switch back to another mode.
|
||||
|
||||
- **Approve a plan:** When Gemini CLI presents a finalized plan, approving it
|
||||
automatically exits Plan Mode and starts the implementation.
|
||||
- **Keyboard shortcut:** Press `Shift+Tab` to cycle to the desired mode.
|
||||
- **Natural language:** Ask Gemini CLI to "exit plan mode" or "stop planning."
|
||||
|
||||
## Tool Restrictions
|
||||
|
||||
Plan Mode enforces strict safety policies to prevent accidental changes.
|
||||
|
||||
These are the only allowed tools:
|
||||
|
||||
- **FileSystem (Read):**
|
||||
[`read_file`](../tools/file-system.md#2-read_file-readfile),
|
||||
[`list_directory`](../tools/file-system.md#1-list_directory-readfolder),
|
||||
[`glob`](../tools/file-system.md#4-glob-findfiles)
|
||||
- **Search:** [`grep_search`](../tools/file-system.md#5-grep_search-searchtext),
|
||||
[`google_web_search`](../tools/web-search.md),
|
||||
[`web_fetch`](../tools/web-fetch.md) (requires explicit confirmation),
|
||||
[`get_internal_docs`](../tools/internal-docs.md)
|
||||
- **Research Subagents:**
|
||||
[`codebase_investigator`](../core/subagents.md#codebase-investigator),
|
||||
[`cli_help`](../core/subagents.md#cli-help-agent)
|
||||
- **Interaction:** [`ask_user`](../tools/ask-user.md)
|
||||
- **MCP tools (Read):** Read-only [MCP tools](../tools/mcp-server.md) (for
|
||||
example, `github_read_issue`, `postgres_read_schema`) and core
|
||||
[MCP resource tools](../tools/mcp-resources.md) (`list_mcp_resources`,
|
||||
`read_mcp_resource`) are allowed.
|
||||
- **Planning (Write):**
|
||||
[`write_file`](../tools/file-system.md#3-write_file-writefile) and
|
||||
[`replace`](../tools/file-system.md#6-replace-edit) only allowed for `.md`
|
||||
files in the `~/.gemini/tmp/<project>/<session-id>/plans/` directory or your
|
||||
[custom plans directory](#custom-plan-directory-and-policies).
|
||||
- **Skills:** [`activate_skill`](../cli/skills.md) (allows loading specialized
|
||||
instructions and resources in a read-only manner)
|
||||
|
||||
## Customization and best practices
|
||||
|
||||
Plan Mode is secure by default, but you can adapt it to fit your specific
|
||||
workflows. You can customize how Gemini CLI plans by using skills, adjusting
|
||||
safety policies, changing where plans are stored, or adding hooks.
|
||||
|
||||
### Custom planning with skills
|
||||
|
||||
You can use [Agent Skills](../cli/skills.md) to customize how Gemini CLI
|
||||
approaches planning for specific types of tasks. When a skill is activated
|
||||
during Plan Mode, its specialized instructions and procedural workflows will
|
||||
guide the research, design, and planning phases.
|
||||
|
||||
For example:
|
||||
|
||||
- A **"Database Migration"** skill could ensure the plan includes data safety
|
||||
checks and rollback strategies.
|
||||
- A **"Security Audit"** skill could prompt Gemini CLI to look for specific
|
||||
vulnerabilities during codebase exploration.
|
||||
- A **"Frontend Design"** skill could guide Gemini CLI to use specific UI
|
||||
components and accessibility standards in its proposal.
|
||||
|
||||
To use a skill in Plan Mode, you can explicitly ask Gemini CLI to "use the
|
||||
`<skill-name>` skill to plan..." or Gemini CLI may autonomously activate it
|
||||
based on the task description.
|
||||
|
||||
### Custom policies
|
||||
|
||||
Plan Mode's default tool restrictions are managed by the
|
||||
[policy engine](../reference/policy-engine.md) and defined in the built-in
|
||||
[`plan.toml`] file. The built-in policy (Tier 1) enforces the read-only state,
|
||||
but you can customize these rules by creating your own policies in your
|
||||
`~/.gemini/policies/` directory (Tier 2).
|
||||
|
||||
#### Global vs. mode-specific rules
|
||||
|
||||
As described in the
|
||||
[policy engine documentation](../reference/policy-engine.md#approval-modes), any
|
||||
rule that does not explicitly specify `modes` is considered "always active" and
|
||||
will apply to Plan Mode as well.
|
||||
|
||||
To maintain the integrity of Plan Mode as a safe research environment,
|
||||
persistent tool approvals are context-aware. Approvals granted in modes like
|
||||
Default or Auto-Edit do not apply to Plan Mode, ensuring that tools trusted for
|
||||
implementation don't automatically execute while you're researching. However,
|
||||
approvals granted while in Plan Mode are treated as intentional choices for
|
||||
global trust and apply to all modes.
|
||||
|
||||
If you want to manually restrict a rule to other modes but _not_ to Plan Mode,
|
||||
you must explicitly specify the target modes. For example, to allow `npm test`
|
||||
in default and Auto-Edit modes but not in Plan Mode:
|
||||
|
||||
```toml
|
||||
[[rule]]
|
||||
toolName = "run_shell_command"
|
||||
commandPrefix = "npm test"
|
||||
decision = "allow"
|
||||
priority = 100
|
||||
# By omitting "plan", this rule will not be active in Plan Mode.
|
||||
modes = ["default", "autoEdit"]
|
||||
```
|
||||
|
||||
#### Example: Automatically approve read-only MCP tools
|
||||
|
||||
By default, read-only MCP tools require user confirmation in Plan Mode. You can
|
||||
use `toolAnnotations` and the `mcpName` wildcard to customize this behavior for
|
||||
your specific environment.
|
||||
|
||||
`~/.gemini/policies/mcp-read-only.toml`
|
||||
|
||||
```toml
|
||||
[[rule]]
|
||||
toolName = "*"
|
||||
mcpName = "*"
|
||||
toolAnnotations = { readOnlyHint = true }
|
||||
decision = "allow"
|
||||
priority = 100
|
||||
modes = ["plan"]
|
||||
```
|
||||
|
||||
For more information on how the policy engine works, see the
|
||||
[policy engine](../reference/policy-engine.md) docs.
|
||||
|
||||
#### Example: Allow git commands in Plan Mode
|
||||
|
||||
This rule lets you check the repository status and see changes while in Plan
|
||||
Mode.
|
||||
|
||||
`~/.gemini/policies/git-research.toml`
|
||||
|
||||
```toml
|
||||
[[rule]]
|
||||
toolName = "run_shell_command"
|
||||
commandPrefix = ["git status", "git diff"]
|
||||
decision = "allow"
|
||||
priority = 100
|
||||
modes = ["plan"]
|
||||
```
|
||||
|
||||
#### Example: Enable custom subagents in Plan Mode
|
||||
|
||||
Built-in research [subagents](../core/subagents.md) like
|
||||
[`codebase_investigator`](../core/subagents.md#codebase-investigator) and
|
||||
[`cli_help`](../core/subagents.md#cli-help-agent) are enabled by default in Plan
|
||||
Mode. You can enable additional
|
||||
[custom subagents](../core/subagents.md#creating-custom-subagents) by adding a
|
||||
rule to your policy.
|
||||
|
||||
`~/.gemini/policies/research-subagents.toml`
|
||||
|
||||
```toml
|
||||
[[rule]]
|
||||
toolName = "my_custom_subagent"
|
||||
decision = "allow"
|
||||
priority = 100
|
||||
modes = ["plan"]
|
||||
```
|
||||
|
||||
Tell Gemini CLI it can use these tools in your prompt, for example: _"You can
|
||||
check ongoing changes in git."_
|
||||
|
||||
### Custom plan directory and policies
|
||||
|
||||
By default, planning artifacts are stored in a managed temporary directory
|
||||
outside your project: `~/.gemini/tmp/<project>/<session-id>/plans/`.
|
||||
|
||||
You can configure a custom directory for plans in your `settings.json`. For
|
||||
example, to store plans in a `.gemini/plans` directory within your project:
|
||||
|
||||
```json
|
||||
{
|
||||
"general": {
|
||||
"plan": {
|
||||
"directory": ".gemini/plans"
|
||||
}
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
To maintain the safety of Plan Mode, user-configured paths for the plans
|
||||
directory are restricted to the project root. This ensures that custom planning
|
||||
locations defined within a project's workspace cannot be used to escape and
|
||||
overwrite sensitive files elsewhere. Any user-configured directory must reside
|
||||
within the project boundary.
|
||||
|
||||
Using a custom directory requires updating your
|
||||
[policy engine](../reference/policy-engine.md) configurations to allow
|
||||
`write_file` and `replace` in that specific location. For example, to allow
|
||||
writing to the `.gemini/plans` directory within your project, create a policy
|
||||
file at `~/.gemini/policies/plan-custom-directory.toml`:
|
||||
|
||||
```toml
|
||||
[[rule]]
|
||||
toolName = ["write_file", "replace"]
|
||||
decision = "allow"
|
||||
priority = 100
|
||||
modes = ["plan"]
|
||||
# Adjust the pattern to match your custom directory.
|
||||
# This example matches any .md file in a .gemini/plans directory within the project.
|
||||
argsPattern = "\"file_path\":\"[^\"]+[\\\\/]+\\.gemini[\\\\/]+plans[\\\\/]+[\\w-]+\\.md\""
|
||||
```
|
||||
|
||||
### Using hooks with Plan Mode
|
||||
|
||||
You can use the [hook system](../hooks/writing-hooks.md) to automate parts of
|
||||
the planning workflow or enforce additional checks when Gemini CLI transitions
|
||||
into or out of Plan Mode.
|
||||
|
||||
Hooks such as `BeforeTool` or `AfterTool` can be configured to intercept the
|
||||
`enter_plan_mode` and `exit_plan_mode` tool calls.
|
||||
|
||||
> [!WARNING] When hooks are triggered by **tool executions**, they do **not**
|
||||
> run when you manually toggle Plan Mode using the `/plan` command or the
|
||||
> `Shift+Tab` keyboard shortcut. If you need hooks to execute on mode changes,
|
||||
> ensure the transition is initiated by the agent (for example, by asking "start
|
||||
> a plan for...").
|
||||
|
||||
#### Example: Archive approved plans to GCS (`AfterTool`)
|
||||
|
||||
If your organizational policy requires a record of all execution plans, you can
|
||||
use an `AfterTool` hook to securely copy the plan artifact to Google Cloud
|
||||
Storage whenever Gemini CLI exits Plan Mode to start the implementation.
|
||||
|
||||
**`.gemini/hooks/archive-plan.sh`:**
|
||||
|
||||
```bash
|
||||
#!/usr/bin/env bash
|
||||
# Extract the plan filename from the tool input JSON
|
||||
plan_filename=$(jq -r '.tool_input.plan_filename // empty')
|
||||
|
||||
# Construct the absolute path using the GEMINI_PLANS_DIR environment variable
|
||||
plan_path="$GEMINI_PLANS_DIR/$plan_filename"
|
||||
|
||||
if [ -f "$plan_path" ]; then
|
||||
# Generate a unique filename using a timestamp
|
||||
filename="$(date +%s)_$(basename "$plan_path")"
|
||||
|
||||
# Upload the plan to GCS in the background so it doesn't block the CLI
|
||||
gsutil cp "$plan_path" "gs://my-audit-bucket/gemini-plans/$filename" > /dev/null 2>&1 &
|
||||
fi
|
||||
|
||||
# AfterTool hooks should generally allow the flow to continue
|
||||
echo '{"decision": "allow"}'
|
||||
```
|
||||
|
||||
To register this `AfterTool` hook, add it to your `settings.json`:
|
||||
|
||||
```json
|
||||
{
|
||||
"hooks": {
|
||||
"AfterTool": [
|
||||
{
|
||||
"matcher": "exit_plan_mode",
|
||||
"hooks": [
|
||||
{
|
||||
"name": "archive-plan",
|
||||
"type": "command",
|
||||
"command": "~/.gemini/hooks/archive-plan.sh"
|
||||
}
|
||||
]
|
||||
}
|
||||
]
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
## Commands
|
||||
|
||||
- **`/plan copy`**: Copy the currently approved plan to your clipboard.
|
||||
|
||||
## Planning workflows
|
||||
|
||||
Plan Mode provides building blocks for structured research and design. These are
|
||||
implemented as [extensions](../extensions/index.md) using core planning tools
|
||||
like [`enter_plan_mode`](../tools/planning.md#1-enter_plan_mode-enterplanmode),
|
||||
[`exit_plan_mode`](../tools/planning.md#2-exit_plan_mode-exitplanmode), and
|
||||
[`ask_user`](../tools/ask-user.md).
|
||||
|
||||
### Built-in planning workflow
|
||||
|
||||
The built-in planner uses an adaptive workflow to analyze your project, consult
|
||||
you on trade-offs via [`ask_user`](../tools/ask-user.md), and draft a plan for
|
||||
your approval.
|
||||
|
||||
### Custom planning workflows
|
||||
|
||||
You can install or create specialized planners to suit your workflow.
|
||||
|
||||
#### Conductor
|
||||
|
||||
[Conductor] is designed for spec-driven development. It organizes work into
|
||||
"tracks" and stores persistent artifacts in your project's `conductor/`
|
||||
directory:
|
||||
|
||||
- **Automate transitions:** Switches to read-only mode via
|
||||
[`enter_plan_mode`](../tools/planning.md#1-enter_plan_mode-enterplanmode).
|
||||
- **Streamline decisions:** Uses [`ask_user`](../tools/ask-user.md) for
|
||||
architectural choices.
|
||||
- **Maintain project context:** Stores artifacts in the project directory using
|
||||
[custom plan directory and policies](#custom-plan-directory-and-policies).
|
||||
- **Handoff execution:** Transitions to implementation via
|
||||
[`exit_plan_mode`](../tools/planning.md#2-exit_plan_mode-exitplanmode).
|
||||
|
||||
#### Build your own
|
||||
|
||||
Since Plan Mode is built on modular building blocks, you can develop your own
|
||||
custom planning workflow as an [extensions](../extensions/index.md). By
|
||||
leveraging core tools and [custom policies](#custom-policies), you can define
|
||||
how Gemini CLI researches and stores plans for your specific domain.
|
||||
|
||||
To build a custom planning workflow, you can use:
|
||||
|
||||
- **Tool usage:** Use core tools like
|
||||
[`enter_plan_mode`](../tools/planning.md#1-enter_plan_mode-enterplanmode),
|
||||
[`ask_user`](../tools/ask-user.md), and
|
||||
[`exit_plan_mode`](../tools/planning.md#2-exit_plan_mode-exitplanmode) to
|
||||
manage the research and design process.
|
||||
- **Customization:** Set your own storage locations and policy rules using
|
||||
[custom plan directories](#custom-plan-directory-and-policies) and
|
||||
[custom policies](#custom-policies).
|
||||
|
||||
<!-- prettier-ignore -->
|
||||
> [!TIP]
|
||||
> Use [Conductor] as a reference when building your own custom
|
||||
> planning workflow.
|
||||
|
||||
By using Plan Mode as its execution environment, your custom methodology can
|
||||
enforce read-only safety during the design phase while benefiting from
|
||||
high-reasoning model routing.
|
||||
|
||||
## Automatic Model Routing
|
||||
|
||||
When using an [auto model](../reference/configuration.md#model), Gemini CLI
|
||||
automatically optimizes [model routing](../cli/telemetry.md#model-routing) based
|
||||
on the current phase of your task:
|
||||
|
||||
1. **Planning Phase:** While in Plan Mode, the CLI routes requests to a
|
||||
high-reasoning **Pro** model to ensure robust architectural decisions and
|
||||
high-quality plans.
|
||||
2. **Implementation Phase:** Once a plan is approved and you exit Plan Mode,
|
||||
the CLI detects the existence of the approved plan and automatically
|
||||
switches to a high-speed **Flash** model. This provides a faster, more
|
||||
responsive experience during the implementation of the plan.
|
||||
|
||||
If the high-reasoning model is unavailable or you don't have access to it,
|
||||
Gemini CLI automatically and silently falls back to a faster model to ensure
|
||||
your workflow isn't interrupted.
|
||||
|
||||
This behavior is enabled by default to provide the best balance of quality and
|
||||
performance. You can disable this automatic switching in your settings:
|
||||
|
||||
```json
|
||||
{
|
||||
"general": {
|
||||
"plan": {
|
||||
"modelRouting": false
|
||||
}
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
## Cleanup
|
||||
|
||||
By default, Gemini CLI automatically cleans up old session data, including all
|
||||
associated plan files and task trackers.
|
||||
|
||||
- **Default behavior:** Sessions (and their plans) are retained for **30 days**.
|
||||
- **Configuration:** You can customize this behavior via the `/settings` command
|
||||
(search for **Enable Session Cleanup** or **Keep chat history**) or in your
|
||||
`settings.json` file. See
|
||||
[session retention](../cli/session-management.md#session-retention) for more
|
||||
details.
|
||||
|
||||
Manual deletion also removes all associated artifacts:
|
||||
|
||||
- **Command Line:** Use `gemini --delete-session <index|id>`.
|
||||
- **Session Browser:** Press `/resume`, navigate to a session, and press `x`.
|
||||
|
||||
If you use a [custom plans directory](#custom-plan-directory-and-policies),
|
||||
those files are not automatically deleted and must be managed manually.
|
||||
|
||||
## Non-interactive execution
|
||||
|
||||
When running Gemini CLI in non-interactive environments (such as headless
|
||||
scripts or CI/CD pipelines), Plan Mode optimizes for automated workflows:
|
||||
|
||||
- **Automatic transitions:** The policy engine automatically approves the
|
||||
`enter_plan_mode` and `exit_plan_mode` tools without prompting for user
|
||||
confirmation.
|
||||
- **Automated implementation:** When exiting Plan Mode to execute the plan,
|
||||
Gemini CLI automatically switches to
|
||||
[YOLO mode](../reference/policy-engine.md#approval-modes) instead of the
|
||||
standard Default mode. This allows the CLI to execute the implementation steps
|
||||
automatically without hanging on interactive tool approvals.
|
||||
|
||||
**Example:**
|
||||
|
||||
```bash
|
||||
gemini --approval-mode plan -p "Analyze telemetry and suggest improvements"
|
||||
```
|
||||
|
||||
[`plan.toml`]:
|
||||
https://github.com/google-gemini/gemini-cli/blob/main/packages/core/src/policy/policies/plan.toml
|
||||
[Conductor]: https://github.com/gemini-cli-extensions/conductor
|
||||
[open an issue]: https://github.com/google-gemini/gemini-cli/issues
|
||||
@@ -0,0 +1,51 @@
|
||||
# Rewind
|
||||
|
||||
The `/rewind` command lets you go back to a previous state in your conversation
|
||||
and, optionally, revert any file changes made by the AI during those
|
||||
interactions. This is a powerful tool for undoing mistakes, exploring different
|
||||
approaches, or simply cleaning up your session history.
|
||||
|
||||
## Usage
|
||||
|
||||
To use the rewind feature, simply type `/rewind` into the input prompt and press
|
||||
**Enter**.
|
||||
|
||||
Alternatively, you can use the keyboard shortcut: **Press `Esc` twice**.
|
||||
|
||||
## Interface
|
||||
|
||||
When you trigger a rewind, an interactive list of your previous interactions
|
||||
appears.
|
||||
|
||||
1. **Select interaction:** Use the **Up/Down arrow keys** to navigate through
|
||||
the list. The most recent interactions are at the bottom.
|
||||
2. **Preview:** As you select an interaction, you'll see a preview of the user
|
||||
prompt and, if applicable, the number of files changed during that step.
|
||||
3. **Confirm selection:** Press **Enter** on the interaction you want to rewind
|
||||
back to.
|
||||
4. **Action selection:** After selecting an interaction, you'll be presented
|
||||
with a confirmation dialog with up to three options:
|
||||
- **Rewind conversation and revert code changes:** Reverts both the chat
|
||||
history and the file modifications to the state before the selected
|
||||
interaction.
|
||||
- **Rewind conversation:** Only reverts the chat history. File changes are
|
||||
kept.
|
||||
- **Revert code changes:** Only reverts the file modifications. The chat
|
||||
history is kept.
|
||||
- **Do nothing (esc):** Cancels the rewind operation.
|
||||
|
||||
If no code changes were made since the selected point, the options related to
|
||||
reverting code changes will be hidden.
|
||||
|
||||
## Key considerations
|
||||
|
||||
- **Destructive action:** Rewinding is a destructive action for your current
|
||||
session history and potentially your files. Use it with care.
|
||||
- **Agent awareness:** When you rewind the conversation, the AI model loses all
|
||||
memory of the interactions that were removed. If you only revert code changes,
|
||||
you may need to inform the model that the files have changed.
|
||||
- **Manual edits:** Rewinding only affects file changes made by the AI's edit
|
||||
tools. It does **not** undo manual edits you've made or changes triggered by
|
||||
the shell tool (`!`).
|
||||
- **Compression:** Rewind works across chat compression points by reconstructing
|
||||
the history from stored session data.
|
||||
@@ -0,0 +1,472 @@
|
||||
# Sandboxing in Gemini CLI
|
||||
|
||||
This document provides a guide to sandboxing in Gemini CLI, including
|
||||
prerequisites, quickstart, and configuration.
|
||||
|
||||
## Prerequisites
|
||||
|
||||
Before using sandboxing, you need to install and set up Gemini CLI:
|
||||
|
||||
```bash
|
||||
npm install -g @google/gemini-cli
|
||||
```
|
||||
|
||||
To verify the installation:
|
||||
|
||||
```bash
|
||||
gemini --version
|
||||
```
|
||||
|
||||
## Overview of sandboxing
|
||||
|
||||
Sandboxing isolates potentially dangerous operations (such as shell commands or
|
||||
file modifications) from your host system, providing a security barrier between
|
||||
AI operations and your environment.
|
||||
|
||||
The benefits of sandboxing include:
|
||||
|
||||
- **Security**: Prevent accidental system damage or data loss.
|
||||
- **Isolation**: Limit file system access to project directory.
|
||||
- **Consistency**: Ensure reproducible environments across different systems.
|
||||
- **Safety**: Reduce risk when working with untrusted code or experimental
|
||||
commands.
|
||||
|
||||
## Quickstart
|
||||
|
||||
You can enable sandboxing using a command flag, environment variable, or
|
||||
configuration file.
|
||||
|
||||
### Using the command flag
|
||||
|
||||
```bash
|
||||
gemini -s -p "analyze the code structure"
|
||||
```
|
||||
|
||||
### Using an environment variable
|
||||
|
||||
**macOS/Linux**
|
||||
|
||||
```bash
|
||||
export GEMINI_SANDBOX=true
|
||||
gemini -p "run the test suite"
|
||||
```
|
||||
|
||||
**Windows (PowerShell)**
|
||||
|
||||
```powershell
|
||||
$env:GEMINI_SANDBOX="true"
|
||||
gemini -p "run the test suite"
|
||||
```
|
||||
|
||||
### Configuring via settings.json
|
||||
|
||||
```json
|
||||
{
|
||||
"tools": {
|
||||
"sandbox": "docker"
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
## Configuration
|
||||
|
||||
Enable sandboxing using one of the following methods (in order of precedence):
|
||||
|
||||
1. **Command flag**: `-s` or `--sandbox`
|
||||
2. **Environment variable**:
|
||||
`GEMINI_SANDBOX=true|docker|podman|sandbox-exec|runsc|lxc`
|
||||
3. **Settings file**: `"sandbox": true` in the `tools` object of your
|
||||
`settings.json` file (for example, `{"tools": {"sandbox": true}}`).
|
||||
|
||||
## Sandboxing methods
|
||||
|
||||
Your ideal method of sandboxing may differ depending on your platform and your
|
||||
preferred container solution.
|
||||
|
||||
### 1. macOS Seatbelt (macOS only)
|
||||
|
||||
Lightweight, built-in sandboxing using `sandbox-exec`.
|
||||
|
||||
**Default profile**: `permissive-open` - restricts writes outside project
|
||||
directory but allows most other operations.
|
||||
|
||||
Built-in profiles (set via `SEATBELT_PROFILE` env var):
|
||||
|
||||
- `permissive-open` (default): Write restrictions, network allowed
|
||||
- `permissive-proxied`: Write restrictions, network via proxy
|
||||
- `restrictive-open`: Strict restrictions, network allowed
|
||||
- `restrictive-proxied`: Strict restrictions, network via proxy
|
||||
- `strict-open`: Read and write restrictions, network allowed
|
||||
- `strict-proxied`: Read and write restrictions, network via proxy
|
||||
|
||||
### 2. Container-based (Docker/Podman)
|
||||
|
||||
Cross-platform sandboxing with complete process isolation using container
|
||||
technology. By default, it uses the `ghcr.io/google/gemini-cli:latest` image.
|
||||
|
||||
**Prerequisites:**
|
||||
|
||||
- Docker or Podman must be installed and running on your system.
|
||||
|
||||
**How it works (Workspace directory):**
|
||||
|
||||
Inside the sandbox container, your current working directory is mounted at the
|
||||
**exact same absolute path** as it is on your host machine. For example, if you
|
||||
run the CLI from `/Users/you/project` on your host machine, the sandbox will
|
||||
mount your local project folder and operate within `/Users/you/project` inside
|
||||
the container. This allows the AI to seamlessly read and modify your project
|
||||
files while remaining isolated from the rest of your system.
|
||||
|
||||
**Quick setup:**
|
||||
|
||||
To enable Docker sandboxing, run Gemini CLI with the sandbox flag and specify
|
||||
Docker as the provider:
|
||||
|
||||
```bash
|
||||
# Using the environment variable (Recommended)
|
||||
export GEMINI_SANDBOX=docker
|
||||
gemini -p "build the project"
|
||||
|
||||
# Or configure it permanently in your settings.json
|
||||
# {"tools": {"sandbox": "docker"}}
|
||||
```
|
||||
|
||||
**Customizing the Sandbox Image:**
|
||||
|
||||
If your project requires specific dependencies, you can specify a custom image
|
||||
name or have Gemini CLI build one for you automatically. You can use any Docker
|
||||
or Podman image as your sandbox, provided it has standard shell utilities (like
|
||||
`bash`) available.
|
||||
|
||||
**Option A: Using an existing custom image (e.g., Artifact Registry)**
|
||||
|
||||
To configure a custom image that is hosted on a registry (or built locally),
|
||||
update your `settings.json` to use an object for the sandbox configuration, or
|
||||
set the `GEMINI_SANDBOX_IMAGE` environment variable.
|
||||
|
||||
_Example: Configuring via `settings.json`_
|
||||
|
||||
```json
|
||||
{
|
||||
"tools": {
|
||||
"sandbox": {
|
||||
"command": "docker",
|
||||
"image": "us-central1-docker.pkg.dev/my-project/my-repo/my-custom-sandbox:latest"
|
||||
}
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
_Example: Configuring via environment variable_
|
||||
|
||||
```bash
|
||||
export GEMINI_SANDBOX_IMAGE="us-central1-docker.pkg.dev/my-project/my-repo/my-custom-sandbox:latest"
|
||||
```
|
||||
|
||||
**Option B: Building a local custom image automatically**
|
||||
|
||||
If you prefer to define your environment as code, you can provide a Dockerfile
|
||||
and Gemini CLI will build the image automatically.
|
||||
|
||||
1. Create a `.gemini/sandbox.Dockerfile` in your project root.
|
||||
2. Ensure you have the `gh` CLI installed and authenticated (if you are using
|
||||
the default `ghcr.io/google/gemini-cli` image as a base).
|
||||
3. Run your command with the `BUILD_SANDBOX` environment variable set:
|
||||
|
||||
```bash
|
||||
BUILD_SANDBOX=1 GEMINI_SANDBOX=docker gemini -p "run my custom build"
|
||||
```
|
||||
|
||||
### 3. Windows Native Sandbox (Windows only)
|
||||
|
||||
... **Troubleshooting and Side Effects:**
|
||||
|
||||
The Windows Native sandbox uses the `icacls` command to set a "Low Mandatory
|
||||
Level" on files and directories it needs to write to.
|
||||
|
||||
- **Persistence**: These integrity level changes are persistent on the
|
||||
filesystem. Even after the sandbox session ends, files created or modified by
|
||||
the sandbox will retain their "Low" integrity level.
|
||||
- **Manual Reset**: If you need to reset the integrity level of a file or
|
||||
directory, you can use:
|
||||
```powershell
|
||||
icacls "C:\path\to\dir" /setintegritylevel Medium
|
||||
```
|
||||
- **System Folders**: The sandbox manager automatically skips setting integrity
|
||||
levels on system folders (like `C:\Windows`) for safety.
|
||||
|
||||
### 4. gVisor / runsc (Linux only)
|
||||
|
||||
Strongest isolation available: runs containers inside a user-space kernel via
|
||||
[gVisor](https://github.com/google/gvisor). gVisor intercepts all container
|
||||
system calls and handles them in a sandboxed kernel written in Go, providing a
|
||||
strong security barrier between AI operations and the host OS.
|
||||
|
||||
**Prerequisites:**
|
||||
|
||||
- Linux (gVisor supports Linux only)
|
||||
- Docker installed and running
|
||||
- gVisor/runsc runtime configured
|
||||
|
||||
When you set `sandbox: "runsc"`, Gemini CLI runs
|
||||
`docker run --runtime=runsc ...` to execute containers with gVisor isolation.
|
||||
runsc is not auto-detected; you must specify it explicitly (e.g.
|
||||
`GEMINI_SANDBOX=runsc` or `sandbox: "runsc"`).
|
||||
|
||||
To set up runsc:
|
||||
|
||||
1. Install the runsc binary.
|
||||
2. Configure the Docker daemon to use the runsc runtime.
|
||||
3. Verify the installation.
|
||||
|
||||
### 5. LXC/LXD (Linux only, experimental)
|
||||
|
||||
Full-system container sandboxing using LXC/LXD. Unlike Docker/Podman, LXC
|
||||
containers run a complete Linux system with `systemd`, `snapd`, and other system
|
||||
services. This is ideal for tools that don't work in standard Docker containers,
|
||||
such as Snapcraft and Rockcraft.
|
||||
|
||||
**Prerequisites**:
|
||||
|
||||
- Linux only.
|
||||
- LXC/LXD must be installed (`snap install lxd` or `apt install lxd`).
|
||||
- A container must be created and running before starting Gemini CLI. Gemini
|
||||
does **not** create the container automatically.
|
||||
|
||||
**Quick setup**:
|
||||
|
||||
```bash
|
||||
# Initialize LXD (first time only)
|
||||
lxd init --auto
|
||||
|
||||
# Create and start an Ubuntu container
|
||||
lxc launch ubuntu:24.04 gemini-sandbox
|
||||
|
||||
# Enable LXC sandboxing
|
||||
export GEMINI_SANDBOX=lxc
|
||||
gemini -p "build the project"
|
||||
```
|
||||
|
||||
**Custom container name**:
|
||||
|
||||
```bash
|
||||
export GEMINI_SANDBOX=lxc
|
||||
export GEMINI_SANDBOX_IMAGE=my-snapcraft-container
|
||||
gemini -p "build the snap"
|
||||
```
|
||||
|
||||
**Limitations**:
|
||||
|
||||
- Linux only (LXC is not available on macOS or Windows).
|
||||
- The container must already exist and be running.
|
||||
- The workspace directory is bind-mounted into the container at the same
|
||||
absolute path — the path must be writable inside the container.
|
||||
- Used with tools like Snapcraft or Rockcraft that require a full system.
|
||||
|
||||
## Tool sandboxing
|
||||
|
||||
Tool-level sandboxing provides granular isolation for individual tool executions
|
||||
(like `shell_exec` and `write_file`) instead of sandboxing the entire Gemini CLI
|
||||
process.
|
||||
|
||||
This approach offers better integration with your local environment for non-tool
|
||||
tasks (like UI rendering and configuration loading) while still providing
|
||||
security for tool-driven operations.
|
||||
|
||||
### How to turn off tool sandboxing
|
||||
|
||||
If you experience issues with tool sandboxing or prefer full-process isolation,
|
||||
you can disable it by setting `security.toolSandboxing` to `false` in your
|
||||
`settings.json` file.
|
||||
|
||||
```json
|
||||
{
|
||||
"security": {
|
||||
"toolSandboxing": false
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
<!-- prettier-ignore -->
|
||||
> [!NOTE]
|
||||
> Changing the `security.toolSandboxing` setting requires a restart of Gemini
|
||||
> CLI to take effect.
|
||||
|
||||
## Sandbox expansion
|
||||
|
||||
Sandbox expansion is a dynamic permission system that lets Gemini CLI request
|
||||
additional permissions for a command when needed.
|
||||
|
||||
When a sandboxed command fails due to permission restrictions (like restricted
|
||||
file paths or network access), or when a command is proactively identified as
|
||||
requiring extra permissions (like `npm install`), Gemini CLI will present you
|
||||
with a "Sandbox Expansion Request."
|
||||
|
||||
### How sandbox expansion works
|
||||
|
||||
1. **Detection**: Gemini CLI detects a sandbox denial or proactively identifies
|
||||
a command that requires extra permissions.
|
||||
2. **Request**: A modal dialog is shown, explaining which additional
|
||||
permissions (e.g., specific directories or network access) are required.
|
||||
3. **Approval**: If you approve the expansion, the command is executed with the
|
||||
extended permissions for that specific run.
|
||||
|
||||
This mechanism ensures you don't have to manually re-run commands with more
|
||||
permissive sandbox settings, while still maintaining control over what the AI
|
||||
can access.
|
||||
|
||||
### Including files outside the workspace
|
||||
|
||||
By default, the sandbox only has access to the current project workspace. If you
|
||||
need the sandbox to have permission to operate on certain files or directories
|
||||
from the local file system outside of the project workspace, you can mount them
|
||||
using the `SANDBOX_MOUNTS` environment variable.
|
||||
|
||||
Provide a comma-separated list of mount definitions in the format
|
||||
`from:to:opts`. If `to` is omitted, it defaults to the same path as `from`. If
|
||||
`opts` is omitted, it defaults to `ro` (read-only). Note that the `from` path
|
||||
must be an absolute path.
|
||||
|
||||
**Example**:
|
||||
|
||||
```bash
|
||||
export SANDBOX_MOUNTS="/path/on/host:/path/in/container:rw,/another/path:ro"
|
||||
```
|
||||
|
||||
## Running inside a Docker container
|
||||
|
||||
If you are running Gemini CLI itself from within an official or custom Docker
|
||||
container and want to enable sandboxing, you must share the host's Docker socket
|
||||
and ensure your workspace paths align.
|
||||
|
||||
1. **Mount the Docker socket**: Map `/var/run/docker.sock` so the CLI can spawn
|
||||
sibling sandbox containers via the host's Docker daemon.
|
||||
2. **Align workspace paths**: The path to your workspace inside the container
|
||||
must exactly match the absolute path on the host. Because the sandbox
|
||||
container is spawned by the host's Docker daemon, it resolves volume mounts
|
||||
against the host file system.
|
||||
|
||||
**Example**:
|
||||
|
||||
```bash
|
||||
docker run -it \
|
||||
-v /var/run/docker.sock:/var/run/docker.sock \
|
||||
-v /absolute/path/on/host/project:/absolute/path/on/host/project \
|
||||
-w /absolute/path/on/host/project \
|
||||
-e GEMINI_SANDBOX=docker \
|
||||
ghcr.io/google/gemini-cli:latest
|
||||
```
|
||||
|
||||
## Advanced settings
|
||||
|
||||
### Custom sandbox flags
|
||||
|
||||
For container-based sandboxing, you can inject custom flags into the `docker` or
|
||||
`podman` command using the `SANDBOX_FLAGS` environment variable. This is useful
|
||||
for advanced configurations, such as disabling security features for specific
|
||||
use cases.
|
||||
|
||||
**Example (Podman)**:
|
||||
|
||||
To disable SELinux labeling for volume mounts, you can set the following:
|
||||
|
||||
**macOS/Linux**
|
||||
|
||||
```bash
|
||||
export SANDBOX_FLAGS="--security-opt label=disable"
|
||||
```
|
||||
|
||||
**Windows (PowerShell)**
|
||||
|
||||
```powershell
|
||||
$env:SANDBOX_FLAGS="--security-opt label=disable"
|
||||
```
|
||||
|
||||
Multiple flags can be provided as a space-separated string:
|
||||
|
||||
**macOS/Linux**
|
||||
|
||||
```bash
|
||||
export SANDBOX_FLAGS="--flag1 --flag2=value"
|
||||
```
|
||||
|
||||
**Windows (PowerShell)**
|
||||
|
||||
```powershell
|
||||
$env:SANDBOX_FLAGS="--flag1 --flag2=value"
|
||||
```
|
||||
|
||||
### Linux UID/GID handling
|
||||
|
||||
The sandbox automatically handles user permissions on Linux. Override these
|
||||
permissions with:
|
||||
|
||||
**macOS/Linux**
|
||||
|
||||
```bash
|
||||
export SANDBOX_SET_UID_GID=true # Force host UID/GID
|
||||
export SANDBOX_SET_UID_GID=false # Disable UID/GID mapping
|
||||
```
|
||||
|
||||
**Windows (PowerShell)**
|
||||
|
||||
```powershell
|
||||
$env:SANDBOX_SET_UID_GID="true" # Force host UID/GID
|
||||
$env:SANDBOX_SET_UID_GID="false" # Disable UID/GID mapping
|
||||
```
|
||||
|
||||
## Troubleshooting
|
||||
|
||||
### Common issues
|
||||
|
||||
**"Operation not permitted"**
|
||||
|
||||
- Operation requires access outside sandbox.
|
||||
- Try more permissive profile or add mount points.
|
||||
|
||||
**Missing commands**
|
||||
|
||||
- Add to a custom Dockerfile. Automatic `BUILD_SANDBOX` builds are only
|
||||
available when running Gemini CLI from source; npm installs need a prebuilt
|
||||
image instead.
|
||||
- Install via `sandbox.bashrc`.
|
||||
|
||||
**Network issues**
|
||||
|
||||
- Check sandbox profile allows network.
|
||||
- Verify proxy configuration.
|
||||
|
||||
### Debug mode
|
||||
|
||||
```bash
|
||||
DEBUG=1 gemini -s -p "debug command"
|
||||
```
|
||||
|
||||
<!-- prettier-ignore -->
|
||||
> [!NOTE]
|
||||
> If you have `DEBUG=true` in a project's `.env` file, it won't affect
|
||||
> gemini-cli due to automatic exclusion. Use `.gemini/.env` files for
|
||||
> gemini-cli specific debug settings.
|
||||
|
||||
### Inspect sandbox
|
||||
|
||||
```bash
|
||||
# Check environment
|
||||
gemini -s -p "run shell command: env | grep SANDBOX"
|
||||
|
||||
# List mounts
|
||||
gemini -s -p "run shell command: mount | grep workspace"
|
||||
```
|
||||
|
||||
## Security notes
|
||||
|
||||
- Sandboxing reduces but doesn't eliminate all risks.
|
||||
- Use the most restrictive profile that allows your work.
|
||||
- Container overhead is minimal after first build.
|
||||
- GUI applications may not work in sandboxes.
|
||||
|
||||
## Related documentation
|
||||
|
||||
- [Configuration](../reference/configuration.md): Full configuration options.
|
||||
- [Commands](../reference/commands.md): Available commands.
|
||||
- [Troubleshooting](../resources/troubleshooting.md): General troubleshooting.
|
||||
@@ -0,0 +1,215 @@
|
||||
# Session management
|
||||
|
||||
Session management saves your conversation history so you can resume your work
|
||||
where you left off. Use these features to review past interactions, manage
|
||||
history across different projects, and configure how long data is retained.
|
||||
|
||||
## Automatic saving
|
||||
|
||||
Your session history is recorded automatically as you interact with the model.
|
||||
This background process ensures your work is preserved even if you interrupt a
|
||||
session.
|
||||
|
||||
- **What is saved:** The complete conversation history, including:
|
||||
- Your prompts and the model's responses.
|
||||
- All tool executions (inputs and outputs).
|
||||
- Token usage statistics (input, output, cached, etc.).
|
||||
- Assistant thoughts and reasoning summaries (when available).
|
||||
- **Location:** Sessions are stored in `~/.gemini/tmp/<project_hash>/chats/`,
|
||||
where `<project_hash>` is a unique identifier based on your project's root
|
||||
directory.
|
||||
- **Scope:** Sessions are project-specific. Switching directories to a different
|
||||
project switches to that project's session history.
|
||||
|
||||
## Resuming sessions
|
||||
|
||||
You can resume a previous session to continue the conversation with all prior
|
||||
context restored. Resuming is supported both through command-line flags and an
|
||||
interactive browser.
|
||||
|
||||
### From the command line
|
||||
|
||||
When starting Gemini CLI, use the `--resume` (or `-r`) flag to load existing
|
||||
sessions.
|
||||
|
||||
- **Resume latest:**
|
||||
|
||||
```bash
|
||||
gemini --resume
|
||||
```
|
||||
|
||||
This immediately loads the most recent session.
|
||||
|
||||
- **Resume by index:** List available sessions first (see
|
||||
[Listing sessions](#listing-sessions)), then use the index number:
|
||||
|
||||
```bash
|
||||
gemini --resume 1
|
||||
```
|
||||
|
||||
- **Resume by ID:** You can also provide the full session UUID:
|
||||
```bash
|
||||
gemini --resume a1b2c3d4-e5f6-7890-abcd-ef1234567890
|
||||
```
|
||||
|
||||
### From the interactive interface
|
||||
|
||||
While the CLI is running, use the `/resume` slash command to open the **Session
|
||||
Browser**:
|
||||
|
||||
```text
|
||||
/resume
|
||||
```
|
||||
|
||||
When typing `/resume` (or `/chat`) in slash completion, commands are grouped
|
||||
under titled separators:
|
||||
|
||||
- `-- auto --` (session browser)
|
||||
- `list` is selectable and opens the session browser
|
||||
- `-- checkpoints --` (manual tagged checkpoint commands)
|
||||
|
||||
Unique prefixes such as `/resum` and `/cha` resolve to the same grouped menu.
|
||||
|
||||
The Session Browser provides an interactive interface where you can perform the
|
||||
following actions:
|
||||
|
||||
- **Browse:** Scroll through a list of your past sessions.
|
||||
- **Preview:** See details like the session date, message count, and the first
|
||||
user prompt.
|
||||
- **Search:** Press `/` to enter search mode, then type to filter sessions by ID
|
||||
or content.
|
||||
- **Select:** Press **Enter** to resume the selected session.
|
||||
- **Esc:** Press **Esc** to exit the Session Browser.
|
||||
|
||||
### Manual chat checkpoints
|
||||
|
||||
For named branch points inside a session, use chat checkpoints:
|
||||
|
||||
```text
|
||||
/resume save decision-point
|
||||
/resume list
|
||||
/resume resume decision-point
|
||||
```
|
||||
|
||||
Compatibility aliases:
|
||||
|
||||
- `/chat ...` works for the same commands.
|
||||
- `/resume checkpoints ...` also remains supported during migration.
|
||||
|
||||
## Parallel sessions with Git worktrees
|
||||
|
||||
When working on multiple tasks at once, you can use
|
||||
[Git worktrees](./git-worktrees.md) to give each Gemini session its own copy of
|
||||
the codebase. This prevents changes in one session from colliding with another.
|
||||
|
||||
## Managing sessions
|
||||
|
||||
You can list and delete sessions to keep your history organized and manage disk
|
||||
space.
|
||||
|
||||
### Listing sessions
|
||||
|
||||
To see a list of all available sessions for the current project from the command
|
||||
line, use the `--list-sessions` flag:
|
||||
|
||||
```bash
|
||||
gemini --list-sessions
|
||||
```
|
||||
|
||||
Output example:
|
||||
|
||||
```text
|
||||
Available sessions for this project (3):
|
||||
|
||||
1. Fix bug in auth (2 days ago) [a1b2c3d4]
|
||||
2. Refactor database schema (5 hours ago) [e5f67890]
|
||||
3. Update documentation (Just now) [abcd1234]
|
||||
```
|
||||
|
||||
### Deleting sessions
|
||||
|
||||
You can remove old or unwanted sessions to free up space or declutter your
|
||||
history.
|
||||
|
||||
**From the command line:** Use the `--delete-session` flag with an index or ID:
|
||||
|
||||
```bash
|
||||
gemini --delete-session 2
|
||||
```
|
||||
|
||||
**From the Session Browser:**
|
||||
|
||||
1. Open the browser with `/resume`.
|
||||
2. Navigate to the session you want to remove.
|
||||
3. Press **x**.
|
||||
|
||||
## Configuration
|
||||
|
||||
You can configure how Gemini CLI manages your session history in your
|
||||
`settings.json` file. These settings let you control retention policies and
|
||||
session lengths.
|
||||
|
||||
### Session retention
|
||||
|
||||
By default, Gemini CLI automatically cleans up old session data to prevent your
|
||||
history from growing indefinitely. When a session is deleted, Gemini CLI also
|
||||
removes all associated data, including implementation plans, task trackers, tool
|
||||
outputs, and activity logs.
|
||||
|
||||
The default policy is to **retain sessions for 30 days**.
|
||||
|
||||
#### Configuration
|
||||
|
||||
You can customize these policies using the `/settings` command or by manually
|
||||
editing your `settings.json` file:
|
||||
|
||||
```json
|
||||
{
|
||||
"general": {
|
||||
"sessionRetention": {
|
||||
"enabled": true,
|
||||
"maxAge": "30d",
|
||||
"maxCount": 50
|
||||
}
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
- **`enabled`**: (boolean) Master switch for session cleanup. Defaults to
|
||||
`true`.
|
||||
- **`maxAge`**: (string) Duration to keep sessions (for example, "24h", "7d",
|
||||
"4w"). Sessions older than this are deleted. Defaults to `"30d"`.
|
||||
- **`maxCount`**: (number) Maximum number of sessions to retain. The oldest
|
||||
sessions exceeding this count are deleted. Defaults to undefined (unlimited).
|
||||
- **`minRetention`**: (string) Minimum retention period (safety limit). Defaults
|
||||
to `"1d"`. Sessions newer than this period are never deleted by automatic
|
||||
cleanup.
|
||||
|
||||
### Session limits
|
||||
|
||||
You can limit the length of individual sessions to prevent context windows from
|
||||
becoming too large and expensive.
|
||||
|
||||
```json
|
||||
{
|
||||
"model": {
|
||||
"maxSessionTurns": 100
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
- **`maxSessionTurns`**: (number) The maximum number of turns (user and model
|
||||
exchanges) allowed in a single session. Set to `-1` for unlimited (default).
|
||||
|
||||
**Behavior when limit is reached:**
|
||||
|
||||
- **Interactive mode:** The CLI shows an informational message and stops
|
||||
sending requests to the model. You must manually start a new session.
|
||||
- **Non-interactive mode:** The CLI exits with an error.
|
||||
|
||||
## Next steps
|
||||
|
||||
- Explore the [Memory tool](../tools/memory.md) to save persistent information
|
||||
across sessions.
|
||||
- Learn how to [Checkpoint](./checkpointing.md) your session state.
|
||||
- Check out the [CLI reference](./cli-reference.md) for all command-line flags.
|
||||
@@ -0,0 +1,198 @@
|
||||
# Gemini CLI settings (`/settings` command)
|
||||
|
||||
Control your Gemini CLI experience with the `/settings` command. The `/settings`
|
||||
command opens a dialog to view and edit all your Gemini CLI settings, including
|
||||
your UI experience, keybindings, and accessibility features.
|
||||
|
||||
Your Gemini CLI settings are stored in a `settings.json` file. In addition to
|
||||
using the `/settings` command, you can also edit them in one of the following
|
||||
locations:
|
||||
|
||||
- **User settings**: `~/.gemini/settings.json`
|
||||
- **Workspace settings**: `your-project/.gemini/settings.json`
|
||||
|
||||
<!-- prettier-ignore -->
|
||||
> [!IMPORTANT]
|
||||
> Workspace settings override user settings.
|
||||
|
||||
## Settings reference
|
||||
|
||||
Here is a list of all the available settings, grouped by category and ordered as
|
||||
they appear in the UI.
|
||||
|
||||
<!-- SETTINGS-AUTOGEN:START -->
|
||||
|
||||
### General
|
||||
|
||||
| UI Label | Setting | Description | Default |
|
||||
| ----------------------------- | ---------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ----------- |
|
||||
| Vim Mode | `general.vimMode` | Enable Vim keybindings | `false` |
|
||||
| Default Approval Mode | `general.defaultApprovalMode` | The default approval mode for tool execution. 'default' prompts for approval, 'auto_edit' auto-approves edit tools, and 'plan' is read-only mode. YOLO mode (auto-approve all actions) can only be enabled via command line (--yolo or --approval-mode=yolo). | `"default"` |
|
||||
| Enable Auto Update | `general.enableAutoUpdate` | Enable automatic updates. | `true` |
|
||||
| Enable Terminal Notifications | `general.enableNotifications` | Enable terminal run-event notifications for action-required prompts and session completion. | `false` |
|
||||
| Terminal Notification Method | `general.notificationMethod` | How to send terminal notifications. | `"auto"` |
|
||||
| Enable Plan Mode | `general.plan.enabled` | Enable Plan Mode for read-only safety during planning. | `true` |
|
||||
| Plan Directory | `general.plan.directory` | The directory where planning artifacts are stored. If not specified, defaults to the system temporary directory. A custom directory requires a policy to allow write access in Plan Mode. | `undefined` |
|
||||
| Plan Model Routing | `general.plan.modelRouting` | Automatically switch between Pro and Flash models based on Plan Mode status. Uses Pro for the planning phase and Flash for the implementation phase. | `true` |
|
||||
| Retry Fetch Errors | `general.retryFetchErrors` | Retry on "exception TypeError: fetch failed sending request" errors. | `true` |
|
||||
| Max Chat Model Attempts | `general.maxAttempts` | Maximum number of attempts for requests to the main chat model. Cannot exceed 10. | `10` |
|
||||
| Debug Keystroke Logging | `general.debugKeystrokeLogging` | Enable debug logging of keystrokes to the console. | `false` |
|
||||
| Enable Session Cleanup | `general.sessionRetention.enabled` | Enable automatic session cleanup | `true` |
|
||||
| Keep chat history | `general.sessionRetention.maxAge` | Automatically delete chats older than this time period (e.g., "30d", "7d", "24h", "1w") | `"30d"` |
|
||||
| Topic & Update Narration | `general.topicUpdateNarration` | Enable the Topic & Update communication model for reduced chattiness and structured progress reporting. | `true` |
|
||||
| Log RAG Snippets | `general.logRagSnippets` | Log full Code Customization (RAG) retrieved snippets to a local file for debugging. | `false` |
|
||||
|
||||
### Output
|
||||
|
||||
| UI Label | Setting | Description | Default |
|
||||
| ------------- | --------------- | ------------------------------------------------------ | -------- |
|
||||
| Output Format | `output.format` | The format of the CLI output. Can be `text` or `json`. | `"text"` |
|
||||
|
||||
### UI
|
||||
|
||||
| UI Label | Setting | Description | Default |
|
||||
| ------------------------------------ | -------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------- |
|
||||
| Auto Theme Switching | `ui.autoThemeSwitching` | Automatically switch between default light and dark themes based on terminal background color. | `true` |
|
||||
| Terminal Background Polling Interval | `ui.terminalBackgroundPollingInterval` | Interval in seconds to poll the terminal background color. | `60` |
|
||||
| Hide Window Title | `ui.hideWindowTitle` | Hide the window title bar | `false` |
|
||||
| Inline Thinking | `ui.inlineThinkingMode` | Display model thinking inline: off or full. | `"off"` |
|
||||
| Show Thoughts in Title | `ui.showStatusInTitle` | Show Gemini CLI model thoughts in the terminal window title during the working phase | `false` |
|
||||
| Dynamic Window Title | `ui.dynamicWindowTitle` | Update the terminal window title with current status icons (Ready: ◇, Action Required: ✋, Working: ✦) | `true` |
|
||||
| Show Home Directory Warning | `ui.showHomeDirectoryWarning` | Show a warning when running Gemini CLI in the home directory. | `true` |
|
||||
| Show Compatibility Warnings | `ui.showCompatibilityWarnings` | Show warnings about terminal or OS compatibility issues. | `true` |
|
||||
| Hide Tips | `ui.hideTips` | Hide helpful tips in the UI | `false` |
|
||||
| Escape Pasted @ Symbols | `ui.escapePastedAtSymbols` | When enabled, @ symbols in pasted text are escaped to prevent unintended @path expansion. | `false` |
|
||||
| Show Shortcuts Hint | `ui.showShortcutsHint` | Show the "? for shortcuts" hint above the input. | `true` |
|
||||
| Compact Tool Output | `ui.compactToolOutput` | Display tool outputs (like directory listings and file reads) in a compact, structured format. | `true` |
|
||||
| Hide Banner | `ui.hideBanner` | Hide the application banner | `false` |
|
||||
| Hide Context Summary | `ui.hideContextSummary` | Hide the context summary (GEMINI.md, MCP servers) above the input. | `false` |
|
||||
| Hide CWD | `ui.footer.hideCWD` | Hide the current working directory in the footer. | `false` |
|
||||
| Hide Sandbox Status | `ui.footer.hideSandboxStatus` | Hide the sandbox status indicator in the footer. | `false` |
|
||||
| Hide Model Info | `ui.footer.hideModelInfo` | Hide the model name and context usage in the footer. | `false` |
|
||||
| Hide Context Window Percentage | `ui.footer.hideContextPercentage` | Hides the context window usage percentage. | `true` |
|
||||
| Hide Footer | `ui.hideFooter` | Hide the footer from the UI | `false` |
|
||||
| Show Memory Usage | `ui.showMemoryUsage` | Display memory usage information in the UI | `false` |
|
||||
| Show Line Numbers | `ui.showLineNumbers` | Show line numbers in the chat. | `true` |
|
||||
| Show Citations | `ui.showCitations` | Show citations for generated text in the chat. | `false` |
|
||||
| Show Model Info In Chat | `ui.showModelInfoInChat` | Show the model name in the chat for each model turn. | `false` |
|
||||
| Show User Identity | `ui.showUserIdentity` | Show the signed-in user's identity (e.g. email) in the UI. | `true` |
|
||||
| Use Alternate Screen Buffer | `ui.useAlternateBuffer` | Use an alternate screen buffer for the UI, preserving shell history. | `false` |
|
||||
| Render Process | `ui.renderProcess` | Enable Ink render process for the UI. | `true` |
|
||||
| Terminal Buffer | `ui.terminalBuffer` | Use the new terminal buffer architecture for rendering. | `false` |
|
||||
| Use Background Color | `ui.useBackgroundColor` | Whether to use background colors in the UI. | `true` |
|
||||
| Incremental Rendering | `ui.incrementalRendering` | Enable incremental rendering for the UI. This option will reduce flickering but may cause rendering artifacts. Only supported when useAlternateBuffer is enabled. | `true` |
|
||||
| Show Spinner | `ui.showSpinner` | Show the spinner during operations. | `true` |
|
||||
| Loading Phrases | `ui.loadingPhrases` | What to show while the model is working: tips, witty comments, all, or off. | `"off"` |
|
||||
| Error Verbosity | `ui.errorVerbosity` | Controls whether recoverable errors are hidden (low) or fully shown (full). | `"low"` |
|
||||
| Screen Reader Mode | `ui.accessibility.screenReader` | Render output in plain-text to be more screen reader accessible | `false` |
|
||||
|
||||
### IDE
|
||||
|
||||
| UI Label | Setting | Description | Default |
|
||||
| -------- | ------------- | ---------------------------- | ------- |
|
||||
| IDE Mode | `ide.enabled` | Enable IDE integration mode. | `false` |
|
||||
|
||||
### Billing
|
||||
|
||||
| UI Label | Setting | Description | Default |
|
||||
| ---------------- | ------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------- | ------- |
|
||||
| Overage Strategy | `billing.overageStrategy` | How to handle quota exhaustion when AI credits are available. 'ask' prompts each time, 'always' automatically uses credits, 'never' disables credit usage. | `"ask"` |
|
||||
|
||||
### Model
|
||||
|
||||
| UI Label | Setting | Description | Default |
|
||||
| ----------------------------- | ---------------------------- | -------------------------------------------------------------------------------------- | ----------- |
|
||||
| Model | `model.name` | The Gemini model to use for conversations. | `undefined` |
|
||||
| Max Session Turns | `model.maxSessionTurns` | Maximum number of user/model/tool turns to keep in a session. -1 means unlimited. | `-1` |
|
||||
| Context Compression Threshold | `model.compressionThreshold` | The fraction of context usage at which to trigger context compression (e.g. 0.2, 0.3). | `0.5` |
|
||||
| Disable Loop Detection | `model.disableLoopDetection` | Disable automatic detection and prevention of infinite loops. | `false` |
|
||||
| Skip Next Speaker Check | `model.skipNextSpeakerCheck` | Skip the next speaker check. | `true` |
|
||||
|
||||
### Agents
|
||||
|
||||
| UI Label | Setting | Description | Default |
|
||||
| ------------------------- | ---------------------------------------- | --------------------------------------------------------------------------------------------- | ------- |
|
||||
| Confirm Sensitive Actions | `agents.browser.confirmSensitiveActions` | Require manual confirmation for sensitive browser actions (e.g., fill_form, evaluate_script). | `false` |
|
||||
| Block File Uploads | `agents.browser.blockFileUploads` | Hard-block file upload requests from the browser agent. | `false` |
|
||||
|
||||
### Context
|
||||
|
||||
| UI Label | Setting | Description | Default |
|
||||
| ------------------------------------ | ------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------- |
|
||||
| Memory Discovery Max Dirs | `context.discoveryMaxDirs` | Maximum number of directories to search for memory. | `200` |
|
||||
| Load Memory From Include Directories | `context.loadMemoryFromIncludeDirectories` | Controls how /memory reload loads GEMINI.md files. When true, include directories are scanned; when false, only the current directory is used. | `false` |
|
||||
| Respect .gitignore | `context.fileFiltering.respectGitIgnore` | Respect .gitignore files when searching. | `true` |
|
||||
| Respect .geminiignore | `context.fileFiltering.respectGeminiIgnore` | Respect .geminiignore files when searching. | `true` |
|
||||
| Enable Recursive File Search | `context.fileFiltering.enableRecursiveFileSearch` | Enable recursive file search functionality when completing @ references in the prompt. | `true` |
|
||||
| Enable Fuzzy Search | `context.fileFiltering.enableFuzzySearch` | Enable fuzzy search when searching for files. | `true` |
|
||||
| Custom Ignore File Paths | `context.fileFiltering.customIgnoreFilePaths` | Additional ignore file paths to respect. These files take precedence over .geminiignore and .gitignore. Files earlier in the array take precedence over files later in the array, e.g. the first file takes precedence over the second one. | `[]` |
|
||||
|
||||
### Tools
|
||||
|
||||
| UI Label | Setting | Description | Default |
|
||||
| -------------------------------- | ------------------------------------ | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------- |
|
||||
| Sandbox Allowed Paths | `tools.sandboxAllowedPaths` | List of additional paths that the sandbox is allowed to access. | `[]` |
|
||||
| Sandbox Network Access | `tools.sandboxNetworkAccess` | Whether the sandbox is allowed to access the network. | `false` |
|
||||
| Enable Interactive Shell | `tools.shell.enableInteractiveShell` | Use node-pty for an interactive shell experience. Fallback to child_process still applies. | `true` |
|
||||
| Show Color | `tools.shell.showColor` | Show color in shell output. | `true` |
|
||||
| Use Ripgrep | `tools.useRipgrep` | Use ripgrep for file content search instead of the fallback implementation. Provides faster search performance. | `true` |
|
||||
| Tool Output Truncation Threshold | `tools.truncateToolOutputThreshold` | Maximum characters to show when truncating large tool outputs. Set to 0 or negative to disable truncation. | `40000` |
|
||||
| Disable LLM Correction | `tools.disableLLMCorrection` | Disable LLM-based error correction for edit tools. When enabled, tools will fail immediately if exact string matches are not found, instead of attempting to self-correct. | `true` |
|
||||
|
||||
### Security
|
||||
|
||||
| UI Label | Setting | Description | Default |
|
||||
| ------------------------------------- | ----------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | ------- |
|
||||
| Tool Sandboxing | `security.toolSandboxing` | Tool-level sandboxing. Isolates individual tools instead of the entire CLI process. | `false` |
|
||||
| Disable YOLO Mode | `security.disableYoloMode` | Disable YOLO mode, even if enabled by a flag. | `false` |
|
||||
| Disable Always Allow | `security.disableAlwaysAllow` | Disable "Always allow" options in tool confirmation dialogs. | `false` |
|
||||
| Allow Permanent Tool Approval | `security.enablePermanentToolApproval` | Enable the "Allow for all future sessions" option in tool confirmation dialogs. | `false` |
|
||||
| Auto-add to Policy by Default | `security.autoAddToPolicyByDefault` | When enabled, the "Allow for all future sessions" option becomes the default choice for low-risk tools in trusted workspaces. | `false` |
|
||||
| Blocks extensions from Git | `security.blockGitExtensions` | Blocks installing and loading extensions from Git. | `false` |
|
||||
| Extension Source Regex Allowlist | `security.allowedExtensions` | List of Regex patterns for allowed extensions. If nonempty, only extensions that match the patterns in this list are allowed. Overrides the blockGitExtensions setting. | `[]` |
|
||||
| Folder Trust | `security.folderTrust.enabled` | Setting to track whether Folder trust is enabled. | `true` |
|
||||
| Enable Environment Variable Redaction | `security.environmentVariableRedaction.enabled` | Enable redaction of environment variables that may contain secrets. | `false` |
|
||||
| Enable Context-Aware Security | `security.enableConseca` | Enable the context-aware security checker. This feature uses an LLM to dynamically generate and enforce security policies for tool use based on your prompt, providing an additional layer of protection against unintended actions. | `false` |
|
||||
|
||||
### Advanced
|
||||
|
||||
| UI Label | Setting | Description | Default |
|
||||
| --------------------------------- | ------------------------------ | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------- |
|
||||
| Auto Configure Max Old Space Size | `advanced.autoConfigureMemory` | Automatically configure Node.js memory limits. Note: Because memory is allocated during the initial process boot, this setting is only read from the global user settings file and ignores workspace-level overrides. | `true` |
|
||||
| Ignore Local .env | `advanced.ignoreLocalEnv` | Whether to ignore generic .env files in the project directory. | `false` |
|
||||
|
||||
### Experimental
|
||||
|
||||
| UI Label | Setting | Description | Default |
|
||||
| ---------------------------------------------------- | ----------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -------------------- |
|
||||
| Gemma Models | `experimental.gemma` | Enable access to Gemma 4 models via Gemini API. | `true` |
|
||||
| Voice Mode | `experimental.voiceMode` | Enable experimental voice dictation and commands (/voice, /voice model). | `false` |
|
||||
| Voice Activation Mode | `experimental.voice.activationMode` | How to trigger voice recording with the Space key. | `"push-to-talk"` |
|
||||
| Voice Transcription Backend | `experimental.voice.backend` | The backend to use for voice transcription. Note: When using the Gemini Live backend, voice recordings are sent to Google Cloud for transcription. | `"gemini-live"` |
|
||||
| Whisper Model | `experimental.voice.whisperModel` | The Whisper model to use for local transcription. | `"ggml-base.en.bin"` |
|
||||
| Voice Stop Grace Period (ms) | `experimental.voice.stopGracePeriodMs` | How long to wait for final transcription after stopping recording. | `4000` |
|
||||
| Enable Git Worktrees | `experimental.worktrees` | Enable automated Git worktree management for parallel work. | `false` |
|
||||
| Use OSC 52 Paste | `experimental.useOSC52Paste` | Use OSC 52 for pasting. This may be more robust than the default system when using remote terminal sessions (if your terminal is configured to allow it). | `false` |
|
||||
| Use OSC 52 Copy | `experimental.useOSC52Copy` | Use OSC 52 for copying. This may be more robust than the default system when using remote terminal sessions (if your terminal is configured to allow it). | `false` |
|
||||
| Model Steering | `experimental.modelSteering` | Enable model steering (user hints) to guide the model during tool execution. | `false` |
|
||||
| Direct Web Fetch | `experimental.directWebFetch` | Enable web fetch behavior that bypasses LLM summarization. | `false` |
|
||||
| Enable Gemma Model Router | `experimental.gemmaModelRouter.enabled` | Enable the Gemma Model Router (experimental). Requires a local endpoint serving Gemma via the Gemini API using LiteRT-LM shim. | `false` |
|
||||
| Auto-start LiteRT Server | `experimental.gemmaModelRouter.autoStartServer` | Automatically start the LiteRT-LM server when Gemini CLI starts and the Gemma router is enabled. | `false` |
|
||||
| Auto Memory | `experimental.autoMemory` | Automatically extract memory patches and skills from past sessions in the background. Every change is written as a unified diff `.patch` file under `<projectMemoryDir>/.inbox/<kind>/` and held for review in /memory inbox; nothing is applied until you approve it. | `false` |
|
||||
| Use the generalist profile to manage agent contexts. | `experimental.generalistProfile` | Suitable for general coding and software development tasks. | `false` |
|
||||
| Enable Context Management | `experimental.contextManagement` | Enable logic for context management. | `false` |
|
||||
|
||||
### Skills
|
||||
|
||||
| UI Label | Setting | Description | Default |
|
||||
| ------------------- | ---------------- | -------------------- | ------- |
|
||||
| Enable Agent Skills | `skills.enabled` | Enable Agent Skills. | `true` |
|
||||
|
||||
### HooksConfig
|
||||
|
||||
| UI Label | Setting | Description | Default |
|
||||
| ------------------ | --------------------------- | -------------------------------------------------------------------------------- | ------- |
|
||||
| Enable Hooks | `hooksConfig.enabled` | Canonical toggle for the hooks system. When disabled, no hooks will be executed. | `true` |
|
||||
| Hook Notifications | `hooksConfig.notifications` | Show visual indicators when hooks are executing. | `true` |
|
||||
|
||||
<!-- SETTINGS-AUTOGEN:END -->
|
||||
@@ -0,0 +1,78 @@
|
||||
# Agent Skill best practices
|
||||
|
||||
Create high-quality, reliable Agent Skills by following these established design
|
||||
principles and patterns.
|
||||
|
||||
## Design for discovery
|
||||
|
||||
The most important part of a skill is its `description`. This is the only
|
||||
information the model has before activation.
|
||||
|
||||
- **Be specific**: Use keywords that are likely to appear in user prompts (for
|
||||
example, "audit," "security," "refactor," "migration").
|
||||
- **Define the trigger**: Clearly state _when_ the skill should be used (for
|
||||
example, "Use this skill when the user asks to review a PR for performance
|
||||
regressions").
|
||||
- **Avoid overlap**: Ensure your skill descriptions are distinct from one
|
||||
another and from the general capabilities of the model.
|
||||
|
||||
## Progressive disclosure
|
||||
|
||||
The "context window" is a shared resource. Use a three-level loading system to
|
||||
manage context efficiently.
|
||||
|
||||
1. **Metadata (name + description)**: Always in context (~100 words).
|
||||
2. **`SKILL.md` body**: Loaded only after the skill triggers (<5k words).
|
||||
3. **Bundled resources**: Loaded only as needed by the model.
|
||||
|
||||
**Best practice**: Keep the `SKILL.md` body focused on core procedural
|
||||
instructions. Move detailed reference material, schemas, and examples into
|
||||
separate files in a `references/` directory.
|
||||
|
||||
## Degrees of freedom
|
||||
|
||||
Match the level of instruction specificity to the task's fragility.
|
||||
|
||||
- **High freedom (text-based instructions)**: Use when multiple approaches are
|
||||
valid or decisions depend heavily on context.
|
||||
- **Medium freedom (pseudocode or scripts with parameters)**: Use when a
|
||||
preferred pattern exists but some variation is acceptable.
|
||||
- **Low freedom (specific scripts, few parameters)**: Use when operations are
|
||||
fragile and error-prone, or a specific sequence MUST be followed.
|
||||
|
||||
## Bundle resources effectively
|
||||
|
||||
Leverage the skill's ability to include scripts and assets to extend the agent's
|
||||
capabilities.
|
||||
|
||||
- **Use scripts for deterministic tasks**: If a task can be automated with a
|
||||
script (for example, running a linter, fetching data from an API), bundle it
|
||||
in the `scripts/` folder.
|
||||
- **Agentic ergonomics**: Ensure scripts output LLM-friendly stdout. Suppress
|
||||
verbose tracebacks and provide clear, concise success/failure messages.
|
||||
- **Provide templates**: Include common file headers or boilerplate code in the
|
||||
`assets/` folder to ensure the agent produces consistent output.
|
||||
|
||||
## Anatomy of a great skill
|
||||
|
||||
A well-structured skill directory organizes its resources into specialized
|
||||
sub-folders.
|
||||
|
||||
```text
|
||||
my-skill/
|
||||
├── SKILL.md (Required) Core instructions and metadata
|
||||
├── scripts/ (Optional) Executable logic (Node.js, Python, etc.)
|
||||
├── references/ (Optional) Documentation to be loaded as needed
|
||||
└── assets/ (Optional) Templates and non-executable resources
|
||||
```
|
||||
|
||||
## Security and privacy
|
||||
|
||||
Design your skills with security in mind to protect your workspace and data.
|
||||
|
||||
- **Avoid hardcoded secrets**: Never include API keys or passwords in your
|
||||
skill's scripts or documentation.
|
||||
- **Review third-party skills**: Inspect the `SKILL.md` and scripts of any skill
|
||||
before installing it from an untrusted source.
|
||||
- **Limit scope**: Design skills to be as focused as possible to minimize the
|
||||
potential impact of errors.
|
||||
@@ -0,0 +1,141 @@
|
||||
# Agent Skills
|
||||
|
||||
Agent Skills let you extend Gemini CLI with specialized expertise, procedural
|
||||
workflows, and task-specific resources. Based on the
|
||||
[Agent Skills](https://agentskills.io) open standard, a "skill" is a
|
||||
self-contained directory that packages instructions and assets into a
|
||||
discoverable capability.
|
||||
|
||||
Unlike general context files ([GEMINI.md](./gemini-md.md)), which provide
|
||||
persistent workspace-wide background, Skills represent **on-demand expertise**.
|
||||
This lets Gemini CLI maintain a vast library of specialized capabilities—such as
|
||||
security auditing, cloud deployments, or codebase migrations—without cluttering
|
||||
the model's immediate context window.
|
||||
|
||||
## How it works
|
||||
|
||||
The lifecycle of an Agent Skill involves discovery, activation, and conditional
|
||||
resource access.
|
||||
|
||||
1. **Discovery**: At the start of a session, Gemini CLI scans the discovery
|
||||
tiers and injects the name and description of all enabled skills into the
|
||||
system prompt.
|
||||
2. **Activation**: When Gemini identifies a task matching a skill's
|
||||
description, it calls the `activate_skill` tool.
|
||||
3. **Consent**: You will see a confirmation prompt in the UI detailing the
|
||||
skill's name, purpose, and the directory path it will gain access to.
|
||||
4. **Injection**: Upon your approval:
|
||||
- The `SKILL.md` body and folder structure is added to the conversation
|
||||
history.
|
||||
- The skill's directory is added to the agent's allowed file paths, granting
|
||||
it permission to read any bundled assets.
|
||||
5. **Execution**: The model proceeds with the specialized expertise active. It
|
||||
is instructed to prioritize the skill's procedural guidance within reason.
|
||||
|
||||
## Discovery tiers
|
||||
|
||||
Gemini CLI discovers skills from several locations, following a specific order
|
||||
of precedence (lowest to highest):
|
||||
|
||||
1. **Built-in skills**: Standard skills included with Gemini CLI that provide
|
||||
foundational capabilities.
|
||||
2. **Extension skills**: Skills bundled within installed
|
||||
[extensions](../extensions/index.md).
|
||||
3. **User skills**: Located in `~/.gemini/skills/` or the `~/.agents/skills/`
|
||||
alias.
|
||||
4. **Workspace skills**: Located in `.gemini/skills/` or the `.agents/skills/`
|
||||
alias. Workspace skills are shared with your team via version control.
|
||||
|
||||
### Precedence and aliases
|
||||
|
||||
If multiple skills share the same name, the version from the higher-precedence
|
||||
location is used. Within the same tier (user or workspace), the
|
||||
`.agents/skills/` alias takes precedence over the `.gemini/skills/` directory.
|
||||
|
||||
The `.agents/skills/` alias provides an interoperable path for managing
|
||||
agent-specific expertise that remains compatible across different AI tools.
|
||||
|
||||
## Key benefits
|
||||
|
||||
Agent Skills provide several advantages for managing specialized knowledge and
|
||||
complex workflows.
|
||||
|
||||
- **Shared expertise**: Package complex workflows (like a specific team's PR
|
||||
review process) into a folder that anyone can use.
|
||||
- **Repeatable workflows**: Ensure complex multi-step tasks are performed
|
||||
consistently by providing a procedural framework.
|
||||
- **Resource bundling**: Include scripts, templates, or example data alongside
|
||||
instructions so the agent has everything it needs.
|
||||
- **Progressive disclosure**: Only skill metadata (name and description) is
|
||||
loaded initially. Detailed instructions and resources are only disclosed when
|
||||
the model explicitly activates the skill, saving context tokens.
|
||||
|
||||
<!-- prettier-ignore -->
|
||||
> [!NOTE]
|
||||
> `/skills disable` and `/skills enable` default to the `user` scope. Use
|
||||
> `--scope workspace` to manage workspace-specific settings.
|
||||
|
||||
To see all available skills in your current session, use the `/skills list`
|
||||
command.
|
||||
|
||||
## Managing skills
|
||||
|
||||
You can manage Agent Skills through interactive session commands or directly
|
||||
from your terminal.
|
||||
|
||||
### In an interactive session
|
||||
|
||||
Use the `/skills` slash command to view and manage available expertise:
|
||||
|
||||
- `/skills list [all] [nodesc]`: Shows discovered skills. Use `all` to include
|
||||
built-in skills and `nodesc` to hide descriptions.
|
||||
- `/skills link <path> [--scope user|workspace]`: Links skills from a local
|
||||
directory.
|
||||
- `/skills disable <name>`: Prevents a specific skill from being used.
|
||||
- `/skills enable <name>`: Re-enables a disabled skill.
|
||||
- `/skills reload` (or `/skills refresh`): Refreshes the list of discovered
|
||||
skills from all tiers.
|
||||
|
||||
### From the terminal
|
||||
|
||||
The `gemini skills` command provides management utilities:
|
||||
|
||||
```bash
|
||||
# List all discovered skills. Use --all to include built-in skills.
|
||||
gemini skills list --all
|
||||
|
||||
# Install a skill from a Git repository or local directory.
|
||||
# Use --consent to skip the security confirmation prompt.
|
||||
gemini skills install https://github.com/user/repo.git --consent
|
||||
|
||||
# Uninstall a skill.
|
||||
gemini skills uninstall my-skill --scope workspace
|
||||
```
|
||||
|
||||
#### Command options
|
||||
|
||||
The skill management commands support several global and command-specific
|
||||
options.
|
||||
|
||||
- `--scope`: Either `user` (global, default) or `workspace` (local to the
|
||||
project).
|
||||
- `--path`: The sub-directory within a Git repository containing the skill.
|
||||
- `--consent`: Acknowledge security risks and skip the interactive confirmation
|
||||
during installation.
|
||||
|
||||
For more details on CLI commands, see the
|
||||
[CLI reference](./cli-reference.md#skills-management).
|
||||
|
||||
## Next steps
|
||||
|
||||
Explore these resources to refine your skills and understand the framework
|
||||
better.
|
||||
|
||||
- [Get started with Agent Skills](./tutorials/skills-getting-started.md): A
|
||||
quick walkthrough of triggering and using skills.
|
||||
- [Creating Agent Skills](./creating-skills.md): Create your first skill and
|
||||
bundle custom logic.
|
||||
- [Using Agent Skills](./using-agent-skills.md): Learn how to leverage built-in
|
||||
and custom skills.
|
||||
- [Best practices](./skills-best-practices.md): Learn strategies for building
|
||||
effective skills.
|
||||
@@ -0,0 +1,129 @@
|
||||
# System Prompt Override (GEMINI_SYSTEM_MD)
|
||||
|
||||
The core system instructions that guide Gemini CLI can be completely replaced
|
||||
with your own Markdown file. This feature is controlled via the
|
||||
`GEMINI_SYSTEM_MD` environment variable.
|
||||
|
||||
## Overview
|
||||
|
||||
The `GEMINI_SYSTEM_MD` variable instructs the CLI to use an external Markdown
|
||||
file for its system prompt, completely overriding the built-in default. This is
|
||||
a full replacement, not a merge. If you use a custom file, none of the original
|
||||
core instructions will apply unless you include them yourself.
|
||||
|
||||
This feature is intended for advanced users who need to enforce strict,
|
||||
project-specific behavior or create a customized persona.
|
||||
|
||||
<!-- prettier-ignore -->
|
||||
> [!TIP]
|
||||
> You can export the current default system prompt to a file first, review
|
||||
> it, and then selectively modify or replace it (see
|
||||
> [“Export the default prompt”](#export-the-default-prompt-recommended)).
|
||||
|
||||
## How to enable
|
||||
|
||||
You can set the environment variable temporarily in your shell, or persist it
|
||||
via a `.gemini/.env` file. See
|
||||
[Persisting Environment Variables](../get-started/authentication.mdx#persisting-environment-variables).
|
||||
|
||||
- Use the project default path (`.gemini/system.md`):
|
||||
|
||||
- `GEMINI_SYSTEM_MD=true` or `GEMINI_SYSTEM_MD=1`
|
||||
- The CLI reads `./.gemini/system.md` (relative to your current project
|
||||
directory).
|
||||
|
||||
- Use a custom file path:
|
||||
|
||||
- `GEMINI_SYSTEM_MD=/absolute/path/to/my-system.md`
|
||||
- Relative paths are supported and resolved from the current working
|
||||
directory.
|
||||
- Tilde expansion is supported (for example, `~/my-system.md`).
|
||||
|
||||
- Disable the override (use built‑in prompt):
|
||||
- `GEMINI_SYSTEM_MD=false` or `GEMINI_SYSTEM_MD=0` or unset the variable.
|
||||
|
||||
If the override is enabled but the target file does not exist, the CLI will
|
||||
error with: `missing system prompt file '<path>'`.
|
||||
|
||||
## Quick examples
|
||||
|
||||
- One‑off session using a project file:
|
||||
- `GEMINI_SYSTEM_MD=1 gemini`
|
||||
- Persist for a project using `.gemini/.env`:
|
||||
- Create `.gemini/system.md`, then add to `.gemini/.env`:
|
||||
- `GEMINI_SYSTEM_MD=1`
|
||||
- Use a custom file under your home directory:
|
||||
- `GEMINI_SYSTEM_MD=~/prompts/system.md gemini`
|
||||
|
||||
## UI indicator
|
||||
|
||||
When `GEMINI_SYSTEM_MD` is active, the CLI shows a `|⌐■_■|` indicator in the UI
|
||||
to signal custom system‑prompt mode.
|
||||
|
||||
## Variable Substitution
|
||||
|
||||
When using a custom system prompt file, you can use the following variables to
|
||||
dynamically include built-in content:
|
||||
|
||||
- `${AgentSkills}`: Injects a complete section (including header) of all
|
||||
available agent skills.
|
||||
- `${SubAgents}`: Injects a complete section (including header) of available
|
||||
sub-agents.
|
||||
- `${AvailableTools}`: Injects a bulleted list of all currently enabled tool
|
||||
names.
|
||||
- Tool Name Variables: Injects the actual name of a tool using the pattern:
|
||||
`${toolName}_ToolName` (for example, `${write_file_ToolName}`,
|
||||
`${run_shell_command_ToolName}`).
|
||||
|
||||
This pattern is generated dynamically for all available tools.
|
||||
|
||||
### Example
|
||||
|
||||
```markdown
|
||||
# Custom System Prompt
|
||||
|
||||
You are a helpful assistant. ${AgentSkills}
|
||||
${SubAgents}
|
||||
|
||||
## Tooling
|
||||
|
||||
The following tools are available to you: ${AvailableTools}
|
||||
|
||||
You can use ${write_file_ToolName} to save logs.
|
||||
```
|
||||
|
||||
## Export the default prompt (recommended)
|
||||
|
||||
Before overriding, export the current default prompt so you can review required
|
||||
safety and workflow rules.
|
||||
|
||||
- Write the built‑in prompt to the project default path:
|
||||
- `GEMINI_WRITE_SYSTEM_MD=1 gemini`
|
||||
- Or write to a custom path:
|
||||
- `GEMINI_WRITE_SYSTEM_MD=~/prompts/DEFAULT_SYSTEM.md gemini`
|
||||
|
||||
This creates the file and writes the current built‑in system prompt to it.
|
||||
|
||||
## Best practices: system.md vs GEMINI.md
|
||||
|
||||
- system.md (firmware):
|
||||
- Non‑negotiable operational rules: safety, tool‑use protocols, approvals, and
|
||||
mechanics that keep the CLI reliable.
|
||||
- Stable across tasks and projects (or per project when needed).
|
||||
- GEMINI.md (strategy):
|
||||
- Persona, goals, methodologies, and project/domain context.
|
||||
- Evolves per task; relies on system.md for safe execution.
|
||||
|
||||
Keep system.md minimal but complete for safety and tool operation. Keep
|
||||
GEMINI.md focused on high‑level guidance and project specifics.
|
||||
|
||||
## Troubleshooting
|
||||
|
||||
- Error: `missing system prompt file '…'`
|
||||
- Ensure the referenced path exists and is readable.
|
||||
- For `GEMINI_SYSTEM_MD=1|true`, create `./.gemini/system.md` in your project.
|
||||
- Override not taking effect
|
||||
- Confirm the variable is loaded (use `.gemini/.env` or export in your shell).
|
||||
- Paths are resolved from the current working directory; try an absolute path.
|
||||
- Restore defaults
|
||||
- Unset `GEMINI_SYSTEM_MD` or set it to `0`/`false`.
|
||||
File diff suppressed because it is too large
Load Diff
@@ -0,0 +1,288 @@
|
||||
# Themes
|
||||
|
||||
Gemini CLI supports a variety of themes to customize its color scheme and
|
||||
appearance. You can change the theme to suit your preferences via the `/theme`
|
||||
command or `"theme":` configuration setting.
|
||||
|
||||
## Available themes
|
||||
|
||||
Gemini CLI comes with a selection of pre-defined themes, which you can list
|
||||
using the `/theme` command within Gemini CLI:
|
||||
|
||||
- **Dark themes:**
|
||||
- `ANSI`
|
||||
- `Atom One`
|
||||
- `Ayu`
|
||||
- `Default`
|
||||
- `Dracula`
|
||||
- `GitHub`
|
||||
- `Holiday`
|
||||
- `Shades Of Purple`
|
||||
- `Solarized Dark`
|
||||
- `Tokyo Night`
|
||||
- **Light themes:**
|
||||
- `ANSI Light`
|
||||
- `Ayu Light`
|
||||
- `Default Light`
|
||||
- `GitHub Light`
|
||||
- `Google Code`
|
||||
- `Solarized Light`
|
||||
- `Xcode`
|
||||
|
||||
### Changing themes
|
||||
|
||||
1. Enter `/theme` into Gemini CLI.
|
||||
2. A dialog or selection prompt appears, listing the available themes.
|
||||
3. Using the arrow keys, select a theme. Some interfaces might offer a live
|
||||
preview or highlight as you select.
|
||||
4. Confirm your selection to apply the theme.
|
||||
|
||||
<!-- prettier-ignore -->
|
||||
> [!NOTE]
|
||||
> If a theme is defined in your `settings.json` file (either by name or
|
||||
> by a file path), you must remove the `"theme"` setting from the file before
|
||||
> you can change the theme using the `/theme` command.
|
||||
|
||||
### Theme persistence
|
||||
|
||||
Selected themes are saved in Gemini CLI's
|
||||
[configuration](../reference/configuration.md) so your preference is remembered
|
||||
across sessions.
|
||||
|
||||
---
|
||||
|
||||
## Custom color themes
|
||||
|
||||
Gemini CLI lets you create your own custom color themes by specifying them in
|
||||
your `settings.json` file. This gives you full control over the color palette
|
||||
used in the CLI.
|
||||
|
||||
### How to define a custom theme
|
||||
|
||||
Add a `customThemes` block to your user, project, or system `settings.json`
|
||||
file. Each custom theme is defined as an object with a unique name and a set of
|
||||
nested configuration objects. For example:
|
||||
|
||||
```json
|
||||
{
|
||||
"ui": {
|
||||
"customThemes": {
|
||||
"MyCustomTheme": {
|
||||
"name": "MyCustomTheme",
|
||||
"type": "custom",
|
||||
"background": {
|
||||
"primary": "#181818"
|
||||
},
|
||||
"text": {
|
||||
"primary": "#f0f0f0",
|
||||
"secondary": "#a0a0a0"
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
**Configuration objects:**
|
||||
|
||||
- **`text`**: Defines text colors.
|
||||
- `primary`: The default text color.
|
||||
- `secondary`: Used for less prominent text.
|
||||
- `link`: Color for URLs and links.
|
||||
- `accent`: Used for highlights and emphasis.
|
||||
- `response`: Precedence over `primary` for rendering model responses.
|
||||
- **`background`**: Defines background colors.
|
||||
- `primary`: The main background color of the UI.
|
||||
- `diff.added`: Background for added lines in diffs.
|
||||
- `diff.removed`: Background for removed lines in diffs.
|
||||
- **`border`**: Defines border colors.
|
||||
- `default`: The standard border color.
|
||||
- `focused`: Border color when an element is focused.
|
||||
- **`status`**: Colors for status indicators.
|
||||
- `success`: Used for successful operations.
|
||||
- `warning`: Used for warnings.
|
||||
- `error`: Used for errors.
|
||||
- **`ui`**: Other UI elements.
|
||||
- `comment`: Color for code comments.
|
||||
- `symbol`: Color for code symbols and operators.
|
||||
- `gradient`: An array of colors used for gradient effects.
|
||||
|
||||
**Required properties:**
|
||||
|
||||
- `name` (must match the key in the `customThemes` object and be a string)
|
||||
- `type` (must be the string `"custom"`)
|
||||
|
||||
While all sub-properties are technically optional, we recommend providing at
|
||||
least `background.primary`, `text.primary`, `text.secondary`, and the various
|
||||
accent colors via `text.link`, `text.accent`, and `status` to ensure a cohesive
|
||||
UI.
|
||||
|
||||
You can use either hex codes (for example, `#FF0000`) **or** standard CSS color
|
||||
names (for example, `coral`, `teal`, `blue`) for any color value. See
|
||||
[CSS color names](https://developer.mozilla.org/en-US/docs/Web/CSS/color_value#color_keywords)
|
||||
for a full list of supported names.
|
||||
|
||||
You can define multiple custom themes by adding more entries to the
|
||||
`customThemes` object.
|
||||
|
||||
### Loading themes from a file
|
||||
|
||||
In addition to defining custom themes in `settings.json`, you can also load a
|
||||
theme directly from a JSON file by specifying the file path in your
|
||||
`settings.json`. This is useful for sharing themes or keeping them separate from
|
||||
your main configuration.
|
||||
|
||||
To load a theme from a file, set the `theme` property in your `settings.json` to
|
||||
the path of your theme file:
|
||||
|
||||
```json
|
||||
{
|
||||
"ui": {
|
||||
"theme": "/path/to/your/theme.json"
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
The theme file must be a valid JSON file that follows the same structure as a
|
||||
custom theme defined in `settings.json`.
|
||||
|
||||
**Example `my-theme.json`:**
|
||||
|
||||
```json
|
||||
{
|
||||
"name": "Gruvbox Dark",
|
||||
"type": "custom",
|
||||
"background": {
|
||||
"primary": "#282828",
|
||||
"diff": {
|
||||
"added": "#2b3312",
|
||||
"removed": "#341212"
|
||||
}
|
||||
},
|
||||
"text": {
|
||||
"primary": "#ebdbb2",
|
||||
"secondary": "#a89984",
|
||||
"link": "#83a598",
|
||||
"accent": "#d3869b"
|
||||
},
|
||||
"border": {
|
||||
"default": "#3c3836",
|
||||
"focused": "#458588"
|
||||
},
|
||||
"status": {
|
||||
"success": "#b8bb26",
|
||||
"warning": "#fabd2f",
|
||||
"error": "#fb4934"
|
||||
},
|
||||
"ui": {
|
||||
"comment": "#928374",
|
||||
"symbol": "#8ec07c",
|
||||
"gradient": ["#cc241d", "#d65d0e", "#d79921"]
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
<!-- prettier-ignore -->
|
||||
> [!WARNING]
|
||||
> For your safety, Gemini CLI will only load theme files that
|
||||
> are located within your home directory. If you attempt to load a theme from
|
||||
> outside your home directory, a warning will be displayed and the theme will
|
||||
> not be loaded. This is to prevent loading potentially malicious theme files
|
||||
> from untrusted sources.
|
||||
|
||||
### Example custom theme
|
||||
|
||||
<img src="/docs/assets/theme-custom.png" alt="Custom theme example" width="600" />
|
||||
|
||||
### Using your custom theme
|
||||
|
||||
- Select your custom theme using the `/theme` command in Gemini CLI. Your custom
|
||||
theme will appear in the theme selection dialog.
|
||||
- Or, set it as the default by adding `"theme": "MyCustomTheme"` to the `ui`
|
||||
object in your `settings.json`.
|
||||
- Custom themes can be set at the user, project, or system level, and follow the
|
||||
same [configuration precedence](../reference/configuration.md) as other
|
||||
settings.
|
||||
|
||||
### Themes from extensions
|
||||
|
||||
[Extensions](../extensions/reference.md#themes) can also provide custom themes.
|
||||
Once an extension is installed and enabled, its themes are automatically added
|
||||
to the selection list in the `/theme` command.
|
||||
|
||||
Themes from extensions appear with the extension name in parentheses to help you
|
||||
identify their source, for example: `shades-of-green (green-extension)`.
|
||||
|
||||
---
|
||||
|
||||
## Dark themes
|
||||
|
||||
### ANSI
|
||||
|
||||
<img src="/docs/assets/theme-ansi-dark.png" alt="ANSI theme" width="600">
|
||||
|
||||
### Atom One
|
||||
|
||||
<img src="/docs/assets/theme-atom-one-dark.png" alt="Atom One theme" width="600">
|
||||
|
||||
### Ayu
|
||||
|
||||
<img src="/docs/assets/theme-ayu-dark.png" alt="Ayu theme" width="600">
|
||||
|
||||
### Default
|
||||
|
||||
<img src="/docs/assets/theme-default-dark.png" alt="Default theme" width="600">
|
||||
|
||||
### Dracula
|
||||
|
||||
<img src="/docs/assets/theme-dracula-dark.png" alt="Dracula theme" width="600">
|
||||
|
||||
### GitHub
|
||||
|
||||
<img src="/docs/assets/theme-github-dark.png" alt="GitHub theme" width="600">
|
||||
|
||||
### Holiday
|
||||
|
||||
<img src="/docs/assets/theme-holiday-dark.png" alt="Holiday theme" width="600">
|
||||
|
||||
### Shades Of Purple
|
||||
|
||||
<img src="/docs/assets/theme-shades-of-purple-dark.png" alt="Shades Of Purple theme" width="600">
|
||||
|
||||
### Solarized Dark
|
||||
|
||||
<img src="/docs/assets/theme-solarized-dark.png" alt="Solarized Dark theme" width="600">
|
||||
|
||||
### Tokyo Night
|
||||
|
||||
<img src="/docs/assets/theme-tokyonight-dark.png" alt="Tokyo Night theme" width="600">
|
||||
|
||||
## Light themes
|
||||
|
||||
### ANSI Light
|
||||
|
||||
<img src="/docs/assets/theme-ansi-light.png" alt="ANSI Light theme" width="600">
|
||||
|
||||
### Ayu Light
|
||||
|
||||
<img src="/docs/assets/theme-ayu-light.png" alt="Ayu Light theme" width="600">
|
||||
|
||||
### Default Light
|
||||
|
||||
<img src="/docs/assets/theme-default-light.png" alt="Default Light theme" width="600">
|
||||
|
||||
### GitHub Light
|
||||
|
||||
<img src="/docs/assets/theme-github-light.png" alt="GitHub Light theme" width="600">
|
||||
|
||||
### Google Code
|
||||
|
||||
<img src="/docs/assets/theme-google-light.png" alt="Google Code theme" width="600">
|
||||
|
||||
### Solarized Light
|
||||
|
||||
<img src="/docs/assets/theme-solarized-light.png" alt="Solarized Light theme" width="600">
|
||||
|
||||
### Xcode
|
||||
|
||||
<img src="/docs/assets/theme-xcode-light.png" alt="Xcode Light theme" width="600">
|
||||
@@ -0,0 +1,20 @@
|
||||
# Token caching and cost optimization
|
||||
|
||||
Gemini CLI automatically optimizes API costs through token caching when using
|
||||
API key authentication (Gemini API key or Vertex AI). This feature reuses
|
||||
previous system instructions and context to reduce the number of tokens
|
||||
processed in subsequent requests.
|
||||
|
||||
**Token caching is available for:**
|
||||
|
||||
- API key users (Gemini API key)
|
||||
- Vertex AI users (with project and location setup)
|
||||
|
||||
**Token caching is not available for:**
|
||||
|
||||
- OAuth users (Google Personal/Enterprise accounts) - the Code Assist API does
|
||||
not support cached content creation at this time
|
||||
|
||||
You can view your token usage and cached token savings using the `/stats`
|
||||
command. When cached tokens are available, they will be displayed in the stats
|
||||
output.
|
||||
@@ -0,0 +1,154 @@
|
||||
# Trusted Folders
|
||||
|
||||
The Trusted Folders feature is a security setting that gives you control over
|
||||
which projects can use the full capabilities of Gemini CLI. It prevents
|
||||
potentially malicious code from running by asking you to approve a folder before
|
||||
the CLI loads any project-specific configurations from it.
|
||||
|
||||
## Enabling the feature
|
||||
|
||||
The Trusted Folders feature is **disabled by default**. To use it, you must
|
||||
first enable it in your settings.
|
||||
|
||||
Add the following to your user `settings.json` file:
|
||||
|
||||
```json
|
||||
{
|
||||
"security": {
|
||||
"folderTrust": {
|
||||
"enabled": true
|
||||
}
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
## How it works: The trust dialog
|
||||
|
||||
Once the feature is enabled, the first time you run Gemini CLI from a folder, a
|
||||
dialog will automatically appear, prompting you to make a choice:
|
||||
|
||||
- **Trust folder**: Grants full trust to the current folder (for example,
|
||||
`my-project`).
|
||||
- **Trust parent folder**: Grants trust to the parent directory (for example,
|
||||
`safe-projects`), which automatically trusts all of its subdirectories as
|
||||
well. This is useful if you keep all your safe projects in one place.
|
||||
- **Don't trust**: Marks the folder as untrusted. The CLI will operate in a
|
||||
restricted "safe mode."
|
||||
|
||||
Your choice is saved in a central file (`~/.gemini/trustedFolders.json`), so you
|
||||
will only be asked once per folder.
|
||||
|
||||
## Understanding folder contents: The discovery phase
|
||||
|
||||
Before you make a choice, Gemini CLI performs a **discovery phase** to scan the
|
||||
folder for potential configurations. This information is displayed in the trust
|
||||
dialog to help you make an informed decision.
|
||||
|
||||
The discovery UI lists the following categories of items found in the project:
|
||||
|
||||
- **Commands**: Custom `.toml` command definitions that add new functionality.
|
||||
- **MCP Servers**: Configured Model Context Protocol servers that the CLI will
|
||||
attempt to connect to.
|
||||
- **Hooks**: System or custom hooks that can intercept and modify CLI behavior.
|
||||
- **Skills**: Local agent skills that provide specialized capabilities.
|
||||
- **Setting overrides**: Any project-specific configurations that override your
|
||||
global user settings.
|
||||
|
||||
### Security warnings and errors
|
||||
|
||||
The trust dialog also highlights critical information that requires your
|
||||
attention:
|
||||
|
||||
- **Security Warnings**: The CLI will explicitly flag potentially dangerous
|
||||
settings, such as auto-approving certain tools or disabling the security
|
||||
sandbox.
|
||||
- **Discovery Errors**: If the CLI encounters issues while scanning the folder
|
||||
(for example, a malformed `settings.json` file), these errors will be
|
||||
displayed prominently.
|
||||
|
||||
By reviewing these details, you can ensure that you only grant trust to projects
|
||||
that you know are safe.
|
||||
|
||||
## Why trust matters: The impact of an untrusted workspace
|
||||
|
||||
When a folder is **untrusted**, Gemini CLI runs in a restricted "safe mode" to
|
||||
protect you. In this mode, the following features are disabled:
|
||||
|
||||
1. **Workspace settings are ignored**: The CLI will **not** load the
|
||||
`.gemini/settings.json` file from the project. This prevents the loading of
|
||||
custom tools and other potentially dangerous configurations.
|
||||
|
||||
2. **Environment variables are ignored**: The CLI will **not** load any `.env`
|
||||
files from the project.
|
||||
|
||||
3. **Extension management is restricted**: You **cannot install, update, or
|
||||
uninstall** extensions.
|
||||
|
||||
4. **Tool auto-acceptance is disabled**: You will always be prompted before any
|
||||
tool is run, even if you have auto-acceptance enabled globally.
|
||||
|
||||
5. **Automatic memory loading is disabled**: The CLI will not automatically
|
||||
load files into context from directories specified in local settings.
|
||||
|
||||
6. **MCP servers do not connect**: The CLI will not attempt to connect to any
|
||||
[Model Context Protocol (MCP)](../tools/mcp-server.md) servers.
|
||||
|
||||
7. **Custom commands are not loaded**: The CLI will not load any custom
|
||||
commands from .toml files, including both project-specific and global user
|
||||
commands.
|
||||
|
||||
Granting trust to a folder unlocks the full functionality of Gemini CLI for that
|
||||
workspace.
|
||||
|
||||
## Headless and automated environments
|
||||
|
||||
When running Gemini CLI in a headless environment (for example, a CI/CD
|
||||
pipeline) where interactive prompts are not possible, the trust dialog cannot be
|
||||
displayed. If the folder is untrusted and the Folder Trust feature is enabled,
|
||||
the CLI will throw a `FatalUntrustedWorkspaceError` and exit.
|
||||
|
||||
To proceed in these environments, you can bypass the trust check using one of
|
||||
the following methods:
|
||||
|
||||
- **Command-line flag:** Run the CLI with the `--skip-trust` flag.
|
||||
- **Environment variable:** Set the `GEMINI_CLI_TRUST_WORKSPACE=true`
|
||||
environment variable.
|
||||
|
||||
These methods will trust the current workspace for the duration of the session
|
||||
without prompting.
|
||||
|
||||
For detailed instructions on managing folder trust within CI/CD workflows,
|
||||
review the
|
||||
[Gemini CLI trust guidance for GitHub Actions](https://github.com/google-github-actions/run-gemini-cli/blob/main/docs/trust-guidance.md).
|
||||
|
||||
## Overriding the trust file location
|
||||
|
||||
By default, trust settings are saved to `~/.gemini/trustedFolders.json`. If you
|
||||
need to store this file in a different location, you can set the
|
||||
`GEMINI_CLI_TRUSTED_FOLDERS_PATH` environment variable to the desired absolute
|
||||
file path.
|
||||
|
||||
## Managing your trust settings
|
||||
|
||||
If you need to change a decision or see all your settings, you have a couple of
|
||||
options:
|
||||
|
||||
- **Change the current folder's trust**: Run the `/permissions` command from
|
||||
within the CLI. This will bring up the same interactive dialog, allowing you
|
||||
to change the trust level for the current folder.
|
||||
|
||||
- **View all trust rules**: To see a complete list of all your trusted and
|
||||
untrusted folder rules, you can inspect the contents of the
|
||||
`~/.gemini/trustedFolders.json` file in your home directory.
|
||||
|
||||
## The trust check process (advanced)
|
||||
|
||||
For advanced users, it's helpful to know the exact order of operations for how
|
||||
trust is determined:
|
||||
|
||||
1. **IDE trust signal**: If you are using the
|
||||
[IDE Integration](../ide-integration/index.md), the CLI first asks the IDE
|
||||
if the workspace is trusted. The IDE's response takes highest priority.
|
||||
|
||||
2. **Local trust file**: If the IDE is not connected, the CLI checks the
|
||||
central `~/.gemini/trustedFolders.json` file.
|
||||
@@ -0,0 +1,284 @@
|
||||
# Automate tasks with headless mode
|
||||
|
||||
Automate tasks with Gemini CLI. Learn how to use headless mode, pipe data into
|
||||
Gemini CLI, automate workflows with shell scripts, and generate structured JSON
|
||||
output for other applications.
|
||||
|
||||
## Prerequisites
|
||||
|
||||
- Gemini CLI installed and authenticated.
|
||||
- Familiarity with shell scripting (Bash/Zsh).
|
||||
|
||||
## Why headless mode?
|
||||
|
||||
Headless mode runs Gemini CLI once and exits. It's perfect for:
|
||||
|
||||
- **CI/CD:** Analyzing pull requests automatically.
|
||||
- **Batch processing:** Summarizing a large number of log files.
|
||||
- **Tool building:** Creating your own "AI wrapper" scripts.
|
||||
|
||||
## How to use headless mode
|
||||
|
||||
Run Gemini CLI in headless mode by providing a prompt with the `-p` (or
|
||||
`--prompt`) flag. This bypasses the interactive chat interface and prints the
|
||||
response to standard output (stdout). Positional arguments without the flag
|
||||
default to interactive mode, unless the input or output is piped or redirected.
|
||||
|
||||
Run a single command:
|
||||
|
||||
```bash
|
||||
gemini -p "Write a poem about TypeScript"
|
||||
```
|
||||
|
||||
## How to pipe input to Gemini CLI
|
||||
|
||||
Feed data into Gemini using the standard Unix pipe `|`. Gemini reads the
|
||||
standard input (stdin) as context and answers your question using standard
|
||||
output.
|
||||
|
||||
Pipe a file:
|
||||
|
||||
**macOS/Linux**
|
||||
|
||||
```bash
|
||||
cat error.log | gemini -p "Explain why this failed"
|
||||
```
|
||||
|
||||
**Windows (PowerShell)**
|
||||
|
||||
```powershell
|
||||
Get-Content error.log | gemini -p "Explain why this failed"
|
||||
```
|
||||
|
||||
Pipe a command:
|
||||
|
||||
```bash
|
||||
git diff | gemini -p "Write a commit message for these changes"
|
||||
```
|
||||
|
||||
## Use Gemini CLI output in scripts
|
||||
|
||||
Because Gemini prints to stdout, you can chain it with other tools or save the
|
||||
results to a file.
|
||||
|
||||
### Scenario: Bulk documentation generator
|
||||
|
||||
You have a folder of Python scripts and want to generate a `README.md` for each
|
||||
one.
|
||||
|
||||
1. Save the following code as `generate_docs.sh` (or `generate_docs.ps1` for
|
||||
Windows):
|
||||
|
||||
**macOS/Linux (`generate_docs.sh`)**
|
||||
|
||||
```bash
|
||||
#!/bin/bash
|
||||
|
||||
# Loop through all Python files
|
||||
for file in *.py; do
|
||||
echo "Generating docs for $file..."
|
||||
|
||||
# Ask Gemini CLI to generate the documentation and print it to stdout
|
||||
gemini -p "Generate a Markdown documentation summary for @$file. Print the
|
||||
result to standard output." > "${file%.py}.md"
|
||||
done
|
||||
```
|
||||
|
||||
**Windows PowerShell (`generate_docs.ps1`)**
|
||||
|
||||
```powershell
|
||||
# Loop through all Python files
|
||||
Get-ChildItem -Filter *.py | ForEach-Object {
|
||||
Write-Host "Generating docs for $($_.Name)..."
|
||||
|
||||
$newName = $_.Name -replace '\.py$', '.md'
|
||||
# Ask Gemini CLI to generate the documentation and print it to stdout
|
||||
gemini -p "Generate a Markdown documentation summary for @$($_.Name). Print the result to standard output." | Out-File -FilePath $newName -Encoding utf8
|
||||
}
|
||||
```
|
||||
|
||||
2. Make the script executable and run it in your directory:
|
||||
|
||||
**macOS/Linux**
|
||||
|
||||
```bash
|
||||
chmod +x generate_docs.sh
|
||||
./generate_docs.sh
|
||||
```
|
||||
|
||||
**Windows (PowerShell)**
|
||||
|
||||
```powershell
|
||||
.\generate_docs.ps1
|
||||
```
|
||||
|
||||
This creates a corresponding Markdown file for every Python file in the
|
||||
folder.
|
||||
|
||||
## Extract structured JSON data
|
||||
|
||||
When writing a script, you often need structured data (JSON) to pass to tools
|
||||
like `jq`. To get pure JSON data from the model, combine the
|
||||
`--output-format json` flag with `jq` to parse the response field.
|
||||
|
||||
### Scenario: Extract and return structured data
|
||||
|
||||
1. Save the following script as `generate_json.sh` (or `generate_json.ps1` for
|
||||
Windows):
|
||||
|
||||
**macOS/Linux (`generate_json.sh`)**
|
||||
|
||||
```bash
|
||||
#!/bin/bash
|
||||
|
||||
# Ensure we are in a project root
|
||||
if [ ! -f "package.json" ]; then
|
||||
echo "Error: package.json not found."
|
||||
exit 1
|
||||
fi
|
||||
|
||||
# Extract data
|
||||
gemini --output-format json "Return a raw JSON object with keys 'version' and 'deps' from @package.json" | jq -r '.response' > data.json
|
||||
```
|
||||
|
||||
**Windows PowerShell (`generate_json.ps1`)**
|
||||
|
||||
```powershell
|
||||
# Ensure we are in a project root
|
||||
if (-not (Test-Path "package.json")) {
|
||||
Write-Error "Error: package.json not found."
|
||||
exit 1
|
||||
}
|
||||
|
||||
# Extract data (requires jq installed, or you can use ConvertFrom-Json)
|
||||
$output = gemini --output-format json "Return a raw JSON object with keys 'version' and 'deps' from @package.json" | ConvertFrom-Json
|
||||
$output.response | Out-File -FilePath data.json -Encoding utf8
|
||||
```
|
||||
|
||||
2. Run the script:
|
||||
|
||||
**macOS/Linux**
|
||||
|
||||
```bash
|
||||
chmod +x generate_json.sh
|
||||
./generate_json.sh
|
||||
```
|
||||
|
||||
**Windows (PowerShell)**
|
||||
|
||||
```powershell
|
||||
.\generate_json.ps1
|
||||
```
|
||||
|
||||
3. Check `data.json`. The file should look like this:
|
||||
|
||||
```json
|
||||
{
|
||||
"version": "1.0.0",
|
||||
"deps": {
|
||||
"react": "^18.2.0"
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
## Build your own custom AI tools
|
||||
|
||||
Use headless mode to perform custom, automated AI tasks.
|
||||
|
||||
### Scenario: Create a "Smart Commit" alias
|
||||
|
||||
You can add a function to your shell configuration to create a `git commit`
|
||||
wrapper that writes the message for you.
|
||||
|
||||
**macOS/Linux (Bash/Zsh)**
|
||||
|
||||
1. Open your `.zshrc` file (or `.bashrc` if you use Bash) in your preferred
|
||||
text editor.
|
||||
|
||||
```bash
|
||||
nano ~/.zshrc
|
||||
```
|
||||
|
||||
**Note**: If you use VS Code, you can run `code ~/.zshrc`.
|
||||
|
||||
2. Scroll to the very bottom of the file and paste this code:
|
||||
|
||||
```bash
|
||||
function gcommit() {
|
||||
# Get the diff of staged changes
|
||||
diff=$(git diff --staged)
|
||||
|
||||
if [ -z "$diff" ]; then
|
||||
echo "No staged changes to commit."
|
||||
return 1
|
||||
fi
|
||||
|
||||
# Ask Gemini to write the message
|
||||
echo "Generating commit message..."
|
||||
msg=$(echo "$diff" | gemini -p "Write a concise Conventional Commit message for this diff. Output ONLY the message.")
|
||||
|
||||
# Commit with the generated message
|
||||
git commit -m "$msg"
|
||||
}
|
||||
```
|
||||
|
||||
Save your file and exit.
|
||||
|
||||
3. Run this command to make the function available immediately:
|
||||
|
||||
```bash
|
||||
source ~/.zshrc
|
||||
```
|
||||
|
||||
**Windows (PowerShell)**
|
||||
|
||||
1. Open your PowerShell profile in your preferred text editor.
|
||||
|
||||
```powershell
|
||||
notepad $PROFILE
|
||||
```
|
||||
|
||||
2. Scroll to the very bottom of the file and paste this code:
|
||||
|
||||
```powershell
|
||||
function gcommit {
|
||||
# Get the diff of staged changes
|
||||
$diff = git diff --staged
|
||||
|
||||
if (-not $diff) {
|
||||
Write-Host "No staged changes to commit."
|
||||
return
|
||||
}
|
||||
|
||||
# Ask Gemini to write the message
|
||||
Write-Host "Generating commit message..."
|
||||
$msg = $diff | gemini -p "Write a concise Conventional Commit message for this diff. Output ONLY the message."
|
||||
|
||||
# Commit with the generated message
|
||||
git commit -m "$msg"
|
||||
}
|
||||
```
|
||||
|
||||
Save your file and exit.
|
||||
|
||||
3. Run this command to make the function available immediately:
|
||||
|
||||
```powershell
|
||||
. $PROFILE
|
||||
```
|
||||
|
||||
4. Use your new command:
|
||||
|
||||
```bash
|
||||
gcommit
|
||||
```
|
||||
|
||||
Gemini CLI will analyze your staged changes and commit them with a generated
|
||||
message.
|
||||
|
||||
## Next steps
|
||||
|
||||
- Explore the [Headless mode reference](../../cli/headless.md) for full JSON
|
||||
schema details.
|
||||
- Learn about [Shell commands](shell-commands.md) to let the agent run scripts
|
||||
instead of just writing them.
|
||||
@@ -0,0 +1,144 @@
|
||||
# File management with Gemini CLI
|
||||
|
||||
Explore, analyze, and modify your codebase using Gemini CLI. In this guide,
|
||||
you'll learn how to provide Gemini CLI with files and directories, modify and
|
||||
create files, and control what Gemini CLI can see.
|
||||
|
||||
## Prerequisites
|
||||
|
||||
- Gemini CLI installed and authenticated.
|
||||
- A project directory to work with (for example, a git repository).
|
||||
|
||||
## Providing context by reading files
|
||||
|
||||
Gemini CLI will generally try to read relevant files, sometimes prompting you
|
||||
for access (depending on your settings). To ensure that Gemini CLI uses a file,
|
||||
you can also include it directly.
|
||||
|
||||
### Direct file inclusion (`@`)
|
||||
|
||||
If you know the path to the file you want to work on, use the `@` symbol. This
|
||||
forces the CLI to read the file immediately and inject its content into your
|
||||
prompt.
|
||||
|
||||
```bash
|
||||
`@src/components/UserProfile.tsx Explain how this component handles user data.`
|
||||
```
|
||||
|
||||
### Working with multiple files
|
||||
|
||||
Complex features often span multiple files. You can chain `@` references to give
|
||||
the agent a complete picture of the dependencies.
|
||||
|
||||
```bash
|
||||
`@src/components/UserProfile.tsx @src/types/User.ts Refactor the component to use the updated User interface.`
|
||||
```
|
||||
|
||||
### Including entire directories
|
||||
|
||||
For broad questions or refactoring, you can include an entire directory. Be
|
||||
careful with large folders, as this consumes more tokens.
|
||||
|
||||
```bash
|
||||
`@src/utils/ Check these utility functions for any deprecated API usage.`
|
||||
```
|
||||
|
||||
## How to find files (Exploration)
|
||||
|
||||
If you _don't_ know the exact file path, you can ask Gemini CLI to find it for
|
||||
you. This is useful when navigating a new codebase or looking for specific
|
||||
logic.
|
||||
|
||||
### Scenario: Find a component definition
|
||||
|
||||
You know there's a `UserProfile` component, but you don't know where it lives.
|
||||
|
||||
```none
|
||||
`Find the file that defines the UserProfile component.`
|
||||
```
|
||||
|
||||
Gemini uses the `glob` or `list_directory` tools to search your project
|
||||
structure. It will return the specific path (for example,
|
||||
`src/components/UserProfile.tsx`), which you can then use with `@` in your next
|
||||
turn.
|
||||
|
||||
<!-- prettier-ignore -->
|
||||
> [!TIP]
|
||||
> You can also ask for lists of files, like "Show me all the TypeScript
|
||||
> configuration files in the root directory."
|
||||
|
||||
## How to modify code
|
||||
|
||||
Once Gemini CLI has context, you can direct it to make specific edits. The agent
|
||||
is capable of complex refactoring, not just simple text replacement.
|
||||
|
||||
```none
|
||||
`Update @src/components/UserProfile.tsx to show a loading spinner if the user data is null.`
|
||||
```
|
||||
|
||||
Gemini CLI uses the `replace` tool to propose a targeted code change.
|
||||
|
||||
### Creating new files
|
||||
|
||||
You can also ask the agent to create entirely new files or folder structures.
|
||||
|
||||
```none
|
||||
`Create a new file @src/components/LoadingSpinner.tsx with a simple Tailwind CSS spinner.`
|
||||
```
|
||||
|
||||
Gemini CLI uses the `write_file` tool to generate the new file from scratch.
|
||||
|
||||
## Review and confirm changes
|
||||
|
||||
Gemini CLI prioritizes safety. Before any file is modified, it presents a
|
||||
unified diff of the proposed changes.
|
||||
|
||||
```diff
|
||||
- if (!user) return null;
|
||||
+ if (!user) return <LoadingSpinner />;
|
||||
```
|
||||
|
||||
- **Red lines (-):** Code that will be removed.
|
||||
- **Green lines (+):** Code that will be added.
|
||||
|
||||
Press **y** to confirm and apply the change to your local file system. If the
|
||||
diff doesn't look right, press **n** to cancel and refine your prompt.
|
||||
|
||||
## Verify the result
|
||||
|
||||
After the edit is complete, verify the fix. You can simply read the file again
|
||||
or, better yet, run your project's tests.
|
||||
|
||||
```none
|
||||
`Run the tests for the UserProfile component.`
|
||||
```
|
||||
|
||||
Gemini CLI uses the `run_shell_command` tool to execute your test runner (for
|
||||
example, `npm test` or `jest`). This ensures the changes didn't break existing
|
||||
functionality.
|
||||
|
||||
## Advanced: Controlling what Gemini sees
|
||||
|
||||
By default, Gemini CLI respects your `.gitignore` file. It won't read or search
|
||||
through `node_modules`, build artifacts, or other ignored paths.
|
||||
|
||||
If you have sensitive files (like `.env`) or large assets that you want to keep
|
||||
hidden from the AI _without_ ignoring them in Git, you can create a
|
||||
`.geminiignore` file in your project root.
|
||||
|
||||
**Example `.geminiignore`:**
|
||||
|
||||
```text
|
||||
.env
|
||||
local-db-dump.sql
|
||||
private-notes.md
|
||||
```
|
||||
|
||||
## Next steps
|
||||
|
||||
- Learn how to [Manage context and memory](memory-management.md) to keep your
|
||||
agent smarter over long sessions.
|
||||
- See [Execute shell commands](shell-commands.md) for more on running tests and
|
||||
builds.
|
||||
- Explore the technical [File system reference](../../tools/file-system.md) for
|
||||
advanced tool parameters.
|
||||
@@ -0,0 +1,115 @@
|
||||
# Set up an MCP server
|
||||
|
||||
Connect Gemini CLI to your external databases and services. In this guide,
|
||||
you'll learn how to extend Gemini CLI's capabilities by installing the GitHub
|
||||
MCP server and using it to manage your repositories.
|
||||
|
||||
## Prerequisites
|
||||
|
||||
- Gemini CLI installed.
|
||||
- **Docker:** Required for this specific example (many MCP servers run as Docker
|
||||
containers).
|
||||
- **GitHub token:** A Personal Access Token (PAT) with repo permissions.
|
||||
|
||||
## How to prepare your credentials
|
||||
|
||||
Most MCP servers require authentication. For GitHub, you need a PAT.
|
||||
|
||||
1. Create a [fine-grained PAT](https://github.com/settings/tokens?type=beta).
|
||||
2. Grant it **Read** access to **Metadata** and **Contents**, and
|
||||
**Read/Write** access to **Issues** and **Pull Requests**.
|
||||
3. Store it in your environment:
|
||||
|
||||
**macOS/Linux**
|
||||
|
||||
```bash
|
||||
export GITHUB_PERSONAL_ACCESS_TOKEN="github_pat_..."
|
||||
```
|
||||
|
||||
**Windows (PowerShell)**
|
||||
|
||||
```powershell
|
||||
$env:GITHUB_PERSONAL_ACCESS_TOKEN="github_pat_..."
|
||||
```
|
||||
|
||||
## How to configure Gemini CLI
|
||||
|
||||
You tell Gemini about new servers by editing your `settings.json`.
|
||||
|
||||
1. Open `~/.gemini/settings.json` (or the project-specific
|
||||
`.gemini/settings.json`).
|
||||
2. Add the `mcpServers` block. This tells Gemini: "Run this docker container
|
||||
and talk to it."
|
||||
|
||||
```json
|
||||
{
|
||||
"mcpServers": {
|
||||
"github": {
|
||||
"command": "docker",
|
||||
"args": [
|
||||
"run",
|
||||
"-i",
|
||||
"--rm",
|
||||
"-e",
|
||||
"GITHUB_PERSONAL_ACCESS_TOKEN",
|
||||
"ghcr.io/github/github-mcp-server:latest"
|
||||
],
|
||||
"env": {
|
||||
"GITHUB_PERSONAL_ACCESS_TOKEN": "${GITHUB_PERSONAL_ACCESS_TOKEN}"
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
<!-- prettier-ignore -->
|
||||
> [!NOTE]
|
||||
> The `command` is `docker`, and the rest are arguments passed to it. We
|
||||
> map the local environment variable into the container so your secret isn't
|
||||
> hardcoded in the config file.
|
||||
|
||||
## How to verify the connection
|
||||
|
||||
Restart Gemini CLI. It will automatically try to start the defined servers.
|
||||
|
||||
**Command:** `/mcp list`
|
||||
|
||||
You should see: `✓ github: docker ... - Connected`
|
||||
|
||||
If you see `Disconnected` or an error, check that Docker is running and your API
|
||||
token is valid.
|
||||
|
||||
## How to use the new tools
|
||||
|
||||
Now that the server is running, the agent has new capabilities ("tools"). You
|
||||
don't need to learn special commands; just ask in natural language.
|
||||
|
||||
### Scenario: Listing pull requests
|
||||
|
||||
**Prompt:** `List the open PRs in the google/gemini-cli repository.`
|
||||
|
||||
The agent will:
|
||||
|
||||
1. Recognize the request matches a GitHub tool.
|
||||
2. Call `mcp_github_list_pull_requests`.
|
||||
3. Present the data to you.
|
||||
|
||||
### Scenario: Creating an issue
|
||||
|
||||
**Prompt:**
|
||||
`Create an issue in my repo titled "Bug: Login fails" with the description "See logs".`
|
||||
|
||||
## Troubleshooting
|
||||
|
||||
- **Server won't start?** Try running the docker command manually in your
|
||||
terminal to see if it prints an error (for example, "image not found").
|
||||
- **Tools not found?** Run `/mcp reload` to force the CLI to re-query the server
|
||||
for its capabilities.
|
||||
|
||||
## Next steps
|
||||
|
||||
- Explore the [MCP servers reference](../../tools/mcp-server.md) to learn about
|
||||
SSE and HTTP transports for remote servers.
|
||||
- Browse the
|
||||
[official MCP server list](https://github.com/modelcontextprotocol/servers) to
|
||||
find connectors for Slack, Postgres, Google Drive, and more.
|
||||
@@ -0,0 +1,128 @@
|
||||
# Manage context and memory
|
||||
|
||||
Control what Gemini CLI knows about you and your projects. In this guide, you'll
|
||||
learn how to define project-wide rules with `GEMINI.md`, teach the agent
|
||||
persistent facts, and inspect the active context.
|
||||
|
||||
## Prerequisites
|
||||
|
||||
- Gemini CLI installed and authenticated.
|
||||
- A project directory where you want to enforce specific rules.
|
||||
|
||||
## Why manage context?
|
||||
|
||||
Gemini CLI is powerful but general. It doesn't know your preferred testing
|
||||
framework, your indentation style, or your preference against `any` in
|
||||
TypeScript. Context management solves this by giving the agent persistent
|
||||
memory.
|
||||
|
||||
You'll use these features when you want to:
|
||||
|
||||
- **Enforce standards:** Ensure every generated file matches your team's style
|
||||
guide.
|
||||
- **Set a persona:** Tell the agent to act as a "Senior Rust Engineer" or "QA
|
||||
Specialist."
|
||||
- **Remember facts:** Save details like "My database port is 5432" so you don't
|
||||
have to repeat them.
|
||||
|
||||
## How to define project-wide rules (GEMINI.md)
|
||||
|
||||
The most powerful way to control the agent's behavior is through `GEMINI.md`
|
||||
files. These are Markdown files containing instructions that are automatically
|
||||
loaded into every conversation.
|
||||
|
||||
### Scenario: Create a project context file
|
||||
|
||||
1. In the root of your project, create a file named `GEMINI.md`.
|
||||
|
||||
2. Add your instructions:
|
||||
|
||||
```markdown
|
||||
# Project Instructions
|
||||
|
||||
- **Framework:** We use React with Vite.
|
||||
- **Styling:** Use Tailwind CSS for all styling. Do not write custom CSS.
|
||||
- **Testing:** All new components must include a Vitest unit test.
|
||||
- **Tone:** Be concise. Don't explain basic React concepts.
|
||||
```
|
||||
|
||||
3. Start a new session. Gemini CLI will now know these rules automatically.
|
||||
|
||||
### Scenario: Using the hierarchy
|
||||
|
||||
Context is loaded hierarchically. This lets you have general rules for
|
||||
everything and specific rules for sub-projects.
|
||||
|
||||
1. **Global:** `~/.gemini/GEMINI.md` (Rules for _every_ project you work on).
|
||||
2. **Project Root:** `./GEMINI.md` (Rules for the current repository).
|
||||
3. **Subdirectory:** `./src/GEMINI.md` (Rules specific to the `src` folder).
|
||||
|
||||
**Example:** You might set "Always use strict typing" in your global config, but
|
||||
"Use Python 3.11" only in your backend repository.
|
||||
|
||||
## How to teach the agent facts (Memory)
|
||||
|
||||
Sometimes you don't want to write a config file. You just want to tell the agent
|
||||
something once and have it remember forever. You can do this naturally in chat.
|
||||
|
||||
### Scenario: Saving a memory
|
||||
|
||||
Just tell the agent to remember something.
|
||||
|
||||
**Prompt:** `Remember that I prefer using 'const' over 'let' wherever possible.`
|
||||
|
||||
The agent will edit the appropriate memory Markdown file, so the fact is loaded
|
||||
in future sessions.
|
||||
|
||||
**Prompt:** `Save the fact that the staging server IP is 10.0.0.5.`
|
||||
|
||||
### Scenario: Using memory in conversation
|
||||
|
||||
Once a fact is saved, you don't need to invoke it explicitly. The agent "knows"
|
||||
it.
|
||||
|
||||
**Next Prompt:** `Write a script to deploy to staging.`
|
||||
|
||||
**Agent Response:** "I'll write a script to deploy to **10.0.0.5**..."
|
||||
|
||||
## How to manage and inspect context
|
||||
|
||||
As your project grows, you might want to see exactly what instructions the agent
|
||||
is following.
|
||||
|
||||
### Scenario: View active context
|
||||
|
||||
To see the full, concatenated set of instructions currently loaded (from all
|
||||
`GEMINI.md` files and saved memories), use the `/memory show` command.
|
||||
|
||||
**Command:** `/memory show`
|
||||
|
||||
This prints the raw text the model receives at the start of the session. It's
|
||||
excellent for debugging why the agent might be ignoring a rule.
|
||||
|
||||
### Scenario: Refresh context
|
||||
|
||||
If you edit a `GEMINI.md` file while a session is running, the agent won't know
|
||||
immediately. Force a reload with:
|
||||
|
||||
**Command:** `/memory reload`
|
||||
|
||||
## Best practices
|
||||
|
||||
- **Keep it focused:** Avoid adding excessive content to `GEMINI.md`. Keep
|
||||
instructions actionable and relevant to code generation.
|
||||
- **Use negative constraints:** Explicitly telling the agent what _not_ to do
|
||||
(for example, "Do not use class components") is often more effective than
|
||||
vague positive instructions.
|
||||
- **Review often:** Periodically check your `GEMINI.md` files to remove outdated
|
||||
rules.
|
||||
|
||||
## Next steps
|
||||
|
||||
- Learn about [Session management](session-management.md) to see how short-term
|
||||
history works.
|
||||
- Explore the [Command reference](../../reference/commands.md) for more
|
||||
`/memory` options.
|
||||
- Read the technical spec for [Project context](../../cli/gemini-md.md).
|
||||
- Try the experimental [Auto Memory](../auto-memory.md) feature to extract
|
||||
memory updates and reusable skills from your past sessions automatically.
|
||||
@@ -0,0 +1,90 @@
|
||||
# Use Plan Mode with model steering for complex tasks
|
||||
|
||||
Architecting a complex solution requires precision. By combining Plan Mode's
|
||||
structured environment with model steering's real-time feedback, you can guide
|
||||
Gemini CLI through the research and design phases to ensure the final
|
||||
implementation plan is exactly what you need.
|
||||
|
||||
<!-- prettier-ignore -->
|
||||
> [!NOTE]
|
||||
> This is an experimental feature currently under active development and
|
||||
> may need to be enabled under `/settings`.
|
||||
|
||||
## Prerequisites
|
||||
|
||||
- Gemini CLI installed and authenticated.
|
||||
- [Plan Mode](../plan-mode.md) enabled in your settings.
|
||||
- [Model steering](../model-steering.md) enabled in your settings.
|
||||
|
||||
## Why combine Plan Mode and model steering?
|
||||
|
||||
[Plan Mode](../plan-mode.md) typically follows a linear path: research, propose,
|
||||
and draft. Adding model steering lets you:
|
||||
|
||||
1. **Direct the research:** Correct the agent if it's looking in the wrong
|
||||
directory or missing a key dependency.
|
||||
2. **Iterate mid-draft:** Suggest a different architectural pattern while the
|
||||
agent is still writing the plan.
|
||||
3. **Speed up the loop:** Avoid waiting for a full research turn to finish
|
||||
before providing critical context.
|
||||
|
||||
## Step 1: Start a complex task
|
||||
|
||||
Enter Plan Mode and start a task that requires research.
|
||||
|
||||
**Prompt:** `/plan I want to implement a new notification service using Redis.`
|
||||
|
||||
Gemini CLI enters Plan Mode and starts researching your existing codebase to
|
||||
identify where the new service should live.
|
||||
|
||||
## Step 2: Steer the research phase
|
||||
|
||||
As you see the agent calling tools like `list_directory` or `grep_search`, you
|
||||
might realize it's missing the relevant context.
|
||||
|
||||
**Action:** While the spinner is active, type your hint:
|
||||
`"Don't forget to check packages/common/queues for the existing Redis config."`
|
||||
|
||||
**Result:** Gemini CLI acknowledges your hint and immediately incorporates it
|
||||
into its research. You'll see it start exploring the directory you suggested in
|
||||
its very next turn.
|
||||
|
||||
## Step 3: Refine the design mid-turn
|
||||
|
||||
After research, the agent starts drafting the implementation plan. If you notice
|
||||
it's proposing a design that doesn't align with your goals, steer it.
|
||||
|
||||
**Action:** Type:
|
||||
`"Actually, let's use a Publisher/Subscriber pattern instead of a simple queue for this service."`
|
||||
|
||||
**Result:** The agent stops drafting the current version of the plan,
|
||||
re-evaluates the design based on your feedback, and starts a new draft that uses
|
||||
the Pub/Sub pattern.
|
||||
|
||||
## Step 4: Approve and implement
|
||||
|
||||
Once the agent has used your hints to craft the perfect plan, review the final
|
||||
`.md` file.
|
||||
|
||||
**Action:** Type: `"Looks perfect. Let's start the implementation."`
|
||||
|
||||
Gemini CLI exits Plan Mode and transitions to the implementation phase. Because
|
||||
the plan was refined in real-time with your feedback, the agent can now execute
|
||||
each step with higher confidence and fewer errors.
|
||||
|
||||
## Tips for effective steering
|
||||
|
||||
- **Be specific:** Instead of "do it differently," try "use the existing
|
||||
`Logger` class in `src/utils`."
|
||||
- **Steer early:** Providing feedback during the research phase is more
|
||||
efficient than waiting for the final plan to be drafted.
|
||||
- **Use for context:** Steering is a great way to provide knowledge that might
|
||||
not be obvious from reading the code (for example, "We are planning to
|
||||
deprecate this module next month").
|
||||
|
||||
## Next steps
|
||||
|
||||
- Explore [Agent Skills](../skills.md) to add specialized expertise to your
|
||||
planning turns.
|
||||
- See the [Model steering reference](../model-steering.md) for technical
|
||||
details.
|
||||
@@ -0,0 +1,118 @@
|
||||
# Manage sessions and history
|
||||
|
||||
Resume, browse, and rewind your conversations with Gemini CLI. In this guide,
|
||||
you'll learn how to switch between tasks, manage your session history, and undo
|
||||
mistakes using the rewind feature.
|
||||
|
||||
## Prerequisites
|
||||
|
||||
- Gemini CLI installed and authenticated.
|
||||
- At least one active or past session.
|
||||
|
||||
## How to resume where you left off
|
||||
|
||||
It's common to switch context—maybe you're waiting for a build and want to work
|
||||
on a different feature. Gemini makes it easy to jump back in.
|
||||
|
||||
### Scenario: Resume the last session
|
||||
|
||||
The fastest way to pick up your most recent work is with the `--resume` flag (or
|
||||
`-r`).
|
||||
|
||||
```bash
|
||||
gemini -r
|
||||
```
|
||||
|
||||
This restores your chat history and memory, so you can say "Continue with the
|
||||
next step" immediately.
|
||||
|
||||
### Scenario: Browse past sessions
|
||||
|
||||
If you want to find a specific conversation from yesterday, use the interactive
|
||||
browser.
|
||||
|
||||
**Command:** `/resume`
|
||||
|
||||
This opens a searchable list of all your past sessions. You'll see:
|
||||
|
||||
- A timestamp (for example, "2 hours ago").
|
||||
- The first user message (helping you identify the topic).
|
||||
- The number of turns in the conversation.
|
||||
|
||||
Select a session and press **Enter** to load it.
|
||||
|
||||
## How to manage your workspace
|
||||
|
||||
Over time, you'll accumulate a lot of history. Keeping your session list clean
|
||||
helps you find what you need.
|
||||
|
||||
### Scenario: Deleting sessions
|
||||
|
||||
In the `/resume` browser, navigate to a session you no longer need and press
|
||||
**x**. This permanently deletes the history for that specific conversation.
|
||||
|
||||
You can also manage sessions from the command line:
|
||||
|
||||
```bash
|
||||
# List all sessions with their IDs
|
||||
gemini --list-sessions
|
||||
|
||||
# Delete a specific session by ID or index
|
||||
gemini --delete-session 1
|
||||
```
|
||||
|
||||
### Scenario: Delete session on exit
|
||||
|
||||
If you're doing a one-off task and don't want to leave any session history
|
||||
behind, use the `--delete` flag when exiting:
|
||||
|
||||
```
|
||||
/exit --delete
|
||||
```
|
||||
|
||||
This removes the current session's conversation history and tool output files
|
||||
before exiting. It's useful for privacy-sensitive tasks or quick one-off
|
||||
interactions.
|
||||
|
||||
## How to rewind time (Undo mistakes)
|
||||
|
||||
Gemini CLI's **Rewind** feature is like `Ctrl+Z` for your workflow.
|
||||
|
||||
### Scenario: Triggering rewind
|
||||
|
||||
At any point in a chat, type `/rewind` or press **Esc** twice.
|
||||
|
||||
### Scenario: Choosing a restore point
|
||||
|
||||
You'll see a list of your recent interactions. Select the point _before_ the
|
||||
undesired changes occurred.
|
||||
|
||||
### Scenario: Choosing what to revert
|
||||
|
||||
Gemini gives you granular control over the undo process. You can choose to:
|
||||
|
||||
1. **Rewind conversation:** Only remove the chat history. The files stay
|
||||
changed. (Useful if the code is good but the chat got off track).
|
||||
2. **Revert code changes:** Keep the chat history but undo the file edits.
|
||||
(Useful if you want to keep the context but retry the implementation).
|
||||
3. **Rewind both:** Restore everything to exactly how it was.
|
||||
|
||||
## How to fork conversations
|
||||
|
||||
Sometimes you want to try two different approaches to the same problem.
|
||||
|
||||
1. Start a session and get to a decision point.
|
||||
2. Save the current state with `/resume save decision-point`.
|
||||
3. Try your first approach.
|
||||
4. Later, use `/resume resume decision-point` to fork the conversation back to
|
||||
that moment and try a different approach.
|
||||
|
||||
This creates a new branch of history without losing your original work.
|
||||
|
||||
## Next steps
|
||||
|
||||
- Learn about [Checkpointing](../../cli/checkpointing.md) to understand the
|
||||
underlying safety mechanism.
|
||||
- Explore [Task planning](task-planning.md) to keep complex sessions organized.
|
||||
- See the [Command reference](../../reference/commands.md) for `/resume`
|
||||
options, grouped checkpoint menus, and `/chat` compatibility aliases.
|
||||
@@ -0,0 +1,108 @@
|
||||
# Execute shell commands
|
||||
|
||||
Use the CLI to run builds, manage git, and automate system tasks without leaving
|
||||
the conversation. In this guide, you'll learn how to run commands directly,
|
||||
automate complex workflows, and manage background processes safely.
|
||||
|
||||
## Prerequisites
|
||||
|
||||
- Gemini CLI installed and authenticated.
|
||||
- Basic familiarity with your system's shell (Bash, Zsh, PowerShell, and so on).
|
||||
|
||||
## How to run commands directly (`!`)
|
||||
|
||||
Sometimes you just need to check a file size or git status without asking the AI
|
||||
to do it for you. You can pass commands directly to your shell using the `!`
|
||||
prefix.
|
||||
|
||||
**Example:** `!ls -la`
|
||||
|
||||
This executes `ls -la` immediately and prints the output to your terminal.
|
||||
Gemini CLI also records the command and its output in the current session
|
||||
context, so the model can reference it in follow-up prompts. Very large outputs
|
||||
may be truncated.
|
||||
|
||||
### Scenario: Entering Shell mode
|
||||
|
||||
If you're doing a lot of manual work, toggle "Shell Mode" by typing `!` and
|
||||
pressing **Enter**. Now, everything you type is sent to the shell until you exit
|
||||
(usually by pressing **Esc** or typing `exit`).
|
||||
|
||||
## How to automate complex tasks
|
||||
|
||||
You can automate tasks using a combination of Gemini CLI and shell commands.
|
||||
|
||||
### Scenario: Run tests and fix failures
|
||||
|
||||
You want to run tests and fix any failures.
|
||||
|
||||
**Prompt:**
|
||||
`Run the unit tests. If any fail, analyze the error and try to fix the code.`
|
||||
|
||||
**Workflow:**
|
||||
|
||||
1. Gemini calls `run_shell_command('npm test')`.
|
||||
2. You see a confirmation prompt: `Allow command 'npm test'? [y/N]`.
|
||||
3. You press `y`.
|
||||
4. The tests run. If they fail, Gemini reads the error output.
|
||||
5. Gemini uses `read_file` to inspect the failing test.
|
||||
6. Gemini uses `replace` to fix the bug.
|
||||
7. Gemini runs `npm test` again to verify the fix.
|
||||
|
||||
This loop lets Gemini work autonomously.
|
||||
|
||||
## How to manage background processes
|
||||
|
||||
You can ask Gemini to start long-running tasks, like development servers or file
|
||||
watchers.
|
||||
|
||||
**Prompt:** `Start the React dev server in the background.`
|
||||
|
||||
Gemini will run the command (for example, `npm run dev`) and detach it.
|
||||
|
||||
### Scenario: Viewing active shells
|
||||
|
||||
To see what's running in the background, use the `/shells` command.
|
||||
|
||||
**Command:** `/shells`
|
||||
|
||||
This opens a dashboard where you can view logs or kill runaway processes.
|
||||
|
||||
## How to handle interactive commands
|
||||
|
||||
Gemini CLI attempts to handle interactive commands (like `git add -p` or
|
||||
confirmation prompts) by streaming the output to you. However, for highly
|
||||
interactive tools (like `vim` or `top`), it's often better to run them yourself
|
||||
in a separate terminal window or use the `!` prefix.
|
||||
|
||||
## Safety features
|
||||
|
||||
Giving an AI access to your shell is powerful but risky. Gemini CLI includes
|
||||
several safety layers.
|
||||
|
||||
### Confirmation prompts
|
||||
|
||||
By default, **every** shell command requested by the agent requires your
|
||||
explicit approval.
|
||||
|
||||
- **Allow once:** Runs the command one time.
|
||||
- **Allow always:** Trusts this specific command for the rest of the session.
|
||||
- **Deny:** Stops the agent.
|
||||
|
||||
### Sandboxing
|
||||
|
||||
For maximum security, especially when running untrusted code or exploring new
|
||||
projects, we strongly recommend enabling Sandboxing. This runs all shell
|
||||
commands inside a secure Docker container.
|
||||
|
||||
**Enable sandboxing:** Use the `--sandbox` flag when starting the CLI:
|
||||
`gemini --sandbox`.
|
||||
|
||||
## Next steps
|
||||
|
||||
- Learn about [Sandboxing](../../cli/sandbox.md) to safely run destructive
|
||||
commands.
|
||||
- See the [Shell tool reference](../../tools/shell.md) for configuration options
|
||||
like timeouts and working directories.
|
||||
- Explore [Task planning](task-planning.md) to see how shell commands fit into
|
||||
larger workflows.
|
||||
@@ -0,0 +1,158 @@
|
||||
# Get started with Agent Skills
|
||||
|
||||
Agent Skills extend Gemini CLI with specialized expertise. In this tutorial,
|
||||
you'll learn how to create your first skill, bundle custom logic, and activate
|
||||
it during a session.
|
||||
|
||||
## Create your first skill
|
||||
|
||||
A skill is defined by a directory containing a `SKILL.md` file and
|
||||
subdirectories containing reference materials or scripts used by the skill.
|
||||
Let's create an **API Auditor** skill that runs a script to help you verify if
|
||||
local or remote endpoints are responding correctly.
|
||||
|
||||
### 1. Create the directory structure
|
||||
|
||||
The first step is to create the necessary folders for your skill and its
|
||||
scripts.
|
||||
|
||||
**macOS/Linux**
|
||||
|
||||
```bash
|
||||
mkdir -p .gemini/skills/api-auditor/scripts
|
||||
```
|
||||
|
||||
**Windows (PowerShell)**
|
||||
|
||||
```powershell
|
||||
New-Item -ItemType Directory -Force -Path ".gemini\skills\api-auditor\scripts"
|
||||
```
|
||||
|
||||
### 2. Create the definition (`SKILL.md`)
|
||||
|
||||
The `SKILL.md` file defines the skill's purpose and instructions for the agent.
|
||||
Create a file at `.gemini/skills/api-auditor/SKILL.md`. This tells the agent
|
||||
_when_ to use the skill and _how_ to behave.
|
||||
|
||||
```markdown
|
||||
---
|
||||
name: api-auditor
|
||||
description:
|
||||
Expertise in auditing and testing API endpoints. Use when the user asks to
|
||||
"check", "test", or "audit" a URL or API.
|
||||
---
|
||||
|
||||
# API Auditor Instructions
|
||||
|
||||
You act as a QA engineer specialized in API reliability. When this skill is
|
||||
active, you MUST:
|
||||
|
||||
1. **Audit**: Use the bundled `scripts/audit.js` utility to check the status of
|
||||
the provided URL.
|
||||
2. **Report**: Analyze the output (status codes, latency) and explain any
|
||||
failures in plain English.
|
||||
3. **Secure**: Remind the user if they are testing a sensitive endpoint without
|
||||
an `https://` protocol.
|
||||
```
|
||||
|
||||
### 3. Add the tool logic
|
||||
|
||||
Skills can bundle resources like scripts to perform deterministic tasks. Create
|
||||
a file at `.gemini/skills/api-auditor/scripts/audit.js`. This is the code the
|
||||
agent will run.
|
||||
|
||||
```javascript
|
||||
// .gemini/skills/api-auditor/scripts/audit.js
|
||||
const url = process.argv[2];
|
||||
|
||||
if (!url) {
|
||||
console.error('Usage: node audit.js <url>');
|
||||
process.exit(1);
|
||||
}
|
||||
|
||||
console.log(`Auditing ${url}...`);
|
||||
fetch(url, { method: 'HEAD' })
|
||||
.then((r) => console.log(`Result: Success (Status ${r.status})`))
|
||||
.catch((e) => console.error(`Result: Failed (${e.message})`));
|
||||
```
|
||||
|
||||
## Verify discovery
|
||||
|
||||
Gemini CLI automatically discovers skills in the `.gemini/skills` directory (as
|
||||
well as the `.agents/skills` alias).
|
||||
|
||||
To check if Gemini CLI found your new skill, use the `/skills list` command
|
||||
within an interactive session:
|
||||
|
||||
```bash
|
||||
/skills list
|
||||
```
|
||||
|
||||
You should see `api-auditor` in the list of available skills. If you just added
|
||||
the files, you can run `/skills reload` to refresh the list without restarting
|
||||
the session.
|
||||
|
||||
### If your skill doesn't appear
|
||||
|
||||
If `/skills list` doesn't show your skill, check the following:
|
||||
|
||||
1. **The folder must be trusted (workspace skills only).** Skills under
|
||||
`<workspace>/.gemini/skills/` are only loaded when the workspace folder is
|
||||
marked as trusted. Run `/trust` and restart the session if needed. Skills
|
||||
under `~/.gemini/skills/` (user scope) are not affected by trust.
|
||||
2. **Check the path layout.** `SKILL.md` is discovered either at the root of
|
||||
the skills directory (`.gemini/skills/SKILL.md`) or one directory deep
|
||||
(`.gemini/skills/<skill-name>/SKILL.md`). The recommended layout uses a
|
||||
subdirectory per skill so you can bundle scripts and other resources
|
||||
alongside it. Files nested more than one directory deep are not discovered.
|
||||
3. **The filename must be exactly `SKILL.md`.** Capitalization matters on
|
||||
case-sensitive filesystems (Linux, and macOS when configured as such):
|
||||
`skill.md` or `Skill.md` will be ignored.
|
||||
4. **Frontmatter must include both `name:` and `description:`, and must be the
|
||||
first thing in the file.** A `SKILL.md` is silently skipped if either field
|
||||
is missing, if the delimiters (`---` on their own lines) are absent, or if
|
||||
any text (an H1 title, a comment, even a blank line) appears before the
|
||||
opening `---`.
|
||||
5. **The skill name comes from the `name:` field, not the directory name.** If
|
||||
your frontmatter says `name: foo`, the skill appears as `foo` in
|
||||
`/skills list` regardless of what its parent directory is called. The
|
||||
characters `: \ / < > * ? " |` in the name are replaced with `-`.
|
||||
|
||||
## How to use the skill
|
||||
|
||||
Now that the skill is discovered, you can trigger its activation by asking a
|
||||
relevant question.
|
||||
|
||||
1. **Trigger**: Start a new session and ask: "Can you audit https://google.com"
|
||||
2. **Activation**: Gemini identifies that the request matches the `api-auditor`
|
||||
description and calls the `activate_skill` tool.
|
||||
3. **Consent**: You will see a confirmation prompt. Type **y** to approve.
|
||||
4. **Execution**: Once activated, Gemini uses the `run_shell_command` tool to
|
||||
execute your bundled script:
|
||||
`node .gemini/skills/api-auditor/scripts/audit.js https://google.com`
|
||||
|
||||
## Pro tip: Use the skill-creator
|
||||
|
||||
If you don't want to create the files manually, you can use the built-in
|
||||
`skill-creator` skill. Simply ask Gemini:
|
||||
|
||||
> "Create a new skill called 'api-auditor' that tests if URLs are responding."
|
||||
|
||||
The `skill-creator` will handle the directory structure and boilerplate for you.
|
||||
|
||||
## Manage skills
|
||||
|
||||
You can also manage skills using the `gemini skills` command from your terminal:
|
||||
|
||||
- **Install**: `gemini skills install <url-or-path>`
|
||||
- **Link**: `gemini skills link <path>` (useful for local development)
|
||||
- **Uninstall**: `gemini skills uninstall <name>`
|
||||
|
||||
## Next steps
|
||||
|
||||
- [Creating Agent Skills](../creating-skills.md): Detailed guide on advanced
|
||||
skill features and metadata.
|
||||
- [Using Agent Skills](../using-agent-skills.md): More ways to discover and
|
||||
manage your skill library.
|
||||
- [Skill best practices](../skills-best-practices.md): Learn how to design
|
||||
reliable and effective expertise.
|
||||
@@ -0,0 +1,93 @@
|
||||
# Plan tasks with todos
|
||||
|
||||
Keep complex jobs on the rails with Gemini CLI's built-in task planning. In this
|
||||
guide, you'll learn how to ask for a plan, execute it step-by-step, and monitor
|
||||
progress with the todo list.
|
||||
|
||||
## Prerequisites
|
||||
|
||||
- Gemini CLI installed and authenticated.
|
||||
- A complex task in mind (for example, a multi-file refactor or new feature).
|
||||
|
||||
## Why use task planning?
|
||||
|
||||
Standard LLMs have a limited context window and can "forget" the original goal
|
||||
after 10 turns of code generation. Task planning provides:
|
||||
|
||||
1. **Visibility:** You see exactly what the agent plans to do _before_ it
|
||||
starts.
|
||||
2. **Focus:** The agent knows exactly which step it's working on right now.
|
||||
3. **Resilience:** If the agent gets stuck, the plan helps it get back on
|
||||
track.
|
||||
|
||||
## How to ask for a plan
|
||||
|
||||
The best way to trigger task planning is to explicitly ask for it.
|
||||
|
||||
**Prompt:**
|
||||
`I want to migrate this project from JavaScript to TypeScript. Please make a plan first.`
|
||||
|
||||
Gemini will analyze your codebase and use the `write_todos` tool to generate a
|
||||
structured list.
|
||||
|
||||
**Example Plan:**
|
||||
|
||||
1. [ ] Create `tsconfig.json`.
|
||||
2. [ ] Rename `.js` files to `.ts`.
|
||||
3. [ ] Fix type errors in `utils.js`.
|
||||
4. [ ] Fix type errors in `server.js`.
|
||||
5. [ ] Verify build passes.
|
||||
|
||||
## How to review and iterate
|
||||
|
||||
Once the plan is generated, it appears in your CLI. Review it.
|
||||
|
||||
- **Missing steps?** Tell the agent: "You forgot to add a step for installing
|
||||
`@types/node`."
|
||||
- **Wrong order?** Tell the agent: "Let's verify the build _after_ each file,
|
||||
not just at the end."
|
||||
|
||||
The agent will update the todo list dynamically.
|
||||
|
||||
## How to execute the plan
|
||||
|
||||
Tell the agent to proceed.
|
||||
|
||||
**Prompt:** `Looks good. Start with the first step.`
|
||||
|
||||
As the agent works, you'll see the todo list update in real-time above the input
|
||||
box.
|
||||
|
||||
- **Current focus:** The active task is highlighted (for example,
|
||||
`[IN_PROGRESS] Create tsconfig.json`).
|
||||
- **Progress:** Completed tasks are marked as done.
|
||||
|
||||
## How to monitor progress (`Ctrl+T`)
|
||||
|
||||
For a long-running task, the full todo list might be hidden to save space. You
|
||||
can toggle the full view at any time.
|
||||
|
||||
**Action:** Press **Ctrl+T**.
|
||||
|
||||
This shows the complete list, including pending, in-progress, and completed
|
||||
items. It's a great way to check "how much is left?" without scrolling back up.
|
||||
|
||||
## How to handle unexpected changes
|
||||
|
||||
Plans change. Maybe you discover a library is incompatible halfway through.
|
||||
|
||||
**Prompt:**
|
||||
`Actually, let's skip the 'server.js' refactor for now. It's too risky.`
|
||||
|
||||
The agent will mark that task as `cancelled` or remove it, and move to the next
|
||||
item. This dynamic adjustment is what makes the todo system powerful—it's a
|
||||
living document, not a static text block.
|
||||
|
||||
## Next steps
|
||||
|
||||
- Explore [Session management](session-management.md) to save your plan and
|
||||
finish it tomorrow.
|
||||
- See the [Todo tool reference](../../tools/todos.md) for technical schema
|
||||
details.
|
||||
- Learn about [Memory management](memory-management.md) to persist planning
|
||||
preferences (for example, "Always create a test plan first").
|
||||
@@ -0,0 +1,78 @@
|
||||
# Web search and fetch
|
||||
|
||||
Access the live internet directly from your prompt. In this guide, you'll learn
|
||||
how to search for up-to-date documentation, fetch deep context from specific
|
||||
URLs, and apply that knowledge to your code.
|
||||
|
||||
## Prerequisites
|
||||
|
||||
- Gemini CLI installed and authenticated.
|
||||
- An internet connection.
|
||||
|
||||
## How to research new technologies
|
||||
|
||||
Imagine you want to use a library released yesterday. The model doesn't know
|
||||
about it yet. You need to teach it.
|
||||
|
||||
### Scenario: Find documentation
|
||||
|
||||
**Prompt:**
|
||||
`Search for the 'Bun 1.0' release notes and summarize the key changes.`
|
||||
|
||||
Gemini uses the `google_web_search` tool to find relevant pages and synthesizes
|
||||
an answer. This "grounding" process ensures the agent isn't hallucinating
|
||||
features that don't exist.
|
||||
|
||||
**Prompt:** `Find the documentation for the 'React Router v7' loader API.`
|
||||
|
||||
## How to fetch deep context
|
||||
|
||||
Search gives you a summary, but sometimes you need the raw details. The
|
||||
`web_fetch` tool lets you feed a specific URL directly into the agent's context.
|
||||
|
||||
### Scenario: Reading a blog post
|
||||
|
||||
You found a blog post with the exact solution to your bug.
|
||||
|
||||
**Prompt:**
|
||||
`Read https://example.com/fixing-memory-leaks and explain how to apply it to my code.`
|
||||
|
||||
Gemini will retrieve the page content (stripping away ads and navigation) and
|
||||
use it to answer your question.
|
||||
|
||||
### Scenario: Comparing sources
|
||||
|
||||
You can even fetch multiple pages to compare approaches.
|
||||
|
||||
**Prompt:**
|
||||
`Compare the pagination patterns in https://api.example.com/v1/docs and https://api.example.com/v2/docs.`
|
||||
|
||||
## How to apply knowledge to code
|
||||
|
||||
The real power comes when you combine web tools with file editing.
|
||||
|
||||
**Workflow:**
|
||||
|
||||
1. **Search:** "How do I implement auth with Supabase?"
|
||||
2. **Fetch:** "Read this guide: https://supabase.com/docs/guides/auth."
|
||||
3. **Implement:** "Great. Now use that pattern to create an `auth.ts` file in
|
||||
my project."
|
||||
|
||||
## How to troubleshoot errors
|
||||
|
||||
When you hit an obscure error message, paste it into the chat.
|
||||
|
||||
**Prompt:**
|
||||
`I'm getting 'Error: hydration mismatch' in Next.js. Search for recent solutions.`
|
||||
|
||||
The agent will search sources such as GitHub issues, StackOverflow, and forums
|
||||
to find relevant fixes that might be too new to be in its base training set.
|
||||
|
||||
## Next steps
|
||||
|
||||
- Explore [File management](file-management.md) to see how to apply the code you
|
||||
generate.
|
||||
- See the [Web search tool reference](../../tools/web-search.md) for citation
|
||||
details.
|
||||
- See the [Web fetch tool reference](../../tools/web-fetch.md) for technical
|
||||
limitations.
|
||||
@@ -0,0 +1,89 @@
|
||||
# Managing Agent Skills
|
||||
|
||||
Agent Skills provide Gemini CLI with specialized expertise on demand. This guide
|
||||
covers advanced management techniques, including using slash commands, terminal
|
||||
utilities, and understanding discovery tiers.
|
||||
|
||||
## Discovery tiers
|
||||
|
||||
Gemini CLI discovers skills from several locations, following a specific order
|
||||
of precedence (lowest to highest):
|
||||
|
||||
1. **Built-in Skills**: Included with Gemini CLI and always available.
|
||||
2. **Extension Skills**: Bundled within [extensions](../extensions/index.md).
|
||||
3. **User Skills**: Located in `~/.gemini/skills/` or the `~/.agents/skills/`
|
||||
alias. These are available across all your projects.
|
||||
4. **Workspace Skills**: Located in `.gemini/skills/` or the `.agents/skills/`
|
||||
alias within your current directory. These are project-specific.
|
||||
|
||||
> **Tip:** If multiple skills share the same name, the version from the
|
||||
> higher-precedence location is used.
|
||||
|
||||
## In-session management
|
||||
|
||||
Use the `/skills` slash command during an interactive session to manage your
|
||||
available expertise.
|
||||
|
||||
- **List skills**: `/skills list` (shows discovered skills).
|
||||
- Use `/skills list all` to include internal built-in skills.
|
||||
- Use `/skills list nodesc` to hide descriptions.
|
||||
- **Reload skills**: `/skills reload` (or `/skills refresh`) to scan for new or
|
||||
modified skills without restarting the CLI.
|
||||
- **Toggle status**:
|
||||
- `/skills disable <name>`: Prevents a skill from being triggered.
|
||||
- `/skills enable <name>`: Re-enables a disabled skill.
|
||||
- **Link local skills**: `/skills link <path> [--scope user|workspace]` to
|
||||
immediately use a skill you are developing.
|
||||
|
||||
## Terminal utilities
|
||||
|
||||
The `gemini skills` command provides management utilities directly from your
|
||||
system shell.
|
||||
|
||||
### Install a skill
|
||||
|
||||
To install a skill from a remote repository or a local `.skill` package:
|
||||
|
||||
```bash
|
||||
gemini skills install https://github.com/user/my-awesome-skill
|
||||
```
|
||||
|
||||
By default, this installs to your **user profile**. Use `--scope workspace` to
|
||||
install it only for the current project.
|
||||
|
||||
### Link for development
|
||||
|
||||
If you are developing a skill, use the `link` command to create a reference to
|
||||
your local directory:
|
||||
|
||||
```bash
|
||||
gemini skills link ./path/to/my-skill
|
||||
```
|
||||
|
||||
### Uninstall a skill
|
||||
|
||||
To completely remove an installed or linked skill:
|
||||
|
||||
```bash
|
||||
gemini skills uninstall <name>
|
||||
```
|
||||
|
||||
## Security and consent
|
||||
|
||||
Agent Skills can execute scripts and access your files. To protect your
|
||||
environment:
|
||||
|
||||
1. **Installation consent**: When installing from a remote URL, you will be
|
||||
asked to confirm the source.
|
||||
2. **Activation consent**: Every time a skill is triggered during a session,
|
||||
the agent must ask for permission to activate it and gain access to its
|
||||
resources.
|
||||
|
||||
## Next steps
|
||||
|
||||
- [Get started with Agent Skills](./tutorials/skills-getting-started.md): A
|
||||
walkthrough for creating your first skill.
|
||||
- [Creating Agent Skills](./creating-skills.md): Detailed guide on bundling
|
||||
scripts and assets.
|
||||
- [Skill best practices](./skills-best-practices.md): Strategies for building
|
||||
reliable expertise.
|
||||
@@ -0,0 +1,83 @@
|
||||
# `gemini gemma` — Automated Local Model Routing Setup
|
||||
|
||||
Local model routing uses a local Gemma 3 1B model running on your machine to
|
||||
classify and route user requests. It routes simple requests (like file reads) to
|
||||
Gemini Flash and complex requests (like architecture discussions) to Gemini Pro.
|
||||
|
||||
<!-- prettier-ignore -->
|
||||
> [!NOTE]
|
||||
> This is an experimental feature currently under active development.
|
||||
|
||||
## What is this?
|
||||
|
||||
This feature saves cloud API costs by using local inference for task
|
||||
classification instead of a cloud-based classifier. It adds a few milliseconds
|
||||
of local latency but can significantly reduce the overall token usage for hosted
|
||||
models.
|
||||
|
||||
## Quick start
|
||||
|
||||
```bash
|
||||
# One command does everything: downloads runtime, pulls model, configures settings, starts server
|
||||
gemini gemma setup
|
||||
```
|
||||
|
||||
You'll be prompted to accept the Gemma Terms of Use. The model is ~1 GB.
|
||||
|
||||
After setup, **just use the CLI normally** — routing happens automatically on
|
||||
every request.
|
||||
|
||||
## Commands
|
||||
|
||||
| Command | What it does |
|
||||
| --------------------- | -------------------------------------------------------------- |
|
||||
| `gemini gemma setup` | Full install (binary + model + settings + server start) |
|
||||
| `gemini gemma status` | Health check — shows what's installed and running |
|
||||
| `gemini gemma start` | Start the LiteRT server (auto-starts on CLI launch by default) |
|
||||
| `gemini gemma stop` | Stop the LiteRT server |
|
||||
| `gemini gemma logs` | Tail the server logs to see routing requests live |
|
||||
| `/gemma` | In-session status check (type it inside the CLI) |
|
||||
|
||||
## Verifying it works
|
||||
|
||||
1. Run `gemini gemma status` — all checks should show green
|
||||
2. Open two terminals:
|
||||
- Terminal 1: `gemini gemma logs` (watch for incoming requests)
|
||||
- Terminal 2: use the CLI normally
|
||||
3. You should see classification requests appear in the logs as you interact
|
||||
with the CLI
|
||||
4. The `/gemma` slash command inside a session shows a quick status panel
|
||||
|
||||
## Setup flags
|
||||
|
||||
```bash
|
||||
gemini gemma setup --port 8080 # custom port
|
||||
gemini gemma setup --no-start # don't start server after install
|
||||
gemini gemma setup --force # re-download everything
|
||||
gemini gemma setup --skip-model # binary only, skip the 1GB model download
|
||||
```
|
||||
|
||||
## How it works under the hood
|
||||
|
||||
- Local Gemma classifies each request as "simple" or "complex" (~100ms)
|
||||
- Simple → Flash, Complex → Pro
|
||||
- If the local server is down, the CLI silently falls back to the cloud
|
||||
classifier — no errors, no disruption
|
||||
|
||||
## Disabling
|
||||
|
||||
Set `enabled: false` in settings or just run `gemini gemma stop` to turn off the
|
||||
server:
|
||||
|
||||
```json
|
||||
{ "experimental": { "gemmaModelRouter": { "enabled": false } } }
|
||||
```
|
||||
|
||||
## Advanced setup
|
||||
|
||||
If you are in an environment where the `gemini gemma setup` command cannot
|
||||
automatically download binaries (for example, behind a strict corporate
|
||||
firewall), you can perform the setup manually.
|
||||
|
||||
For more information, see the
|
||||
[Manual Local Model Routing Setup guide](./local-model-routing.md).
|
||||
@@ -0,0 +1,109 @@
|
||||
# Gemini CLI core
|
||||
|
||||
Gemini CLI's core package (`packages/core`) is the backend portion of Gemini
|
||||
CLI, handling communication with the Gemini API, managing tools, and processing
|
||||
requests sent from `packages/cli`. For a general overview of Gemini CLI, see the
|
||||
[main documentation page](../index.md).
|
||||
|
||||
## Navigating this section
|
||||
|
||||
- **[Sub-agents](./subagents.md):** Learn how to create and use specialized
|
||||
sub-agents for complex tasks.
|
||||
- **[Core tools reference](../reference/tools.md):** Information on how tools
|
||||
are defined, registered, and used by the core.
|
||||
- **[Memory Import Processor](../reference/memport.md):** Documentation for the
|
||||
modular GEMINI.md import feature using @file.md syntax.
|
||||
- **[Policy Engine](../reference/policy-engine.md):** Use the Policy Engine for
|
||||
fine-grained control over tool execution.
|
||||
- **[Local Model Routing (experimental)](./gemma-setup.md):** Learn how to
|
||||
enable use of a local Gemma model for model routing decisions using the
|
||||
automated setup command.
|
||||
|
||||
## Role of the core
|
||||
|
||||
While the `packages/cli` portion of Gemini CLI provides the user interface,
|
||||
`packages/core` is responsible for:
|
||||
|
||||
- **Gemini API interaction:** Securely communicating with the Google Gemini API,
|
||||
sending user prompts, and receiving model responses.
|
||||
- **Prompt engineering:** Constructing effective prompts for the Gemini model,
|
||||
potentially incorporating conversation history, tool definitions, and
|
||||
instructional context from `GEMINI.md` files.
|
||||
- **Tool management & orchestration:**
|
||||
- Registering available tools (for example, file system tools, shell command
|
||||
execution).
|
||||
- Interpreting tool use requests from the Gemini model.
|
||||
- Executing the requested tools with the provided arguments.
|
||||
- Returning tool execution results to the Gemini model for further processing.
|
||||
- **Session and state management:** Keeping track of the conversation state,
|
||||
including history and any relevant context required for coherent interactions.
|
||||
- **Configuration:** Managing core-specific configurations, such as API key
|
||||
access, model selection, and tool settings.
|
||||
|
||||
## Security considerations
|
||||
|
||||
The core plays a vital role in security:
|
||||
|
||||
- **API key management:** It handles the `GEMINI_API_KEY` and ensures it's used
|
||||
securely when communicating with the Gemini API.
|
||||
- **Tool execution:** When tools interact with the local system (for example,
|
||||
`run_shell_command`), the core (and its underlying tool implementations) must
|
||||
do so with appropriate caution, often involving sandboxing mechanisms to
|
||||
prevent unintended modifications.
|
||||
|
||||
## Chat history compression
|
||||
|
||||
To ensure that long conversations don't exceed the token limits of the Gemini
|
||||
model, the core includes a chat history compression feature.
|
||||
|
||||
When a conversation approaches the token limit for the configured model, the
|
||||
core automatically compresses the conversation history before sending it to the
|
||||
model. This compression is designed to be lossless in terms of the information
|
||||
conveyed, but it reduces the overall number of tokens used.
|
||||
|
||||
You can find the token limits for each model in the
|
||||
[Google AI documentation](https://ai.google.dev/gemini-api/docs/models).
|
||||
|
||||
## Model fallback
|
||||
|
||||
Gemini CLI includes a model fallback mechanism to ensure that you can continue
|
||||
to use the CLI even if the default "pro" model is rate-limited.
|
||||
|
||||
If you are using the default "pro" model and the CLI detects that you are being
|
||||
rate-limited, it automatically switches to the "flash" model for the current
|
||||
session. This lets you continue working without interruption.
|
||||
|
||||
Internal utility calls that use `gemini-2.5-flash-lite` (for example, prompt
|
||||
completion and classification) silently fall back to `gemini-2.5-flash` and
|
||||
`gemini-2.5-pro` when quota is exhausted, without changing the configured model.
|
||||
|
||||
## File discovery service
|
||||
|
||||
The file discovery service is responsible for finding files in the project that
|
||||
are relevant to the current context. It is used by the `@` command and other
|
||||
tools that need to access files.
|
||||
|
||||
## Memory discovery service
|
||||
|
||||
The memory discovery service is responsible for finding and loading the
|
||||
`GEMINI.md` files that provide context to the model. It searches for these files
|
||||
in a hierarchical manner, starting from the current working directory and moving
|
||||
up to the project root and the user's home directory. It also searches in
|
||||
subdirectories.
|
||||
|
||||
This lets you have global, project-level, and component-level context files,
|
||||
which are all combined to provide the model with the most relevant information.
|
||||
|
||||
You can use the [`/memory` command](../reference/commands.md) to `show`, `add`,
|
||||
and `refresh` the content of loaded `GEMINI.md` files.
|
||||
|
||||
## Citations
|
||||
|
||||
When Gemini finds it is reciting text from a source it appends the citation to
|
||||
the output. It is enabled by default but can be disabled with the
|
||||
ui.showCitations setting.
|
||||
|
||||
- When proposing an edit the citations display before giving the user the option
|
||||
to accept.
|
||||
- Citations are always shown at the end of the model’s turn.
|
||||
- We deduplicate citations and display them in alphabetical order.
|
||||
@@ -0,0 +1,200 @@
|
||||
# Manual Local Model Routing Setup (experimental)
|
||||
|
||||
Gemini CLI supports using a local model for
|
||||
[routing decisions](../cli/model-routing.md). When configured, Gemini CLI will
|
||||
use a locally-running **Gemma** model to make routing decisions (instead of
|
||||
sending routing decisions to a hosted model).
|
||||
|
||||
<!-- prettier-ignore -->
|
||||
> [!NOTE]
|
||||
> This is an experimental feature currently under active development.
|
||||
|
||||
<!-- prettier-ignore -->
|
||||
> [!IMPORTANT]
|
||||
> **Recommended:** We now provide a fully automated setup command. We recommend
|
||||
> using the [`gemini gemma` Setup Guide](./gemma-setup.md) instead of following
|
||||
> these manual steps.
|
||||
|
||||
This feature can help reduce costs associated with hosted model usage while
|
||||
offering similar routing decision latency and quality.
|
||||
|
||||
## Manual Setup
|
||||
|
||||
Using a Gemma model for routing decisions requires that an implementation of a
|
||||
Gemma model be running locally on your machine, served behind an HTTP endpoint
|
||||
and accessed via the Gemini API. If you cannot use the `gemini gemma setup`
|
||||
command, follow these manual steps:
|
||||
|
||||
### Download the LiteRT-LM runtime
|
||||
|
||||
The [LiteRT-LM](https://github.com/google-ai-edge/LiteRT-LM) runtime offers
|
||||
pre-built binaries for locally-serving models. Download the binary appropriate
|
||||
for your system.
|
||||
|
||||
#### Windows
|
||||
|
||||
1. Download
|
||||
[lit.windows_x86_64.exe](https://github.com/google-ai-edge/LiteRT-LM/releases/download/v0.9.0-alpha03/lit.windows_x86_64.exe).
|
||||
2. Using GPU on Windows requires the DirectXShaderCompiler. Download the
|
||||
[dxc zip from the latest release](https://github.com/microsoft/DirectXShaderCompiler/releases/download/v1.8.2505.1/dxc_2025_07_14.zip).
|
||||
Unzip the archive and from the architecture-appropriate `bin\` directory, and
|
||||
copy the `dxil.dll` and `dxcompiler.dll` into the same location as you saved
|
||||
`lit.windows_x86_64.exe`.
|
||||
3. (Optional) Test starting the runtime:
|
||||
`.\lit.windows_x86_64.exe serve --verbose`
|
||||
|
||||
#### Linux
|
||||
|
||||
1. Download
|
||||
[lit.linux_x86_64](https://github.com/google-ai-edge/LiteRT-LM/releases/download/v0.9.0-alpha03/lit.linux_x86_64).
|
||||
2. Ensure the binary is executable: `chmod a+x lit.linux_x86_64`
|
||||
3. (Optional) Test starting the runtime: `./lit.linux_x86_64 serve --verbose`
|
||||
|
||||
#### MacOS
|
||||
|
||||
1. Download
|
||||
[lit-macos-arm64](https://github.com/google-ai-edge/LiteRT-LM/releases/download/v0.9.0-alpha03/lit.macos_arm64).
|
||||
2. Ensure the binary is executable: `chmod a+x lit.macos_arm64`
|
||||
3. (Optional) Test starting the runtime: `./lit.macos_arm64 serve --verbose`
|
||||
|
||||
> **Note**: MacOS can be configured to only allows binaries from "App Store &
|
||||
> Known Developers". If you encounter an error message when attempting to run
|
||||
> the binary, you will need to allow the application. One option is to visit
|
||||
> `System Settings -> Privacy & Security`, scroll to `Security`, and click
|
||||
> `"Allow Anyway"` for `"lit.macos_arm64"`. Another option is to run
|
||||
> `xattr -d com.apple.quarantine lit.macos_arm64` from the commandline.
|
||||
|
||||
### Download the Gemma Model
|
||||
|
||||
Before using Gemma, you will need to download the model (and agree to the Terms
|
||||
of Service).
|
||||
|
||||
This can be done via the LiteRT-LM runtime.
|
||||
|
||||
#### Windows
|
||||
|
||||
```bash
|
||||
$ .\lit.windows_x86_64.exe pull gemma3-1b-gpu-custom
|
||||
|
||||
[Legal] The model you are about to download is governed by
|
||||
the Gemma Terms of Use and Prohibited Use Policy. Please review these terms and ensure you agree before continuing.
|
||||
|
||||
Full Terms: https://ai.google.dev/gemma/terms
|
||||
Prohibited Use Policy: https://ai.google.dev/gemma/prohibited_use_policy
|
||||
|
||||
Do you accept these terms? (Y/N): Y
|
||||
|
||||
Terms accepted.
|
||||
Downloading model 'gemma3-1b-gpu-custom' ...
|
||||
Downloading... 968.6 MB
|
||||
Download complete.
|
||||
```
|
||||
|
||||
#### Linux
|
||||
|
||||
```bash
|
||||
$ ./lit.linux_x86_64 pull gemma3-1b-gpu-custom
|
||||
|
||||
[Legal] The model you are about to download is governed by
|
||||
the Gemma Terms of Use and Prohibited Use Policy. Please review these terms and ensure you agree before continuing.
|
||||
|
||||
Full Terms: https://ai.google.dev/gemma/terms
|
||||
Prohibited Use Policy: https://ai.google.dev/gemma/prohibited_use_policy
|
||||
|
||||
Do you accept these terms? (Y/N): Y
|
||||
|
||||
Terms accepted.
|
||||
Downloading model 'gemma3-1b-gpu-custom' ...
|
||||
Downloading... 968.6 MB
|
||||
Download complete.
|
||||
```
|
||||
|
||||
#### MacOS
|
||||
|
||||
```bash
|
||||
$ ./lit.lit.macos_arm64 pull gemma3-1b-gpu-custom
|
||||
|
||||
[Legal] The model you are about to download is governed by
|
||||
the Gemma Terms of Use and Prohibited Use Policy. Review these terms and ensure you agree before continuing.
|
||||
|
||||
Full Terms: https://ai.google.dev/gemma/terms
|
||||
Prohibited Use Policy: https://ai.google.dev/gemma/prohibited_use_policy
|
||||
|
||||
Do you accept these terms? (Y/N): Y
|
||||
|
||||
Terms accepted.
|
||||
Downloading model 'gemma3-1b-gpu-custom' ...
|
||||
Downloading... 968.6 MB
|
||||
Download complete.
|
||||
```
|
||||
|
||||
### Start LiteRT-LM Runtime
|
||||
|
||||
Using the command appropriate to your system, start the LiteRT-LM runtime.
|
||||
Configure the port that you want to use for your Gemma model. For the purposes
|
||||
of this document, we will use port `9379`.
|
||||
|
||||
Example command for MacOS: `./lit.macos_arm64 serve --port=9379 --verbose`
|
||||
|
||||
### (Optional) Verify Model Serving
|
||||
|
||||
Send a quick prompt to the model via HTTP to validate successful model serving.
|
||||
This will cause the runtime to download the model and run it once.
|
||||
|
||||
You should see a short joke in the server output as an indicator of success.
|
||||
|
||||
#### Windows
|
||||
|
||||
```
|
||||
# Run this in PowerShell to send a request to the server
|
||||
|
||||
$uri = "http://localhost:9379/v1beta/models/gemma3-1b-gpu-custom:generateContent"
|
||||
$body = @{contents = @( @{
|
||||
role = "user"
|
||||
parts = @( @{ text = "Tell me a joke." } )
|
||||
})} | ConvertTo-Json -Depth 10
|
||||
|
||||
Invoke-RestMethod -Uri $uri -Method Post -Body $body -ContentType "application/json"
|
||||
```
|
||||
|
||||
#### Linux/MacOS
|
||||
|
||||
```bash
|
||||
$ curl "http://localhost:9379/v1beta/models/gemma3-1b-gpu-custom:generateContent" \
|
||||
-H 'Content-Type: application/json' \
|
||||
-X POST \
|
||||
-d '{"contents":[{"role":"user","parts":[{"text":"Tell me a joke."}]}]}'
|
||||
```
|
||||
|
||||
## Configuration
|
||||
|
||||
To use a local Gemma model for routing, you must explicitly enable it in your
|
||||
`settings.json`:
|
||||
|
||||
```json
|
||||
{
|
||||
"experimental": {
|
||||
"gemmaModelRouter": {
|
||||
"enabled": true,
|
||||
"classifier": {
|
||||
"host": "http://localhost:9379",
|
||||
"model": "gemma3-1b-gpu-custom"
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
> Use the port you started your LiteRT-LM runtime on in the setup steps.
|
||||
|
||||
### Configuration schema
|
||||
|
||||
| Field | Type | Required | Description |
|
||||
| :----------------- | :------ | :------- | :----------------------------------------------------------------------------------------- |
|
||||
| `enabled` | boolean | Yes | Must be `true` to enable the feature. |
|
||||
| `classifier` | object | Yes | The configuration for the local model endpoint. It includes the host and model specifiers. |
|
||||
| `classifier.host` | string | Yes | The URL to the local model server. Should be `http://localhost:<port>`. |
|
||||
| `classifier.model` | string | Yes | The model name to use for decisions. Must be `"gemma3-1b-gpu-custom"`. |
|
||||
|
||||
> **Note: You will need to restart after configuration changes for local model
|
||||
> routing to take effect.**
|
||||
@@ -0,0 +1,457 @@
|
||||
# Remote Subagents
|
||||
|
||||
Gemini CLI supports connecting to remote subagents using the Agent-to-Agent
|
||||
(A2A) protocol. This allows Gemini CLI to interact with other agents, expanding
|
||||
its capabilities by delegating tasks to remote services.
|
||||
|
||||
Gemini CLI can connect to any compliant A2A agent. You can find samples of A2A
|
||||
agents in the following repositories:
|
||||
|
||||
- [ADK Samples (Python)](https://github.com/google/adk-samples/tree/main/python)
|
||||
- [ADK Python Contributing Samples](https://github.com/google/adk-python/tree/main/contributing/samples)
|
||||
|
||||
## Proxy support
|
||||
|
||||
Gemini CLI routes traffic to remote agents through an HTTP/HTTPS proxy if one is
|
||||
configured. It uses the `general.proxy` setting in your `settings.json` file or
|
||||
standard environment variables (`HTTP_PROXY`, `HTTPS_PROXY`).
|
||||
|
||||
```json
|
||||
{
|
||||
"general": {
|
||||
"proxy": "http://my-proxy:8080"
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
## Defining remote subagents
|
||||
|
||||
Remote subagents are defined as Markdown files (`.md`) with YAML frontmatter.
|
||||
You can place them in:
|
||||
|
||||
1. **Project-level:** `.gemini/agents/*.md` (Shared with your team)
|
||||
2. **User-level:** `~/.gemini/agents/*.md` (Personal agents)
|
||||
|
||||
### Configuration schema
|
||||
|
||||
| Field | Type | Required | Description |
|
||||
| :---------------- | :----- | :------- | :------------------------------------------------------------------------------------------------------------- |
|
||||
| `kind` | string | Yes | Must be `remote`. |
|
||||
| `name` | string | Yes | A unique name for the agent. Must be a valid slug (lowercase letters, numbers, hyphens, and underscores only). |
|
||||
| `agent_card_url` | string | Yes\* | The URL to the agent's A2A card endpoint. Required if `agent_card_json` is not provided. |
|
||||
| `agent_card_json` | string | Yes\* | The inline JSON string of the agent's A2A card. Required if `agent_card_url` is not provided. |
|
||||
| `auth` | object | No | Authentication configuration. See [Authentication](#authentication). |
|
||||
|
||||
### Single-subagent example
|
||||
|
||||
```markdown
|
||||
---
|
||||
kind: remote
|
||||
name: my-remote-agent
|
||||
agent_card_url: https://example.com/agent-card
|
||||
---
|
||||
```
|
||||
|
||||
### Multi-subagent example
|
||||
|
||||
The loader explicitly supports multiple remote subagents defined in a single
|
||||
Markdown file.
|
||||
|
||||
```markdown
|
||||
---
|
||||
- kind: remote
|
||||
name: remote-1
|
||||
agent_card_url: https://example.com/1
|
||||
- kind: remote
|
||||
name: remote-2
|
||||
agent_card_url: https://example.com/2
|
||||
---
|
||||
```
|
||||
|
||||
<!-- prettier-ignore -->
|
||||
> [!NOTE] Mixed local and remote agents, or multiple local agents, are not
|
||||
> supported in a single file; the list format is currently remote-only.
|
||||
|
||||
### Inline Agent Card JSON
|
||||
|
||||
<details>
|
||||
<summary>View formatting options for JSON strings</summary>
|
||||
|
||||
If you don't have an endpoint serving the agent card, you can provide the A2A
|
||||
card directly as a JSON string using `agent_card_json`.
|
||||
|
||||
When providing a JSON string in YAML, you must properly format it as a string
|
||||
scalar. You can use single quotes, a block scalar, or double quotes (which
|
||||
require escaping internal double quotes).
|
||||
|
||||
#### Using single quotes
|
||||
|
||||
Single quotes allow you to embed unescaped double quotes inside the JSON string.
|
||||
This format is useful for shorter, single-line JSON strings.
|
||||
|
||||
```markdown
|
||||
---
|
||||
kind: remote
|
||||
name: single-quotes-agent
|
||||
agent_card_json:
|
||||
'{ "protocolVersion": "0.3.0", "name": "Example Agent", "version": "1.0.0",
|
||||
"url": "dummy-url" }'
|
||||
---
|
||||
```
|
||||
|
||||
#### Using a block scalar
|
||||
|
||||
The literal block scalar (`|`) preserves line breaks and is highly recommended
|
||||
for multiline JSON strings as it avoids quote escaping entirely. The following
|
||||
is a complete, valid Agent Card configuration using dummy values.
|
||||
|
||||
```markdown
|
||||
---
|
||||
kind: remote
|
||||
name: block-scalar-agent
|
||||
agent_card_json: |
|
||||
{
|
||||
"protocolVersion": "0.3.0",
|
||||
"name": "Example Agent Name",
|
||||
"description": "An example agent description for documentation purposes.",
|
||||
"version": "1.0.0",
|
||||
"url": "dummy-url",
|
||||
"preferredTransport": "HTTP+JSON",
|
||||
"capabilities": {
|
||||
"streaming": true,
|
||||
"extendedAgentCard": false
|
||||
},
|
||||
"defaultInputModes": [
|
||||
"text/plain"
|
||||
],
|
||||
"defaultOutputModes": [
|
||||
"application/json"
|
||||
],
|
||||
"skills": [
|
||||
{
|
||||
"id": "ExampleSkill",
|
||||
"name": "Example Skill Assistant",
|
||||
"description": "A description of what this example skill does.",
|
||||
"tags": [
|
||||
"example-tag"
|
||||
],
|
||||
"examples": [
|
||||
"Show me an example."
|
||||
]
|
||||
}
|
||||
]
|
||||
}
|
||||
---
|
||||
```
|
||||
|
||||
#### Using double quotes
|
||||
|
||||
Double quotes are also supported, but any internal double quotes in your JSON
|
||||
must be escaped with a backslash.
|
||||
|
||||
```markdown
|
||||
---
|
||||
kind: remote
|
||||
name: double-quotes-agent
|
||||
agent_card_json:
|
||||
'{ "protocolVersion": "0.3.0", "name": "Example Agent", "version": "1.0.0",
|
||||
"url": "dummy-url" }'
|
||||
---
|
||||
```
|
||||
|
||||
</details>
|
||||
|
||||
## Authentication
|
||||
|
||||
Many remote agents require authentication. Gemini CLI supports several
|
||||
authentication methods aligned with the
|
||||
[A2A security specification](https://a2a-protocol.org/latest/specification/#451-securityscheme).
|
||||
Add an `auth` block to your agent's frontmatter to configure credentials.
|
||||
|
||||
### Supported auth types
|
||||
|
||||
Gemini CLI supports the following authentication types:
|
||||
|
||||
| Type | Description |
|
||||
| :------------------- | :--------------------------------------------------------------------------------------------- |
|
||||
| `apiKey` | Send a static API key as an HTTP header. |
|
||||
| `http` | HTTP authentication (Bearer token, Basic credentials, or any IANA-registered scheme). |
|
||||
| `google-credentials` | Google Application Default Credentials (ADC). Automatically selects access or identity tokens. |
|
||||
| `oauth` | OAuth 2.0 Authorization Code flow with PKCE. Opens a browser for interactive sign-in. |
|
||||
|
||||
### Dynamic values
|
||||
|
||||
For `apiKey` and `http` auth types, secret values (`key`, `token`, `username`,
|
||||
`password`, `value`) support dynamic resolution:
|
||||
|
||||
| Format | Description | Example |
|
||||
| :---------- | :-------------------------------------------------- | :------------------------- |
|
||||
| `$ENV_VAR` | Read from an environment variable. | `$MY_API_KEY` |
|
||||
| `!command` | Execute a shell command and use the trimmed output. | `!gcloud auth print-token` |
|
||||
| literal | Use the string as-is. | `sk-abc123` |
|
||||
| `$$` / `!!` | Escape prefix. `$$FOO` becomes the literal `$FOO`. | `$$NOT_AN_ENV_VAR` |
|
||||
|
||||
> **Security tip:** Prefer `$ENV_VAR` or `!command` over embedding secrets
|
||||
> directly in agent files, especially for project-level agents checked into
|
||||
> version control.
|
||||
|
||||
### API key (`apiKey`)
|
||||
|
||||
Sends an API key as an HTTP header on every request.
|
||||
|
||||
| Field | Type | Required | Description |
|
||||
| :----- | :----- | :------- | :---------------------------------------------------- |
|
||||
| `type` | string | Yes | Must be `apiKey`. |
|
||||
| `key` | string | Yes | The API key value. Supports dynamic values. |
|
||||
| `name` | string | No | Header name to send the key in. Default: `X-API-Key`. |
|
||||
|
||||
```yaml
|
||||
---
|
||||
kind: remote
|
||||
name: my-agent
|
||||
agent_card_url: https://example.com/agent-card
|
||||
auth:
|
||||
type: apiKey
|
||||
key: $MY_API_KEY
|
||||
---
|
||||
```
|
||||
|
||||
### HTTP authentication (`http`)
|
||||
|
||||
Supports Bearer tokens, Basic auth, and arbitrary IANA-registered HTTP
|
||||
authentication schemes.
|
||||
|
||||
#### Bearer token
|
||||
|
||||
Use the following fields to configure a Bearer token:
|
||||
|
||||
| Field | Type | Required | Description |
|
||||
| :------- | :----- | :------- | :----------------------------------------- |
|
||||
| `type` | string | Yes | Must be `http`. |
|
||||
| `scheme` | string | Yes | Must be `Bearer`. |
|
||||
| `token` | string | Yes | The bearer token. Supports dynamic values. |
|
||||
|
||||
```yaml
|
||||
auth:
|
||||
type: http
|
||||
scheme: Bearer
|
||||
token: $MY_BEARER_TOKEN
|
||||
```
|
||||
|
||||
#### Basic authentication
|
||||
|
||||
Use the following fields to configure Basic authentication:
|
||||
|
||||
| Field | Type | Required | Description |
|
||||
| :--------- | :----- | :------- | :------------------------------------- |
|
||||
| `type` | string | Yes | Must be `http`. |
|
||||
| `scheme` | string | Yes | Must be `Basic`. |
|
||||
| `username` | string | Yes | The username. Supports dynamic values. |
|
||||
| `password` | string | Yes | The password. Supports dynamic values. |
|
||||
|
||||
```yaml
|
||||
auth:
|
||||
type: http
|
||||
scheme: Basic
|
||||
username: $MY_USERNAME
|
||||
password: $MY_PASSWORD
|
||||
```
|
||||
|
||||
#### Raw scheme
|
||||
|
||||
For any other IANA-registered scheme (for example, Digest, HOBA), provide the
|
||||
raw authorization value.
|
||||
|
||||
| Field | Type | Required | Description |
|
||||
| :------- | :----- | :------- | :---------------------------------------------------------------------------- |
|
||||
| `type` | string | Yes | Must be `http`. |
|
||||
| `scheme` | string | Yes | The scheme name (for example, `Digest`). |
|
||||
| `value` | string | Yes | Raw value sent as `Authorization: <scheme> <value>`. Supports dynamic values. |
|
||||
|
||||
```yaml
|
||||
auth:
|
||||
type: http
|
||||
scheme: Digest
|
||||
value: $MY_DIGEST_VALUE
|
||||
```
|
||||
|
||||
### Google Application Default Credentials (`google-credentials`)
|
||||
|
||||
Uses
|
||||
[Google Application Default Credentials (ADC)](https://cloud.google.com/docs/authentication/application-default-credentials)
|
||||
to authenticate with Google Cloud services and Cloud Run endpoints. This is the
|
||||
recommended auth method for agents hosted on Google Cloud infrastructure.
|
||||
|
||||
| Field | Type | Required | Description |
|
||||
| :------- | :------- | :------- | :-------------------------------------------------------------------------- |
|
||||
| `type` | string | Yes | Must be `google-credentials`. |
|
||||
| `scopes` | string[] | No | OAuth scopes. Defaults to `https://www.googleapis.com/auth/cloud-platform`. |
|
||||
|
||||
```yaml
|
||||
---
|
||||
kind: remote
|
||||
name: my-gcp-agent
|
||||
agent_card_url: https://my-agent-xyz.run.app/.well-known/agent.json
|
||||
auth:
|
||||
type: google-credentials
|
||||
---
|
||||
```
|
||||
|
||||
#### How token selection works
|
||||
|
||||
The provider automatically selects the correct token type based on the agent's
|
||||
host:
|
||||
|
||||
| Host pattern | Token type | Use case |
|
||||
| :----------------- | :----------------- | :------------------------------------------ |
|
||||
| `*.googleapis.com` | **Access token** | Google APIs (Agent Engine, Vertex AI, etc.) |
|
||||
| `*.run.app` | **Identity token** | Cloud Run services |
|
||||
|
||||
- **Access tokens** authorize API calls to Google services. They are scoped
|
||||
(default: `cloud-platform`) and fetched via `GoogleAuth.getClient()`.
|
||||
- **Identity tokens** prove the caller's identity to a service that validates
|
||||
the token's audience. The audience is set to the target host. These are
|
||||
fetched via `GoogleAuth.getIdTokenClient()`.
|
||||
|
||||
Both token types are cached and automatically refreshed before expiry.
|
||||
|
||||
#### Setup
|
||||
|
||||
`google-credentials` relies on ADC, which means your environment must have
|
||||
credentials configured. Common setups:
|
||||
|
||||
- **Local development:** Run `gcloud auth application-default login` to
|
||||
authenticate with your Google account.
|
||||
- **CI / Cloud environments:** Use a service account. Set the
|
||||
`GOOGLE_APPLICATION_CREDENTIALS` environment variable to the path of your
|
||||
service account key file, or use workload identity on GKE / Cloud Run.
|
||||
|
||||
#### Allowed hosts
|
||||
|
||||
For security, `google-credentials` only sends tokens to known Google-owned
|
||||
hosts:
|
||||
|
||||
- `*.googleapis.com`
|
||||
- `*.run.app`
|
||||
|
||||
Requests to any other host will be rejected with an error. If your agent is
|
||||
hosted on a different domain, use one of the other auth types (`apiKey`, `http`,
|
||||
or `oauth`).
|
||||
|
||||
#### Examples
|
||||
|
||||
The following examples demonstrate how to configure Google Application Default
|
||||
Credentials.
|
||||
|
||||
**Cloud Run agent:**
|
||||
|
||||
```yaml
|
||||
---
|
||||
kind: remote
|
||||
name: cloud-run-agent
|
||||
agent_card_url: https://my-agent-xyz.run.app/.well-known/agent.json
|
||||
auth:
|
||||
type: google-credentials
|
||||
---
|
||||
```
|
||||
|
||||
**Google API with custom scopes:**
|
||||
|
||||
```yaml
|
||||
---
|
||||
kind: remote
|
||||
name: vertex-agent
|
||||
agent_card_url: https://us-central1-aiplatform.googleapis.com/.well-known/agent.json
|
||||
auth:
|
||||
type: google-credentials
|
||||
scopes:
|
||||
- https://www.googleapis.com/auth/cloud-platform
|
||||
- https://www.googleapis.com/auth/compute
|
||||
---
|
||||
```
|
||||
|
||||
### OAuth 2.0 (`oauth`)
|
||||
|
||||
Performs an interactive OAuth 2.0 Authorization Code flow with PKCE. On first
|
||||
use, Gemini CLI opens your browser for sign-in and persists the resulting tokens
|
||||
for subsequent requests.
|
||||
|
||||
| Field | Type | Required | Description |
|
||||
| :------------------ | :------- | :------- | :------------------------------------------------------------------------------------------------------------------------------------------------- |
|
||||
| `type` | string | Yes | Must be `oauth`. |
|
||||
| `client_id` | string | Yes\* | OAuth client ID. Required for interactive auth. |
|
||||
| `client_secret` | string | No\* | OAuth client secret. Required by most authorization servers (confidential clients). Can be omitted for public clients that don't require a secret. |
|
||||
| `scopes` | string[] | No | Requested scopes. Can also be discovered from the agent card. |
|
||||
| `authorization_url` | string | No | Authorization endpoint. Discovered from the agent card if omitted. |
|
||||
| `token_url` | string | No | Token endpoint. Discovered from the agent card if omitted. |
|
||||
|
||||
```yaml
|
||||
---
|
||||
kind: remote
|
||||
name: oauth-agent
|
||||
agent_card_url: https://example.com/.well-known/agent.json
|
||||
auth:
|
||||
type: oauth
|
||||
client_id: my-client-id.apps.example.com
|
||||
---
|
||||
```
|
||||
|
||||
If the agent card advertises an `oauth2` security scheme with
|
||||
`authorizationCode` flow, the `authorization_url`, `token_url`, and `scopes` are
|
||||
automatically discovered. You only need to provide `client_id` (and
|
||||
`client_secret` if required).
|
||||
|
||||
Tokens are persisted to disk and refreshed automatically when they expire.
|
||||
|
||||
### Auth validation
|
||||
|
||||
When Gemini CLI loads a remote agent, it validates your auth configuration
|
||||
against the agent card's declared `securitySchemes`. If the agent requires
|
||||
authentication that you haven't configured, you'll see an error describing
|
||||
what's needed.
|
||||
|
||||
`google-credentials` is treated as compatible with `http` Bearer security
|
||||
schemes, since it produces Bearer tokens.
|
||||
|
||||
### Auth retry behavior
|
||||
|
||||
All auth providers automatically retry on `401` and `403` responses by
|
||||
re-fetching credentials (up to 2 retries). This handles cases like expired
|
||||
tokens or rotated credentials. For `apiKey` with `!command` values, the command
|
||||
is re-executed on retry to fetch a fresh key.
|
||||
|
||||
### Agent card fetching and auth
|
||||
|
||||
When connecting to a remote agent, Gemini CLI first fetches the agent card
|
||||
**without** authentication. If the card endpoint returns a `401` or `403`, it
|
||||
retries the fetch **with** the configured auth headers. This lets agents have
|
||||
publicly accessible cards while protecting their task endpoints, or to protect
|
||||
both behind auth.
|
||||
|
||||
## Managing Subagents
|
||||
|
||||
Users can manage subagents using the following commands within Gemini CLI:
|
||||
|
||||
- `/agents list`: Displays all available local and remote subagents.
|
||||
- `/agents reload`: Reloads the agent registry. Use this after adding or
|
||||
modifying agent definition files.
|
||||
- `/agents enable <agent_name>`: Enables a specific subagent.
|
||||
- `/agents disable <agent_name>`: Disables a specific subagent.
|
||||
|
||||
<!-- prettier-ignore -->
|
||||
> [!TIP]
|
||||
> You can use the `@cli_help` agent within Gemini CLI for assistance
|
||||
> with configuring subagents.
|
||||
|
||||
## Disabling remote agents
|
||||
|
||||
Remote subagents are enabled by default. To disable them, set `enableAgents` to
|
||||
`false` in your `settings.json`:
|
||||
|
||||
```json
|
||||
{
|
||||
"experimental": {
|
||||
"enableAgents": false
|
||||
}
|
||||
}
|
||||
```
|
||||
@@ -0,0 +1,598 @@
|
||||
# Subagents
|
||||
|
||||
Subagents are specialized agents that operate within your main Gemini CLI
|
||||
session. They are designed to handle specific, complex tasks—like deep codebase
|
||||
analysis, documentation lookup, or domain-specific reasoning—without cluttering
|
||||
the main agent's context or toolset.
|
||||
|
||||
## What are subagents?
|
||||
|
||||
Subagents are "specialists" that the main Gemini agent can hire for a specific
|
||||
job.
|
||||
|
||||
- **Focused context:** Each subagent has its own system prompt and persona.
|
||||
- **Specialized tools:** Subagents can have a restricted or specialized set of
|
||||
tools.
|
||||
- **Independent context window:** Interactions with a subagent happen in a
|
||||
separate context loop, which saves tokens in your main conversation history.
|
||||
|
||||
Subagents are exposed to the main agent as a tool of the same name. When the
|
||||
main agent calls the tool, it delegates the task to the subagent. Once the
|
||||
subagent completes its task, it reports back to the main agent with its
|
||||
findings.
|
||||
|
||||
## How to use subagents
|
||||
|
||||
You can use subagents through automatic delegation or by explicitly forcing them
|
||||
in your prompt.
|
||||
|
||||
### Automatic delegation
|
||||
|
||||
Gemini CLI's main agent is instructed to use specialized subagents when a task
|
||||
matches their expertise. For example, if you ask "How does the auth system
|
||||
work?", the main agent may decide to call the `codebase_investigator` subagent
|
||||
to perform the research.
|
||||
|
||||
### Forcing a subagent (@ syntax)
|
||||
|
||||
You can explicitly direct a task to a specific subagent by using the `@` symbol
|
||||
followed by the subagent's name at the beginning of your prompt. This is useful
|
||||
when you want to bypass the main agent's decision-making and go straight to a
|
||||
specialist.
|
||||
|
||||
**Example:**
|
||||
|
||||
```bash
|
||||
@codebase_investigator Map out the relationship between the AgentRegistry and the LocalAgentExecutor.
|
||||
```
|
||||
|
||||
When you use the `@` syntax, the CLI injects a system note that nudges the
|
||||
primary model to use that specific subagent tool immediately.
|
||||
|
||||
## Built-in subagents
|
||||
|
||||
Gemini CLI comes with the following built-in subagents:
|
||||
|
||||
### Codebase Investigator
|
||||
|
||||
- **Name:** `codebase_investigator`
|
||||
- **Purpose:** Analyze the codebase, reverse engineer, and understand complex
|
||||
dependencies.
|
||||
- **When to use:** "How does the authentication system work?", "Map out the
|
||||
dependencies of the `AgentRegistry` class."
|
||||
- **Configuration:** Enabled by default. You can override its settings in
|
||||
`settings.json` under `agents.overrides`. Example (forcing a specific model
|
||||
and increasing turns):
|
||||
```json
|
||||
{
|
||||
"agents": {
|
||||
"overrides": {
|
||||
"codebase_investigator": {
|
||||
"modelConfig": { "model": "gemini-3-flash-preview" },
|
||||
"runConfig": { "maxTurns": 50 }
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
### CLI Help Agent
|
||||
|
||||
- **Name:** `cli_help`
|
||||
- **Purpose:** Get expert knowledge about Gemini CLI itself, its commands,
|
||||
configuration, and documentation.
|
||||
- **When to use:** "How do I configure a proxy?", "What does the `/rewind`
|
||||
command do?"
|
||||
- **Configuration:** Enabled by default.
|
||||
|
||||
### Generalist Agent
|
||||
|
||||
- **Name:** `generalist`
|
||||
- **Purpose:** A general, all-purpose subagent that uses the inherited tool
|
||||
access and configurations from the main agent. Useful for executing broad,
|
||||
resource-heavy subtasks in an isolated conversation, optimizing your main
|
||||
agent's context by returning only the final result of that given task.
|
||||
- **When to use:** Use this agent when a task requires many steps, handles large
|
||||
volumes of information, or requires the same full capabilities as the main
|
||||
agent. It is ideal for:
|
||||
- **Multi-file modifications:** Applying refactors or fixing errors across
|
||||
several files at once.
|
||||
- **High-volume execution:** Running commands or tests that produce extensive
|
||||
terminal output.
|
||||
- **Action-oriented research:** Investigations where the agent needs to both
|
||||
search code and run commands or make edits to find a solution. By delegating
|
||||
these tasks, you prevent your main conversation from becoming cluttered or
|
||||
slow. You can invoke it explicitly using `@generalist`.
|
||||
- **Configuration:** Enabled by default.
|
||||
|
||||
### Browser Agent
|
||||
|
||||
- **Name:** `browser_agent`
|
||||
- **Purpose:** Automate web browser tasks — navigating websites, filling forms,
|
||||
clicking buttons, and extracting information from web pages — using the
|
||||
accessibility tree.
|
||||
- **When to use:** "Go to example.com and fill out the contact form," "Extract
|
||||
the pricing table from this page," "Click the login button and enter my
|
||||
credentials."
|
||||
|
||||
#### Prerequisites
|
||||
|
||||
The browser agent requires:
|
||||
|
||||
- **Chrome** version 144 or later (any recent stable release works).
|
||||
|
||||
The underlying
|
||||
[`chrome-devtools-mcp`](https://www.npmjs.com/package/chrome-devtools-mcp)
|
||||
server is bundled with Gemini CLI and launched automatically — no separate
|
||||
installation is needed.
|
||||
|
||||
#### Enabling the browser agent
|
||||
|
||||
The browser agent is disabled by default. Enable it in your `settings.json`:
|
||||
|
||||
```json
|
||||
{
|
||||
"agents": {
|
||||
"overrides": {
|
||||
"browser_agent": {
|
||||
"enabled": true
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
#### Session modes
|
||||
|
||||
The `sessionMode` setting controls how Chrome is launched and managed. Set it
|
||||
under `agents.browser`:
|
||||
|
||||
```json
|
||||
{
|
||||
"agents": {
|
||||
"overrides": {
|
||||
"browser_agent": {
|
||||
"enabled": true
|
||||
}
|
||||
},
|
||||
"browser": {
|
||||
"sessionMode": "persistent"
|
||||
}
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
The available modes are:
|
||||
|
||||
| Mode | Description |
|
||||
| :----------- | :------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
|
||||
| `persistent` | **(Default)** Launches Chrome with a persistent profile stored at `~/.gemini/cli-browser-profile/`. Cookies, history, and settings are preserved between sessions. |
|
||||
| `isolated` | Launches Chrome with a temporary profile that is deleted after each session. Use this for clean-state automation. |
|
||||
| `existing` | Attaches to an already-running Chrome instance. You must enable remote debugging first by navigating to `chrome://inspect/#remote-debugging` in Chrome. No new browser process is launched. |
|
||||
|
||||
#### First-run consent
|
||||
|
||||
The first time the browser agent is invoked, Gemini CLI displays a consent
|
||||
dialog. You must accept before the browser session starts. This dialog only
|
||||
appears once.
|
||||
|
||||
#### Configuration reference
|
||||
|
||||
All browser-specific settings go under `agents.browser` in your `settings.json`.
|
||||
For full details, see the
|
||||
[`agents.browser` configuration reference](../reference/configuration.md#agents).
|
||||
|
||||
| Setting | Type | Default | Description |
|
||||
| :------------------------ | :--------- | :------------- | :------------------------------------------------------------------------------ |
|
||||
| `sessionMode` | `string` | `"persistent"` | How Chrome is managed: `"persistent"`, `"isolated"`, or `"existing"`. |
|
||||
| `headless` | `boolean` | `false` | Run Chrome in headless mode (no visible window). |
|
||||
| `profilePath` | `string` | — | Custom path to a browser profile directory. |
|
||||
| `visualModel` | `string` | — | Model override for the visual agent. |
|
||||
| `allowedDomains` | `string[]` | — | Restrict navigation to specific domains (for example, `["github.com"]`). |
|
||||
| `disableUserInput` | `boolean` | `true` | Disable user input on the browser window during automation (non-headless only). |
|
||||
| `maxActionsPerTask` | `number` | `100` | Maximum tool calls per task. The agent is terminated when the limit is reached. |
|
||||
| `confirmSensitiveActions` | `boolean` | `false` | Require manual confirmation for `upload_file` and `evaluate_script`. |
|
||||
| `blockFileUploads` | `boolean` | `false` | Hard-block all file upload requests from the agent. |
|
||||
|
||||
#### Automation overlay and input blocking
|
||||
|
||||
In non-headless mode, the browser agent injects a visual overlay into the
|
||||
browser window to indicate that automation is in progress. By default, user
|
||||
input (keyboard and mouse) is also blocked to prevent accidental interference.
|
||||
You can disable this by setting `disableUserInput` to `false`.
|
||||
|
||||
#### Security
|
||||
|
||||
The browser agent enforces several layers of security:
|
||||
|
||||
- **Domain restrictions:** When `allowedDomains` is set, the agent can only
|
||||
navigate to the listed domains (and their subdomains when using `*.` prefix).
|
||||
Attempting to visit a disallowed domain throws a fatal error that immediately
|
||||
terminates the agent. The agent also attempts to detect and block the use of
|
||||
allowed domains as proxies (e.g., via query parameters or fragments) to access
|
||||
restricted content.
|
||||
- **Blocked URL patterns:** The underlying MCP server blocks dangerous URL
|
||||
schemes including `file://`, `javascript:`, `data:text/html`,
|
||||
`chrome://extensions`, and `chrome://settings/passwords`.
|
||||
- **Sensitive action confirmation:** Form filling (`fill`, `fill_form`) always
|
||||
requires user confirmation through the policy engine, regardless of approval
|
||||
mode. When `confirmSensitiveActions` is `true`, `upload_file` and
|
||||
`evaluate_script` also require confirmation.
|
||||
- **File upload blocking:** Set `blockFileUploads` to `true` to hard-block all
|
||||
file upload requests, preventing the agent from uploading any files.
|
||||
- **Action rate limiting:** The `maxActionsPerTask` setting (default: 100)
|
||||
limits the total number of tool calls per task to prevent runaway execution.
|
||||
|
||||
#### Visual agent
|
||||
|
||||
By default, the browser agent interacts with pages through the accessibility
|
||||
tree using element `uid` values. For tasks that require visual identification
|
||||
(for example, "click the yellow button" or "find the red error message"), you
|
||||
can enable the visual agent by setting a `visualModel`:
|
||||
|
||||
```json
|
||||
{
|
||||
"agents": {
|
||||
"overrides": {
|
||||
"browser_agent": {
|
||||
"enabled": true
|
||||
}
|
||||
},
|
||||
"browser": {
|
||||
"visualModel": "gemini-2.5-computer-use-preview-10-2025"
|
||||
}
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
When enabled, the agent gains access to the `analyze_screenshot` tool, which
|
||||
captures a screenshot and sends it to the vision model for analysis. The model
|
||||
returns coordinates and element descriptions that the browser agent uses with
|
||||
the `click_at` tool for precise, coordinate-based interactions.
|
||||
|
||||
<!-- prettier-ignore -->
|
||||
> [!NOTE]
|
||||
> The visual agent requires API key or Vertex AI authentication. It is
|
||||
> not available when using "Sign in with Google".
|
||||
|
||||
#### Sandbox support
|
||||
|
||||
The browser agent adjusts its behavior automatically when running inside a
|
||||
sandbox.
|
||||
|
||||
##### macOS seatbelt (`sandbox-exec`)
|
||||
|
||||
When the CLI runs under the macOS seatbelt sandbox, `persistent` and `isolated`
|
||||
session modes are forced to `isolated` with `headless` enabled. This avoids
|
||||
permission errors caused by seatbelt file-system restrictions on persistent
|
||||
browser profiles. If `sessionMode` is set to `existing`, no override is applied.
|
||||
|
||||
##### Container sandboxes (Docker / Podman)
|
||||
|
||||
Chrome is not available inside the container, so the browser agent is
|
||||
**disabled** unless `sessionMode` is set to `"existing"`. When enabled with
|
||||
`existing` mode, the agent automatically connects to Chrome on the host via the
|
||||
resolved IP of `host.docker.internal:9222` instead of using local pipe
|
||||
discovery. Port `9222` is currently hardcoded and cannot be customized.
|
||||
|
||||
To use the browser agent in a Docker sandbox:
|
||||
|
||||
1. Start Chrome on the host with remote debugging enabled:
|
||||
|
||||
```bash
|
||||
# Option A: Launch Chrome from the command line
|
||||
google-chrome --remote-debugging-port=9222
|
||||
|
||||
# Option B: Enable in Chrome settings
|
||||
# Navigate to chrome://inspect/#remote-debugging and enable
|
||||
```
|
||||
|
||||
2. Configure `sessionMode` and allowed domains in your project's
|
||||
`.gemini/settings.json`:
|
||||
|
||||
```json
|
||||
{
|
||||
"agents": {
|
||||
"overrides": {
|
||||
"browser_agent": { "enabled": true }
|
||||
},
|
||||
"browser": {
|
||||
"sessionMode": "existing",
|
||||
"allowedDomains": ["example.com"]
|
||||
}
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
3. Launch the CLI with port forwarding:
|
||||
|
||||
```bash
|
||||
GEMINI_SANDBOX=docker SANDBOX_PORTS=9222 gemini
|
||||
```
|
||||
|
||||
## Creating custom subagents
|
||||
|
||||
You can create your own subagents to automate specific workflows or enforce
|
||||
specific personas.
|
||||
|
||||
### Agent definition files
|
||||
|
||||
Custom agents are defined as Markdown files (`.md`) with YAML frontmatter. You
|
||||
can place them in:
|
||||
|
||||
1. **Project-level:** `.gemini/agents/*.md` (Shared with your team)
|
||||
2. **User-level:** `~/.gemini/agents/*.md` (Personal agents)
|
||||
|
||||
### File format
|
||||
|
||||
The file **MUST** start with YAML frontmatter enclosed in triple-dashes `---`.
|
||||
The body of the markdown file becomes the agent's **System Prompt**.
|
||||
|
||||
**Example: `.gemini/agents/security-auditor.md`**
|
||||
|
||||
```markdown
|
||||
---
|
||||
name: security-auditor
|
||||
description: Specialized in finding security vulnerabilities in code.
|
||||
kind: local
|
||||
tools:
|
||||
- read_file
|
||||
- grep_search
|
||||
model: gemini-3-flash-preview
|
||||
temperature: 0.2
|
||||
max_turns: 10
|
||||
---
|
||||
|
||||
You are a ruthless Security Auditor. Your job is to analyze code for potential
|
||||
vulnerabilities.
|
||||
|
||||
Focus on:
|
||||
|
||||
1. SQL Injection
|
||||
2. XSS (Cross-Site Scripting)
|
||||
3. Hardcoded credentials
|
||||
4. Unsafe file operations
|
||||
|
||||
When you find a vulnerability, explain it clearly and suggest a fix. Do not fix
|
||||
it yourself; just report it.
|
||||
```
|
||||
|
||||
### Configuration schema
|
||||
|
||||
| Field | Type | Required | Description |
|
||||
| :------------- | :----- | :------- | :------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
|
||||
| `name` | string | Yes | Unique identifier (slug) used as the tool name for the agent. Only lowercase letters, numbers, hyphens, and underscores. |
|
||||
| `description` | string | Yes | Short description of what the agent does. This is visible to the main agent to help it decide when to call this subagent. |
|
||||
| `kind` | string | No | `local` (default) or `remote`. |
|
||||
| `tools` | array | No | List of tool names this agent can use. Supports wildcards: `*` (all tools), `mcp_*` (all MCP tools), `mcp_server_*` (all tools from a server). **If omitted, it inherits all tools from the parent session.** |
|
||||
| `mcpServers` | object | No | Configuration for inline Model Context Protocol (MCP) servers isolated to this specific agent. |
|
||||
| `model` | string | No | Specific model to use (for example, `gemini-3-preview`). Defaults to `inherit` (uses the main session model). |
|
||||
| `temperature` | number | No | Model temperature (0.0 - 2.0). Defaults to `1`. |
|
||||
| `max_turns` | number | No | Maximum number of conversation turns allowed for this agent before it must return. Defaults to `30`. |
|
||||
| `timeout_mins` | number | No | Maximum execution time in minutes. Defaults to `10`. |
|
||||
|
||||
### Tool wildcards
|
||||
|
||||
When defining `tools` for a subagent, you can use wildcards to quickly grant
|
||||
access to groups of tools:
|
||||
|
||||
- `*`: Grant access to all available built-in and discovered tools.
|
||||
- `mcp_*`: Grant access to all tools from all connected MCP servers.
|
||||
- `mcp_my-server_*`: Grant access to all tools from a specific MCP server named
|
||||
`my-server`.
|
||||
|
||||
### Isolation and recursion protection
|
||||
|
||||
Each subagent runs in its own isolated context loop. This means:
|
||||
|
||||
- **Independent history:** The subagent's conversation history does not bloat
|
||||
the main agent's context.
|
||||
- **Isolated tools:** The subagent only has access to the tools you explicitly
|
||||
grant it.
|
||||
- **Recursion protection:** To prevent infinite loops and excessive token usage,
|
||||
subagents **cannot** call other subagents. If a subagent is granted the `*`
|
||||
tool wildcard, it will still be unable to see or invoke other agents.
|
||||
|
||||
## Subagent tool isolation
|
||||
|
||||
Subagent tool isolation moves Gemini CLI away from a single global tool
|
||||
registry. By providing isolated execution environments, you can ensure that
|
||||
subagents only interact with the parts of the system they are designed for. This
|
||||
prevents unintended side effects, improves reliability by avoiding state
|
||||
contamination, and enables fine-grained permission control.
|
||||
|
||||
With this feature, you can:
|
||||
|
||||
- **Specify tool access:** Define exactly which tools an agent can access using
|
||||
a `tools` list in the agent definition.
|
||||
- **Define inline MCP servers:** Configure Model Context Protocol (MCP) servers
|
||||
(which provide a standardized way to connect AI models to external tools and
|
||||
data sources) directly in the subagent's markdown frontmatter, isolating them
|
||||
to that specific agent.
|
||||
- **Maintain state isolation:** Ensure that subagents only interact with their
|
||||
own set of tools and servers, preventing side effects and state contamination.
|
||||
- **Apply subagent-specific policies:** Enforce granular rules in your
|
||||
[Policy Engine](../reference/policy-engine.md) TOML configuration based on the
|
||||
executing subagent's name.
|
||||
|
||||
### Configuring isolated tools and servers
|
||||
|
||||
You can configure tool isolation for a subagent by updating its markdown
|
||||
frontmatter. This lets you explicitly state which tools the subagent can use,
|
||||
rather than relying on the global registry.
|
||||
|
||||
Add an `mcpServers` object to define inline MCP servers that are unique to the
|
||||
agent.
|
||||
|
||||
**Example:**
|
||||
|
||||
```yaml
|
||||
---
|
||||
name: my-isolated-agent
|
||||
tools:
|
||||
- grep_search
|
||||
- read_file
|
||||
mcpServers:
|
||||
my-custom-server:
|
||||
command: 'node'
|
||||
args: ['path/to/server.js']
|
||||
---
|
||||
```
|
||||
|
||||
### Subagent-specific policies
|
||||
|
||||
You can enforce fine-grained control over subagents using the
|
||||
[Policy Engine's](../reference/policy-engine.md) TOML configuration. This allows
|
||||
you to grant or restrict permissions specifically for an agent, without
|
||||
affecting the rest of your CLI session.
|
||||
|
||||
To restrict a policy rule to a specific subagent, add the `subagent` property to
|
||||
the `[[rules]]` block in your `policy.toml` file.
|
||||
|
||||
**Example:**
|
||||
|
||||
```toml
|
||||
[[rules]]
|
||||
name = "Allow pr-creator to push code"
|
||||
subagent = "pr-creator"
|
||||
description = "Permit pr-creator to push branches automatically."
|
||||
action = "allow"
|
||||
toolName = "run_shell_command"
|
||||
commandPrefix = "git push"
|
||||
```
|
||||
|
||||
In this configuration, the policy rule only triggers if the executing subagent's
|
||||
name matches `pr-creator`. Rules without the `subagent` property apply
|
||||
universally to all agents.
|
||||
|
||||
## Managing subagents
|
||||
|
||||
You can manage subagents interactively using the `/agents` command or
|
||||
persistently via `settings.json`.
|
||||
|
||||
### Interactive management (/agents)
|
||||
|
||||
If you are in an interactive CLI session, you can use the `/agents` command to
|
||||
manage subagents without editing configuration files manually. This is the
|
||||
recommended way to quickly enable, disable, or re-configure agents on the fly.
|
||||
|
||||
For a full list of sub-commands and usage, see the
|
||||
[`/agents` command reference](../reference/commands.md#agents).
|
||||
|
||||
### Persistent configuration (settings.json)
|
||||
|
||||
While the `/agents` command and agent definition files provide a starting point,
|
||||
you can use `settings.json` for global, persistent overrides. This is useful for
|
||||
enforcing specific models or execution limits across all sessions.
|
||||
|
||||
#### `agents.overrides`
|
||||
|
||||
Use this to enable or disable specific agents or override their run
|
||||
configurations.
|
||||
|
||||
```json
|
||||
{
|
||||
"agents": {
|
||||
"overrides": {
|
||||
"security-auditor": {
|
||||
"enabled": false,
|
||||
"runConfig": {
|
||||
"maxTurns": 20,
|
||||
"maxTimeMinutes": 10
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
#### `modelConfigs.overrides`
|
||||
|
||||
You can target specific subagents with custom model settings (like system
|
||||
instruction prefixes or specific safety settings) using the `overrideScope`
|
||||
field.
|
||||
|
||||
```json
|
||||
{
|
||||
"modelConfigs": {
|
||||
"overrides": [
|
||||
{
|
||||
"match": { "overrideScope": "security-auditor" },
|
||||
"modelConfig": {
|
||||
"generateContentConfig": {
|
||||
"temperature": 0.1
|
||||
}
|
||||
}
|
||||
}
|
||||
]
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
#### Safety policies (TOML)
|
||||
|
||||
You can restrict access to specific subagents using the CLI's **Policy Engine**.
|
||||
Subagents are treated as virtual tool names for policy matching purposes.
|
||||
|
||||
To govern access to a subagent, create a `.toml` file in your policy directory
|
||||
(e.g., `~/.gemini/policies/`):
|
||||
|
||||
```toml
|
||||
[[rule]]
|
||||
toolName = "codebase_investigator"
|
||||
decision = "deny"
|
||||
deny_message = "Deep codebase analysis is restricted for this session."
|
||||
```
|
||||
|
||||
For more information on setting up fine-grained safety guardrails, see the
|
||||
[Policy Engine reference](../reference/policy-engine.md#special-syntax-for-subagents).
|
||||
|
||||
### Optimizing your subagent
|
||||
|
||||
The main agent's system prompt encourages it to use an expert subagent when one
|
||||
is available. It decides whether an agent is a relevant expert based on the
|
||||
agent's description. You can improve the reliability with which an agent is used
|
||||
by updating the description to more clearly indicate:
|
||||
|
||||
- Its area of expertise.
|
||||
- When it should be used.
|
||||
- Some example scenarios.
|
||||
|
||||
For example, the following subagent description should be called fairly
|
||||
consistently for Git operations.
|
||||
|
||||
> Git expert agent which should be used for all local and remote git operations.
|
||||
> For example:
|
||||
>
|
||||
> - Making commits
|
||||
> - Searching for regressions with bisect
|
||||
> - Interacting with source control and issues providers such as GitHub.
|
||||
|
||||
If you need to further tune your subagent, you can do so by selecting the model
|
||||
to optimize for with `/model` and then asking the model why it does not think
|
||||
that your subagent was called with a specific prompt and the given description.
|
||||
|
||||
## Remote subagents (Agent2Agent)
|
||||
|
||||
Gemini CLI can also delegate tasks to remote subagents using the Agent-to-Agent
|
||||
(A2A) protocol.
|
||||
|
||||
See the [Remote Subagents documentation](remote-agents) for detailed
|
||||
configuration, authentication, and usage instructions.
|
||||
|
||||
## Extension subagents
|
||||
|
||||
Extensions can bundle and distribute subagents. See the
|
||||
[Extensions documentation](../extensions/index.md#subagents) for details on how
|
||||
to package agents within an extension.
|
||||
|
||||
## Disabling subagents
|
||||
|
||||
Subagents are enabled by default. To disable them, set `enableAgents` to `false`
|
||||
in your `settings.json`:
|
||||
|
||||
```json
|
||||
{
|
||||
"experimental": { "enableAgents": false }
|
||||
}
|
||||
```
|
||||
@@ -0,0 +1,83 @@
|
||||
# Example proxy script
|
||||
|
||||
The following is an example of a proxy script that can be used with the
|
||||
`GEMINI_SANDBOX_PROXY_COMMAND` environment variable. This script only allows
|
||||
`HTTPS` connections to `example.com:443` and declines all other requests.
|
||||
|
||||
```javascript
|
||||
#!/usr/bin/env node
|
||||
|
||||
/**
|
||||
* @license
|
||||
* Copyright 2025 Google LLC
|
||||
* SPDX-License-Identifier: Apache-2.0
|
||||
*/
|
||||
|
||||
// Example proxy server that listens on :::8877 and only allows HTTPS connections to example.com.
|
||||
// Set `GEMINI_SANDBOX_PROXY_COMMAND=scripts/example-proxy.js` to run proxy alongside sandbox
|
||||
// Test via `curl https://example.com` inside sandbox (in shell mode or via shell tool)
|
||||
|
||||
import http from 'node:http';
|
||||
import net from 'node:net';
|
||||
import { URL } from 'node:url';
|
||||
import console from 'node:console';
|
||||
|
||||
const PROXY_PORT = 8877;
|
||||
const ALLOWED_DOMAINS = ['example.com', 'googleapis.com'];
|
||||
const ALLOWED_PORT = '443';
|
||||
|
||||
const server = http.createServer((req, res) => {
|
||||
// Deny all requests other than CONNECT for HTTPS
|
||||
console.log(
|
||||
`[PROXY] Denying non-CONNECT request for: ${req.method} ${req.url}`,
|
||||
);
|
||||
res.writeHead(405, { 'Content-Type': 'text/plain' });
|
||||
res.end('Method Not Allowed');
|
||||
});
|
||||
|
||||
server.on('connect', (req, clientSocket, head) => {
|
||||
// req.url will be in the format "hostname:port" for a CONNECT request.
|
||||
const { port, hostname } = new URL(`http://${req.url}`);
|
||||
|
||||
console.log(`[PROXY] Intercepted CONNECT request for: ${hostname}:${port}`);
|
||||
|
||||
if (
|
||||
ALLOWED_DOMAINS.some(
|
||||
(domain) => hostname == domain || hostname.endsWith(`.${domain}`),
|
||||
) &&
|
||||
port === ALLOWED_PORT
|
||||
) {
|
||||
console.log(`[PROXY] Allowing connection to ${hostname}:${port}`);
|
||||
|
||||
// Establish a TCP connection to the original destination.
|
||||
const serverSocket = net.connect(port, hostname, () => {
|
||||
clientSocket.write('HTTP/1.1 200 Connection Established\r\n\r\n');
|
||||
// Create a tunnel by piping data between the client and the destination server.
|
||||
serverSocket.write(head);
|
||||
serverSocket.pipe(clientSocket);
|
||||
clientSocket.pipe(serverSocket);
|
||||
});
|
||||
|
||||
serverSocket.on('error', (err) => {
|
||||
console.error(`[PROXY] Error connecting to destination: ${err.message}`);
|
||||
clientSocket.end(`HTTP/1.1 502 Bad Gateway\r\n\r\n`);
|
||||
});
|
||||
} else {
|
||||
console.log(`[PROXY] Denying connection to ${hostname}:${port}`);
|
||||
clientSocket.end('HTTP/1.1 403 Forbidden\r\n\r\n');
|
||||
}
|
||||
|
||||
clientSocket.on('error', (err) => {
|
||||
// This can happen if the client hangs up.
|
||||
console.error(`[PROXY] Client socket error: ${err.message}`);
|
||||
});
|
||||
});
|
||||
|
||||
server.listen(PROXY_PORT, () => {
|
||||
const address = server.address();
|
||||
console.log(`[PROXY] Proxy listening on ${address.address}:${address.port}`);
|
||||
console.log(
|
||||
`[PROXY] Allowing HTTPS connections to domains: ${ALLOWED_DOMAINS.join(', ')}`,
|
||||
);
|
||||
});
|
||||
```
|
||||
@@ -0,0 +1,189 @@
|
||||
# Gemini CLI extension best practices
|
||||
|
||||
This guide covers best practices for developing, securing, and maintaining
|
||||
Gemini CLI extensions.
|
||||
|
||||
## Development
|
||||
|
||||
Developing extensions for Gemini CLI is a lightweight, iterative process. Use
|
||||
these strategies to build robust and efficient extensions.
|
||||
|
||||
### Structure your extension
|
||||
|
||||
While simple extensions may contain only a few files, we recommend a organized
|
||||
structure for complex projects.
|
||||
|
||||
```text
|
||||
my-extension/
|
||||
├── package.json
|
||||
├── tsconfig.json
|
||||
├── gemini-extension.json
|
||||
├── src/
|
||||
│ ├── index.ts
|
||||
│ └── tools/
|
||||
└── dist/
|
||||
```
|
||||
|
||||
- **Use TypeScript:** We strongly recommend using TypeScript for type safety and
|
||||
improved developer experience.
|
||||
- **Separate source and build:** Keep your source code in `src/` and output
|
||||
build artifacts to `dist/`.
|
||||
- **Bundle dependencies:** If your extension has many dependencies, bundle them
|
||||
using a tool like `esbuild` to reduce installation time and avoid conflicts.
|
||||
|
||||
### Iterate with `link`
|
||||
|
||||
Use the `gemini extensions link` command to develop locally without reinstalling
|
||||
your extension after every change.
|
||||
|
||||
```bash
|
||||
cd my-extension
|
||||
gemini extensions link .
|
||||
```
|
||||
|
||||
Changes to your code are immediately available in the CLI after you rebuild the
|
||||
project and restart the session.
|
||||
|
||||
### Use `GEMINI.md` effectively
|
||||
|
||||
Your `GEMINI.md` file provides essential context to the model.
|
||||
|
||||
- **Focus on goals:** Explain the high-level purpose of the extension and how to
|
||||
interact with its tools.
|
||||
- **Be concise:** Avoid dumping exhaustive documentation into the file. Use
|
||||
clear, direct language.
|
||||
- **Provide examples:** Include brief examples of how the model should use
|
||||
specific tools or commands.
|
||||
|
||||
## Security
|
||||
|
||||
Follow the principle of least privilege and rigorous input validation when
|
||||
building extensions.
|
||||
|
||||
### Minimal permissions
|
||||
|
||||
Only request the permissions your MCP server needs to function. Avoid giving the
|
||||
model broad access (such as full shell access) if restricted tools are
|
||||
sufficient.
|
||||
|
||||
If your extension uses powerful tools like `run_shell_command`, restrict them in
|
||||
your `gemini-extension.json` file:
|
||||
|
||||
```json
|
||||
{
|
||||
"name": "my-safe-extension",
|
||||
"excludeTools": ["run_shell_command(rm -rf *)"]
|
||||
}
|
||||
```
|
||||
|
||||
This ensures the CLI blocks dangerous commands even if the model attempts to
|
||||
execute them.
|
||||
|
||||
### Validate inputs
|
||||
|
||||
Your MCP server runs on the user's machine. Always validate tool inputs to
|
||||
prevent arbitrary code execution or unauthorized filesystem access.
|
||||
|
||||
```typescript
|
||||
// Example: Validating paths
|
||||
if (!path.resolve(inputPath).startsWith(path.resolve(allowedDir) + path.sep)) {
|
||||
throw new Error('Access denied');
|
||||
}
|
||||
```
|
||||
|
||||
### Secure sensitive settings
|
||||
|
||||
If your extension requires API keys or other secrets, use the `sensitive: true`
|
||||
option in your manifest. This ensures keys are stored in the system keychain and
|
||||
obfuscated in the CLI output.
|
||||
|
||||
```json
|
||||
"settings": [
|
||||
{
|
||||
"name": "API Key",
|
||||
"envVar": "MY_API_KEY",
|
||||
"sensitive": true
|
||||
}
|
||||
]
|
||||
```
|
||||
|
||||
## Release
|
||||
|
||||
Follow standard versioning and release practices to ensure a smooth experience
|
||||
for your users.
|
||||
|
||||
### Semantic versioning
|
||||
|
||||
Follow [Semantic Versioning (SemVer)](https://semver.org/) to communicate
|
||||
changes clearly.
|
||||
|
||||
- **Major:** Breaking changes (for example, renaming tools or changing
|
||||
arguments).
|
||||
- **Minor:** New features (for example, adding new tools or commands).
|
||||
- **Patch:** Bug fixes and performance improvements.
|
||||
|
||||
### Release channels
|
||||
|
||||
Use Git branches to manage release channels. This lets users choose between
|
||||
stability and the latest features.
|
||||
|
||||
```bash
|
||||
# Install the stable version (default branch)
|
||||
gemini extensions install github.com/user/repo
|
||||
|
||||
# Install the development version
|
||||
gemini extensions install github.com/user/repo --ref dev
|
||||
```
|
||||
|
||||
### Clean artifacts
|
||||
|
||||
When using GitHub Releases, ensure your archives only contain necessary files
|
||||
(such as `dist/`, `gemini-extension.json`, and `package.json`). Exclude
|
||||
`node_modules/` and `src/` to minimize download size.
|
||||
|
||||
## Test and verify
|
||||
|
||||
Test your extension thoroughly before releasing it to users.
|
||||
|
||||
- **Manual verification:** Use `gemini extensions link` to test your extension
|
||||
in a live CLI session. Verify that tools appear in the debug console (F12) and
|
||||
that custom commands resolve correctly.
|
||||
- **Automated testing:** If your extension includes an MCP server, write unit
|
||||
tests for your tool logic using a framework like Vitest or Jest. You can test
|
||||
MCP tools in isolation by mocking the transport layer.
|
||||
|
||||
## Troubleshooting
|
||||
|
||||
Use these tips to diagnose and fix common extension issues.
|
||||
|
||||
### Extension not loading
|
||||
|
||||
If your extension doesn't appear in `/extensions list`:
|
||||
|
||||
- **Check the manifest:** Ensure `gemini-extension.json` is in the root
|
||||
directory and contains valid JSON.
|
||||
- **Verify the name:** The `name` field in the manifest must match the extension
|
||||
directory name exactly.
|
||||
- **Restart the CLI:** Extensions are loaded at the start of a session. Restart
|
||||
Gemini CLI after making changes to the manifest or linking a new extension.
|
||||
|
||||
### MCP server failures
|
||||
|
||||
If your tools aren't working as expected:
|
||||
|
||||
- **Check the logs:** View the CLI logs to see if the MCP server failed to
|
||||
start.
|
||||
- **Test the command:** Run the server's `command` and `args` directly in your
|
||||
terminal to ensure it starts correctly outside of Gemini CLI.
|
||||
- **Debug console:** In interactive mode, press **F12** to open the debug
|
||||
console and inspect tool calls and responses.
|
||||
|
||||
### Command conflicts
|
||||
|
||||
If a custom command isn't responding:
|
||||
|
||||
- **Check precedence:** Remember that user and project commands take precedence
|
||||
over extension commands. Use the prefixed name (for example,
|
||||
`/extension.command`) to verify the extension's version.
|
||||
- **Help command:** Run `/help` to see a list of all available commands and
|
||||
their sources.
|
||||
@@ -0,0 +1,61 @@
|
||||
# Gemini CLI extensions
|
||||
|
||||
Gemini CLI extensions package prompts, MCP servers, custom commands, themes,
|
||||
hooks, sub-agents, and agent skills into a familiar and user-friendly format.
|
||||
With extensions, you can expand the capabilities of Gemini CLI and share those
|
||||
capabilities with others. They are designed to be easily installable and
|
||||
shareable.
|
||||
|
||||
To see what's possible, browse the
|
||||
[Gemini CLI extension gallery](https://geminicli.com/extensions/browse/).
|
||||
|
||||
## Choose your path
|
||||
|
||||
Choose the guide that best fits your needs.
|
||||
|
||||
### I want to use extensions
|
||||
|
||||
Learn how to discover, install, and manage extensions to enhance your Gemini CLI
|
||||
experience.
|
||||
|
||||
- **[Manage extensions](#manage-extensions):** List and verify your installed
|
||||
extensions.
|
||||
- **[Install extensions](#installation):** Add new capabilities from GitHub or
|
||||
local paths.
|
||||
|
||||
### I want to build extensions
|
||||
|
||||
Learn how to create, test, and share your own extensions with the community.
|
||||
|
||||
- **[Build extensions](writing-extensions.md):** Create your first extension
|
||||
from a template.
|
||||
- **[Best practices](best-practices.md):** Learn how to build secure and
|
||||
reliable extensions.
|
||||
- **[Publish to the gallery](releasing.md):** Share your work with the world.
|
||||
|
||||
## Manage extensions
|
||||
|
||||
Use the interactive `/extensions` command to verify your installed extensions
|
||||
and their status:
|
||||
|
||||
```bash
|
||||
/extensions list
|
||||
```
|
||||
|
||||
You can also manage extensions from your terminal using the `gemini extensions`
|
||||
command group:
|
||||
|
||||
```bash
|
||||
gemini extensions list
|
||||
```
|
||||
|
||||
## Installation
|
||||
|
||||
Install an extension by providing its GitHub repository URL. For example:
|
||||
|
||||
```bash
|
||||
gemini extensions install https://github.com/gemini-cli-extensions/workspace
|
||||
```
|
||||
|
||||
For more advanced installation options, see the
|
||||
[Extension reference](reference.md#install-an-extension).
|
||||
@@ -0,0 +1,361 @@
|
||||
# Extension reference
|
||||
|
||||
This guide covers the `gemini extensions` commands and the structure of the
|
||||
`gemini-extension.json` configuration file.
|
||||
|
||||
## Manage extensions
|
||||
|
||||
Use the `gemini extensions` command group to manage your extensions from the
|
||||
terminal.
|
||||
|
||||
Note that commands like `gemini extensions install` are not supported within the
|
||||
CLI's interactive mode. However, you can use the `/extensions list` command to
|
||||
view installed extensions. All management operations, including updates to slash
|
||||
commands, take effect only after you restart the CLI session.
|
||||
|
||||
### Install an extension
|
||||
|
||||
Install an extension by providing its GitHub repository URL or a local file
|
||||
path.
|
||||
|
||||
Gemini CLI creates a copy of the extension during installation. You must run
|
||||
`gemini extensions update` to pull changes from the source. To install from
|
||||
GitHub, you must have `git` installed on your machine.
|
||||
|
||||
```bash
|
||||
gemini extensions install <source> [--ref <ref>] [--auto-update] [--pre-release] [--consent] [--skip-settings]
|
||||
```
|
||||
|
||||
- `<source>`: The GitHub URL or local path of the extension.
|
||||
- `--ref`: The git ref (branch, tag, or commit) to install.
|
||||
- `--auto-update`: Enable automatic updates for this extension.
|
||||
- `--pre-release`: Enable installation of pre-release versions.
|
||||
- `--consent`: Acknowledge security risks and skip the confirmation prompt.
|
||||
- `--skip-settings`: Skip the configuration on install process.
|
||||
|
||||
### Uninstall an extension
|
||||
|
||||
To uninstall one or more extensions, use the `uninstall` command:
|
||||
|
||||
```bash
|
||||
gemini extensions uninstall <name...>
|
||||
```
|
||||
|
||||
### Disable an extension
|
||||
|
||||
Extensions are enabled globally by default. You can disable an extension
|
||||
entirely or for a specific workspace.
|
||||
|
||||
```bash
|
||||
gemini extensions disable <name> [--scope <scope>]
|
||||
```
|
||||
|
||||
- `<name>`: The name of the extension to disable.
|
||||
- `--scope`: The scope to disable the extension in (`user` or `workspace`).
|
||||
|
||||
### Enable an extension
|
||||
|
||||
Re-enable a disabled extension using the `enable` command:
|
||||
|
||||
```bash
|
||||
gemini extensions enable <name> [--scope <scope>]
|
||||
```
|
||||
|
||||
- `<name>`: The name of the extension to enable.
|
||||
- `--scope`: The scope to enable the extension in (`user` or `workspace`).
|
||||
|
||||
### Update an extension
|
||||
|
||||
Update an extension to the version specified in its `gemini-extension.json`
|
||||
file.
|
||||
|
||||
```bash
|
||||
gemini extensions update <name>
|
||||
```
|
||||
|
||||
To update all installed extensions at once:
|
||||
|
||||
```bash
|
||||
gemini extensions update --all
|
||||
```
|
||||
|
||||
### Create an extension from a template
|
||||
|
||||
Create a new extension directory using a built-in template.
|
||||
|
||||
```bash
|
||||
gemini extensions new <path> [template]
|
||||
```
|
||||
|
||||
- `<path>`: The directory to create.
|
||||
- `[template]`: The template to use (for example, `mcp-server`, `context`,
|
||||
`custom-commands`).
|
||||
|
||||
### Link a local extension
|
||||
|
||||
Create a symbolic link between your development directory and Gemini CLI
|
||||
extensions directory. This lets you test changes immediately without
|
||||
reinstalling.
|
||||
|
||||
```bash
|
||||
gemini extensions link <path>
|
||||
```
|
||||
|
||||
## Extension format
|
||||
|
||||
Gemini CLI loads extensions from `<home>/.gemini/extensions`. Each extension
|
||||
must have a `gemini-extension.json` file in its root directory.
|
||||
|
||||
### `gemini-extension.json`
|
||||
|
||||
The manifest file defines the extension's behavior and configuration.
|
||||
|
||||
```json
|
||||
{
|
||||
"name": "my-extension",
|
||||
"version": "1.0.0",
|
||||
"description": "My awesome extension",
|
||||
"mcpServers": {
|
||||
"my-server": {
|
||||
"command": "node",
|
||||
"args": ["${extensionPath}/my-server.js"],
|
||||
"cwd": "${extensionPath}"
|
||||
}
|
||||
},
|
||||
"contextFileName": "GEMINI.md",
|
||||
"excludeTools": ["run_shell_command"],
|
||||
"migratedTo": "https://github.com/new-owner/new-extension-repo",
|
||||
"plan": {
|
||||
"directory": ".gemini/plans"
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
- `name`: The name of the extension. This is used to uniquely identify the
|
||||
extension and for conflict resolution when extension commands have the same
|
||||
name as user or project commands. The name should be lowercase or numbers and
|
||||
use dashes instead of underscores or spaces. This is how users will refer to
|
||||
your extension in the CLI. Note that we expect this name to match the
|
||||
extension directory name.
|
||||
- `version`: The version of the extension.
|
||||
- `description`: A short description of the extension. This will be displayed on
|
||||
[geminicli.com/extensions](https://geminicli.com/extensions).
|
||||
- `migratedTo`: The URL of the new repository source for the extension. If this
|
||||
is set, the CLI will automatically check this new source for updates and
|
||||
migrate the extension's installation to the new source if an update is found.
|
||||
- `mcpServers`: A map of MCP servers to settings. The key is the name of the
|
||||
server, and the value is the server configuration. These servers will be
|
||||
loaded on startup just like MCP servers defined in a
|
||||
[`settings.json` file](../reference/configuration.md). If both an extension
|
||||
and a `settings.json` file define an MCP server with the same name, the server
|
||||
defined in the `settings.json` file takes precedence.
|
||||
- Note that all MCP server configuration options are supported except for
|
||||
`trust`.
|
||||
- For portability, you should use `${extensionPath}` to refer to files within
|
||||
your extension directory.
|
||||
- Separate your executable and its arguments using `command` and `args`
|
||||
instead of putting them both in `command`.
|
||||
- `contextFileName`: The name of the file that contains the context for the
|
||||
extension. This will be used to load the context from the extension directory.
|
||||
If this property is not used but a `GEMINI.md` file is present in your
|
||||
extension directory, then that file will be loaded.
|
||||
- `excludeTools`: An array of tool names to exclude from the model. You can also
|
||||
specify command-specific restrictions for tools that support it, like the
|
||||
`run_shell_command` tool. For example,
|
||||
`"excludeTools": ["run_shell_command(rm -rf)"]` will block the `rm -rf`
|
||||
command. Note that this differs from the MCP server `excludeTools`
|
||||
functionality, which can be listed in the MCP server config.
|
||||
- `plan`: Planning features configuration.
|
||||
- `directory`: The directory where planning artifacts are stored. This serves
|
||||
as a fallback if the user hasn't specified a plan directory in their
|
||||
settings. If not specified by either the extension or the user, the default
|
||||
is `~/.gemini/tmp/<project>/<session-id>/plans/`.
|
||||
|
||||
When Gemini CLI starts, it loads all the extensions and merges their
|
||||
configurations. If there are any conflicts, the workspace configuration takes
|
||||
precedence.
|
||||
|
||||
### Extension settings
|
||||
|
||||
Extensions can define settings that users provide during installation, such as
|
||||
API keys or URLs. These values are stored in a `.env` file within the extension
|
||||
directory.
|
||||
|
||||
To define settings, add a `settings` array to your manifest:
|
||||
|
||||
```json
|
||||
{
|
||||
"name": "my-api-extension",
|
||||
"version": "1.0.0",
|
||||
"settings": [
|
||||
{
|
||||
"name": "API Key",
|
||||
"description": "Your API key for the service.",
|
||||
"envVar": "MY_API_KEY",
|
||||
"sensitive": true
|
||||
}
|
||||
]
|
||||
}
|
||||
```
|
||||
|
||||
- `name`: The setting's display name.
|
||||
- `description`: A clear explanation of the setting.
|
||||
- `envVar`: The environment variable name where the value is stored.
|
||||
- `sensitive`: If `true`, the value is stored in the system keychain and
|
||||
obfuscated in the UI.
|
||||
|
||||
To update an extension's settings:
|
||||
|
||||
```bash
|
||||
gemini extensions config <name> [setting] [--scope <scope>]
|
||||
```
|
||||
|
||||
#### Environment variable sanitization
|
||||
|
||||
For security reasons, sensitive environment variables are filtered out and not
|
||||
passed to extensions or MCP servers by default.
|
||||
|
||||
Extensions **will not** inherit the user's full shell environment variables.
|
||||
They will only have access to:
|
||||
|
||||
1. Standard safe variables (e.g., `HOME`, `PATH`, `TMPDIR`).
|
||||
2. Variables explicitly declared and requested in the `gemini-extension.json`
|
||||
manifest via the `settings` array (using the `envVar` property).
|
||||
|
||||
If your extension requires specific environment variables (like an API key,
|
||||
custom host, or config path), you **must** declare them in the `settings` array
|
||||
so the CLI can allowlist them for use within the extension.
|
||||
|
||||
### Custom commands
|
||||
|
||||
Provide [custom commands](../cli/custom-commands.md) by placing TOML files in a
|
||||
`commands/` subdirectory. Gemini CLI uses the directory structure to determine
|
||||
the command name.
|
||||
|
||||
For an extension named `gcp`:
|
||||
|
||||
- `commands/deploy.toml` becomes `/deploy`
|
||||
- `commands/gcs/sync.toml` becomes `/gcs:sync` (namespaced with a colon)
|
||||
|
||||
### Hooks
|
||||
|
||||
Intercept and customize CLI behavior using [hooks](../hooks/index.md). Define
|
||||
hooks in a `hooks/hooks.json` file within your extension directory. Note that
|
||||
hooks are not defined in the `gemini-extension.json` manifest.
|
||||
|
||||
### Agent skills
|
||||
|
||||
Bundle [agent skills](../cli/skills.md) to provide specialized workflows. Place
|
||||
skill definitions in a `skills/` directory. For example,
|
||||
`skills/security-audit/SKILL.md` exposes a `security-audit` skill.
|
||||
|
||||
### Sub-agents
|
||||
|
||||
<!-- prettier-ignore -->
|
||||
> [!NOTE]
|
||||
> Sub-agents are a preview feature currently under active development.
|
||||
|
||||
Provide [sub-agents](../core/subagents.md) that users can delegate tasks to. Add
|
||||
agent definition files (`.md`) to an `agents/` directory in your extension root.
|
||||
|
||||
### <a id="policy-engine"></a>Policy Engine
|
||||
|
||||
Extensions can contribute policy rules and safety checkers to Gemini CLI
|
||||
[Policy Engine](../reference/policy-engine.md). These rules are defined in
|
||||
`.toml` files and take effect when the extension is activated.
|
||||
|
||||
To add policies, create a `policies/` directory in your extension's root and
|
||||
place your `.toml` policy files inside it. Gemini CLI automatically loads all
|
||||
`.toml` files from this directory.
|
||||
|
||||
Rules contributed by extensions run in their own tier (tier 2), alongside
|
||||
workspace-defined policies. This tier has higher priority than the default rules
|
||||
but lower priority than user or admin policies.
|
||||
|
||||
<!-- prettier-ignore -->
|
||||
> [!WARNING]
|
||||
> For security, Gemini CLI ignores any `allow` decisions or `yolo`
|
||||
> mode configurations in extension policies. This ensures that an extension
|
||||
> cannot automatically approve tool calls or bypass security measures without
|
||||
> your confirmation.
|
||||
|
||||
**Example `policies.toml`**
|
||||
|
||||
```toml
|
||||
[[rule]]
|
||||
mcpName = "my_server"
|
||||
toolName = "dangerous_tool"
|
||||
decision = "ask_user"
|
||||
priority = 100
|
||||
|
||||
[[safety_checker]]
|
||||
mcpName = "my_server"
|
||||
toolName = "write_data"
|
||||
priority = 200
|
||||
[safety_checker.checker]
|
||||
type = "in-process"
|
||||
name = "allowed-path"
|
||||
required_context = ["environment"]
|
||||
```
|
||||
|
||||
### Themes
|
||||
|
||||
Extensions can provide custom themes to personalize the CLI UI. Themes are
|
||||
defined in the `themes` array in `gemini-extension.json`.
|
||||
|
||||
**Example**
|
||||
|
||||
```json
|
||||
{
|
||||
"name": "my-green-extension",
|
||||
"version": "1.0.0",
|
||||
"themes": [
|
||||
{
|
||||
"name": "shades-of-green",
|
||||
"type": "custom",
|
||||
"background": {
|
||||
"primary": "#1a362a"
|
||||
},
|
||||
"text": {
|
||||
"primary": "#a6e3a1",
|
||||
"secondary": "#6e8e7a",
|
||||
"link": "#89e689"
|
||||
},
|
||||
"status": {
|
||||
"success": "#76c076",
|
||||
"warning": "#d9e689",
|
||||
"error": "#b34e4e"
|
||||
},
|
||||
"border": {
|
||||
"default": "#4a6c5a"
|
||||
},
|
||||
"ui": {
|
||||
"comment": "#6e8e7a"
|
||||
}
|
||||
}
|
||||
]
|
||||
}
|
||||
```
|
||||
|
||||
Custom themes provided by extensions can be selected using the `/theme` command
|
||||
or by setting the `ui.theme` property in your `settings.json` file. Note that
|
||||
when referring to a theme from an extension, the extension name is appended to
|
||||
the theme name in parentheses, for example,
|
||||
`shades-of-green (my-green-extension)`.
|
||||
|
||||
### Conflict resolution
|
||||
|
||||
Extension commands have the lowest precedence. If an extension command name
|
||||
conflicts with a user or project command, the extension command is prefixed with
|
||||
the extension name (for example, `/gcp.deploy`) using a dot separator.
|
||||
|
||||
## Variables
|
||||
|
||||
Gemini CLI supports variable substitution in `gemini-extension.json` and
|
||||
`hooks/hooks.json`.
|
||||
|
||||
| Variable | Description |
|
||||
| :----------------- | :---------------------------------------------- |
|
||||
| `${extensionPath}` | The absolute path to the extension's directory. |
|
||||
| `${workspacePath}` | The absolute path to the current workspace. |
|
||||
| `${/}` | The platform-specific path separator. |
|
||||
@@ -0,0 +1,215 @@
|
||||
# Release extensions
|
||||
|
||||
Release Gemini CLI extensions to your users through a Git repository or GitHub
|
||||
Releases. This guide explains how to share your work, list it in the gallery,
|
||||
and manage updates.
|
||||
|
||||
Git repository releases are the simplest approach and offer the most flexibility
|
||||
for managing development branches. GitHub Releases are more efficient for
|
||||
initial installations because they ship as single archives rather than requiring
|
||||
a full `git clone`. Use GitHub Releases if you need to include platform-specific
|
||||
binary files.
|
||||
|
||||
## List your extension in the gallery
|
||||
|
||||
The [Gemini CLI extension gallery](https://geminicli.com/extensions/browse/)
|
||||
automatically indexes public extensions to help users discover your work. You
|
||||
don't need to submit an issue or email us to list your extension.
|
||||
|
||||
To have your extension automatically discovered and listed:
|
||||
|
||||
1. **Use a public repository:** Ensure your extension is hosted in a public
|
||||
GitHub repository.
|
||||
2. **Add the GitHub topic:** Add the `gemini-cli-extension` topic to your
|
||||
repository's **About** section. Our crawler uses this topic to find new
|
||||
extensions.
|
||||
3. **Place the manifest at the root:** Ensure your `gemini-extension.json` file
|
||||
is in the absolute root of the repository or the release archive.
|
||||
|
||||
Our system crawls tagged repositories daily. Once you tag your repository, your
|
||||
extension will appear in the gallery if it passes validation.
|
||||
|
||||
## Release through a Git repository
|
||||
|
||||
Releasing through Git is the most flexible option. Create a public Git
|
||||
repository and provide the URL to your users. They can then install your
|
||||
extension using `gemini extensions install <your-repo-uri>`.
|
||||
|
||||
Users can optionally depend on a specific branch, tag, or commit using the
|
||||
`--ref` argument. For example:
|
||||
|
||||
```bash
|
||||
gemini extensions install <your-repo-uri> --ref=stable
|
||||
```
|
||||
|
||||
Whenever you push commits to the referenced branch, the CLI prompts users to
|
||||
update their installation. The `HEAD` commit is always treated as the latest
|
||||
version.
|
||||
|
||||
### Manage release channels
|
||||
|
||||
You can use branches or tags to manage different release channels, such as
|
||||
`stable`, `preview`, or `dev`.
|
||||
|
||||
We recommend using your default branch as the stable release channel. This
|
||||
ensures that the default installation command always provides the most reliable
|
||||
version of your extension. You can then use a `dev` branch for active
|
||||
development and merge it into the default branch when you are ready for a
|
||||
release.
|
||||
|
||||
## Release through GitHub Releases
|
||||
|
||||
Distributing extensions through
|
||||
[GitHub Releases](https://docs.github.com/en/repositories/releasing-projects-on-github/about-releases)
|
||||
provides a faster installation experience by avoiding a repository clone.
|
||||
|
||||
Gemini CLI checks for updates by looking for the **Latest** release on GitHub.
|
||||
Users can also install specific versions using the `--ref` argument with a
|
||||
release tag. Use the `--pre-release` flag to install the latest version even if
|
||||
it isn't marked as **Latest**.
|
||||
|
||||
### Custom pre-built archives
|
||||
|
||||
You can attach custom archives directly to your GitHub Release as assets. This
|
||||
is useful if your extension requires a build step or includes platform-specific
|
||||
binaries.
|
||||
|
||||
Custom archives must be fully self-contained and follow the required
|
||||
[archive structure](#archive-structure). If your extension is
|
||||
platform-independent, provide a single generic asset.
|
||||
|
||||
#### Platform-specific archives
|
||||
|
||||
To let Gemini CLI find the correct asset for a user's platform, use the
|
||||
following naming convention:
|
||||
|
||||
1. **Platform and architecture-specific:**
|
||||
`{platform}.{arch}.{name}.{extension}`
|
||||
2. **Platform-specific:** `{platform}.{name}.{extension}`
|
||||
3. **Generic:** A single asset will be used as a fallback if no specific match
|
||||
is found.
|
||||
|
||||
Use these values for the placeholders:
|
||||
|
||||
- `{name}`: Your extension name.
|
||||
- `{platform}`: Use `darwin` (macOS), `linux`, or `win32` (Windows).
|
||||
- `{arch}`: Use `x64` or `arm64`.
|
||||
- `{extension}`: Use `.tar.gz` or `.zip`.
|
||||
|
||||
**Examples:**
|
||||
|
||||
- `darwin.arm64.my-tool.tar.gz` (specific to Apple Silicon Macs)
|
||||
- `darwin.my-tool.tar.gz` (fallback for all Macs, for example Intel)
|
||||
- `linux.x64.my-tool.tar.gz`
|
||||
- `win32.my-tool.zip`
|
||||
|
||||
#### Archive structure
|
||||
|
||||
Archives must be fully contained extensions. The `gemini-extension.json` file
|
||||
must be at the root of the archive. The rest of the layout should match a
|
||||
standard extension structure.
|
||||
|
||||
#### Example GitHub Actions workflow
|
||||
|
||||
Use this example workflow to build and release your extension for multiple
|
||||
platforms:
|
||||
|
||||
```yaml
|
||||
name: Release Extension
|
||||
|
||||
on:
|
||||
push:
|
||||
tags:
|
||||
- 'v*'
|
||||
|
||||
jobs:
|
||||
release:
|
||||
runs-on: ubuntu-latest
|
||||
steps:
|
||||
- uses: actions/checkout@v3
|
||||
|
||||
- name: Set up Node.js
|
||||
uses: actions/setup-node@v3
|
||||
with:
|
||||
node-version: '20'
|
||||
|
||||
- name: Install dependencies
|
||||
run: npm ci
|
||||
|
||||
- name: Build extension
|
||||
run: npm run build
|
||||
|
||||
- name: Create release assets
|
||||
run: |
|
||||
npm run package -- --platform=darwin --arch=arm64
|
||||
npm run package -- --platform=linux --arch=x64
|
||||
npm run package -- --platform=win32 --arch=x64
|
||||
|
||||
- name: Create GitHub Release
|
||||
uses: softprops/action-gh-release@v1
|
||||
with:
|
||||
files: |
|
||||
release/darwin.arm64.my-tool.tar.gz
|
||||
release/linux.arm64.my-tool.tar.gz
|
||||
release/win32.arm64.my-tool.zip
|
||||
```
|
||||
|
||||
## Migrate an extension repository
|
||||
|
||||
If you move your extension to a new repository or rename it, use the
|
||||
`migratedTo` property in `gemini-extension.json` to seamlessly transition your
|
||||
users.
|
||||
|
||||
1. **Create the new repository:** Set up your extension in its new location.
|
||||
2. **Update the old repository:** In your original repository, update the
|
||||
`gemini-extension.json` file to include the `migratedTo` property pointing
|
||||
to the new repository URL, and increment the version number.
|
||||
```json
|
||||
{
|
||||
"name": "my-extension",
|
||||
"version": "1.1.0",
|
||||
"migratedTo": "https://github.com/new-owner/new-extension-repo"
|
||||
}
|
||||
```
|
||||
3. **Release the update:** Publish this new version in your old repository.
|
||||
|
||||
When users check for updates, Gemini CLI detects the `migratedTo` field,
|
||||
verifies the new repository, and automatically updates their local installation
|
||||
to track the new source. All settings migrate automatically.
|
||||
|
||||
## How updates work
|
||||
|
||||
Gemini CLI automatically checks for extension updates based on the installation
|
||||
method. Understanding these mechanisms helps you ensure your users always have
|
||||
the latest version.
|
||||
|
||||
### Sync manifest and tags
|
||||
|
||||
For GitHub releases, always ensure the `version` in `gemini-extension.json`
|
||||
matches your GitHub release tag. While the CLI uses tags for update detection,
|
||||
it displays the manifest version in the UI. Keeping them in sync prevents
|
||||
confusion.
|
||||
|
||||
### Update mechanisms
|
||||
|
||||
<details>
|
||||
<summary>Technical update details</summary>
|
||||
|
||||
The CLI uses different strategies depending on the installation type:
|
||||
|
||||
- **GitHub releases:** The CLI queries the GitHub API for the latest release
|
||||
tag. It ignores the `version` field in the manifest for detection.
|
||||
- **Git clones:** The CLI runs `git ls-remote` to compare the latest remote
|
||||
commit hash with your local `HEAD`.
|
||||
- **Local extensions:** The CLI compares the `version` field in the source
|
||||
directory's manifest with the installed version.
|
||||
|
||||
To verify an extension's installation type, inspect the `type` field in the
|
||||
metadata file at `~/.gemini/extensions/<name>/.gemini-extension-install.json`.
|
||||
|
||||
</details>
|
||||
|
||||
<!-- prettier-ignore -->
|
||||
> [!IMPORTANT]
|
||||
> The `migratedTo` flow requires at least one release on the new repository for
|
||||
> the CLI to recognize it as a valid update source.
|
||||
@@ -0,0 +1,315 @@
|
||||
# Build Gemini CLI extensions
|
||||
|
||||
Gemini CLI extensions let you expand the capabilities of Gemini CLI by adding
|
||||
custom tools, commands, and context. This guide walks you through creating your
|
||||
first extension, from setting up a template to adding custom functionality and
|
||||
linking it for local development.
|
||||
|
||||
## Prerequisites
|
||||
|
||||
Before you start, ensure you have Gemini CLI installed and a basic understanding
|
||||
of Node.js.
|
||||
|
||||
## Extension features
|
||||
|
||||
Extensions offer several ways to customize Gemini CLI. Use this table to decide
|
||||
which features your extension needs.
|
||||
|
||||
| Feature | What it is | When to use it | Invoked by |
|
||||
| :------------------------------------------------------------- | :------------------------------------------------------------------------------------------------------------------------ | :--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | :-------------------- |
|
||||
| **[MCP server](reference.md#mcp-servers)** | A standard way to expose new tools and data sources to the model. | Use this when you want the model to be able to _do_ new things, like fetching data from an internal API, querying a database, or controlling a local application. We also support MCP resources (which can replace custom commands) and system instructions (which can replace custom context) | Model |
|
||||
| **[Custom commands](../cli/custom-commands.md)** | A shortcut (like `/my-cmd`) that executes a pre-defined prompt or shell command. | Use this for repetitive tasks or to save long, complex prompts that you use frequently. Great for automation. | User |
|
||||
| **[Context file (`GEMINI.md`)](reference.md#contextfilename)** | A markdown file containing instructions that are loaded into the model's context at the start of every session. | Use this to define the "personality" of your extension, set coding standards, or provide essential knowledge that the model should always have. | CLI provides to model |
|
||||
| **[Agent skills](../cli/skills.md)** | A specialized set of instructions and workflows that the model activates only when needed. | Use this for complex, occasional tasks (like "create a PR" or "audit security") to avoid cluttering the main context window when the skill isn't being used. | Model |
|
||||
| **[Hooks](../hooks/index.md)** | A way to intercept and customize the CLI's behavior at specific lifecycle events (for example, before/after a tool call). | Use this when you want to automate actions based on what the model is doing, like validating tool arguments, logging activity, or modifying the model's input/output. | CLI |
|
||||
| **[Custom themes](reference.md#themes)** | A set of color definitions to personalize the CLI UI. | Use this to provide a unique visual identity for your extension or to offer specialized high-contrast or thematic color schemes. | User (via /theme) |
|
||||
|
||||
## Step 1: Create a new extension
|
||||
|
||||
The easiest way to start is by using a built-in template. We'll use the
|
||||
`mcp-server` example as our foundation.
|
||||
|
||||
Run the following command to create a new directory called `my-first-extension`
|
||||
with the template files:
|
||||
|
||||
```bash
|
||||
gemini extensions new my-first-extension mcp-server
|
||||
```
|
||||
|
||||
This creates a directory with the following structure:
|
||||
|
||||
```
|
||||
my-first-extension/
|
||||
├── example.js
|
||||
├── gemini-extension.json
|
||||
└── package.json
|
||||
```
|
||||
|
||||
## Step 2: Understand the extension files
|
||||
|
||||
Your new extension contains several key files that define its behavior.
|
||||
|
||||
### `gemini-extension.json`
|
||||
|
||||
The manifest file tells Gemini CLI how to load and use your extension.
|
||||
|
||||
```json
|
||||
{
|
||||
"name": "mcp-server-example",
|
||||
"version": "1.0.0",
|
||||
"mcpServers": {
|
||||
"nodeServer": {
|
||||
"command": "node",
|
||||
"args": ["${extensionPath}${/}example.js"],
|
||||
"cwd": "${extensionPath}"
|
||||
}
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
- `name`: The unique name for your extension.
|
||||
- `version`: The version of your extension.
|
||||
- `mcpServers`: Defines Model Context Protocol (MCP) servers to add new tools.
|
||||
- `command`, `args`, `cwd`: Specify how to start your server. The
|
||||
`${extensionPath}` variable is replaced with the absolute path to your
|
||||
extension's directory.
|
||||
|
||||
### `example.js`
|
||||
|
||||
This file contains the source code for your MCP server. It uses the
|
||||
`@modelcontextprotocol/sdk` to define tools.
|
||||
|
||||
```javascript
|
||||
/**
|
||||
* @license
|
||||
* Copyright 2025 Google LLC
|
||||
* SPDX-License-Identifier: Apache-2.0
|
||||
*/
|
||||
|
||||
import { McpServer } from '@modelcontextprotocol/sdk/server/mcp.js';
|
||||
import { StdioServerTransport } from '@modelcontextprotocol/sdk/server/stdio.js';
|
||||
import { z } from 'zod';
|
||||
|
||||
const server = new McpServer({
|
||||
name: 'prompt-server',
|
||||
version: '1.0.0',
|
||||
});
|
||||
|
||||
// Registers a new tool named 'fetch_posts'
|
||||
server.registerTool(
|
||||
'fetch_posts',
|
||||
{
|
||||
description: 'Fetches a list of posts from a public API.',
|
||||
inputSchema: z.object({}).shape,
|
||||
},
|
||||
async () => {
|
||||
const apiResponse = await fetch(
|
||||
'https://jsonplaceholder.typicode.com/posts',
|
||||
);
|
||||
const posts = await apiResponse.json();
|
||||
const response = { posts: posts.slice(0, 5) };
|
||||
return {
|
||||
content: [
|
||||
{
|
||||
type: 'text',
|
||||
text: JSON.stringify(response),
|
||||
},
|
||||
],
|
||||
};
|
||||
},
|
||||
);
|
||||
|
||||
const transport = new StdioServerTransport();
|
||||
await server.connect(transport);
|
||||
```
|
||||
|
||||
### `package.json`
|
||||
|
||||
The standard configuration file for a Node.js project. It defines dependencies
|
||||
and scripts for your extension.
|
||||
|
||||
## Step 3: Add extension settings
|
||||
|
||||
Some extensions need configuration, such as API keys or user preferences. Let's
|
||||
add a setting for an API key.
|
||||
|
||||
1. Open `gemini-extension.json`.
|
||||
2. Add a `settings` array to the configuration:
|
||||
|
||||
```json
|
||||
{
|
||||
"name": "mcp-server-example",
|
||||
"version": "1.0.0",
|
||||
"settings": [
|
||||
{
|
||||
"name": "API Key",
|
||||
"description": "The API key for the service.",
|
||||
"envVar": "MY_SERVICE_API_KEY",
|
||||
"sensitive": true
|
||||
}
|
||||
],
|
||||
"mcpServers": {
|
||||
// ...
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
When a user installs this extension, Gemini CLI will prompt them to enter the
|
||||
"API Key". The value will be stored securely in the system keychain (because
|
||||
`sensitive` is true) and injected into the MCP server's process as the
|
||||
`MY_SERVICE_API_KEY` environment variable.
|
||||
|
||||
> **Important (Environment Variable Sanitization):** For security reasons,
|
||||
> sensitive environment variables are filtered out and not passed to extensions
|
||||
> or MCP servers by default. Extensions will _only_ have access to environment
|
||||
> variables that are explicitly declared in the `settings` array using the
|
||||
> `envVar` property, plus a few standard safe variables. Do not expect host
|
||||
> environment variables to be available otherwise.
|
||||
|
||||
## Step 4: Link your extension
|
||||
|
||||
Link your extension to your Gemini CLI installation for local development.
|
||||
|
||||
1. **Install dependencies:**
|
||||
|
||||
```bash
|
||||
cd my-first-extension
|
||||
npm install
|
||||
```
|
||||
|
||||
2. **Link the extension:**
|
||||
|
||||
The `link` command creates a symbolic link from Gemini CLI extensions
|
||||
directory to your development directory. Changes you make are reflected
|
||||
immediately.
|
||||
|
||||
```bash
|
||||
gemini extensions link .
|
||||
```
|
||||
|
||||
Restart your Gemini CLI session to use the new `fetch_posts` tool. Test it by
|
||||
asking: "fetch posts".
|
||||
|
||||
## Step 5: Add a custom command
|
||||
|
||||
Custom commands create shortcuts for complex prompts.
|
||||
|
||||
1. Create a `commands` directory and a subdirectory for your command group:
|
||||
|
||||
**macOS/Linux**
|
||||
|
||||
```bash
|
||||
mkdir -p commands/fs
|
||||
```
|
||||
|
||||
**Windows (PowerShell)**
|
||||
|
||||
```powershell
|
||||
New-Item -ItemType Directory -Force -Path "commands\fs"
|
||||
```
|
||||
|
||||
2. Create a file named `commands/fs/grep-code.toml`:
|
||||
|
||||
```toml
|
||||
prompt = """
|
||||
Please summarize the findings for the pattern `{{args}}`.
|
||||
|
||||
Search Results:
|
||||
!{grep -r {{args}} .}
|
||||
"""
|
||||
```
|
||||
|
||||
This command, `/fs:grep-code`, takes an argument, runs the `grep` shell
|
||||
command, and pipes the results into a prompt for summarization.
|
||||
|
||||
After saving the file, restart Gemini CLI. Run `/fs:grep-code "some pattern"` to
|
||||
use your new command.
|
||||
|
||||
## Step 6: Add a custom `GEMINI.md`
|
||||
|
||||
Provide persistent context to the model by adding a `GEMINI.md` file to your
|
||||
extension. This is useful for setting behavior or providing essential tool
|
||||
information.
|
||||
|
||||
1. Create a file named `GEMINI.md` in the root of your extension directory:
|
||||
|
||||
```markdown
|
||||
# My First Extension Instructions
|
||||
|
||||
You are an expert developer assistant. When the user asks you to fetch
|
||||
posts, use the `fetch_posts` tool. Be concise in your responses.
|
||||
```
|
||||
|
||||
2. Update your `gemini-extension.json` to load this file:
|
||||
|
||||
```json
|
||||
{
|
||||
"name": "my-first-extension",
|
||||
"version": "1.0.0",
|
||||
"contextFileName": "GEMINI.md",
|
||||
"mcpServers": {
|
||||
"nodeServer": {
|
||||
"command": "node",
|
||||
"args": ["${extensionPath}${/}example.js"],
|
||||
"cwd": "${extensionPath}"
|
||||
}
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
Restart Gemini CLI. The model now has the context from your `GEMINI.md` file in
|
||||
every session where the extension is active.
|
||||
|
||||
## (Optional) Step 7: Add an Agent Skill
|
||||
|
||||
[Agent Skills](../cli/skills.md) bundle specialized expertise and workflows.
|
||||
Skills are activated only when needed, which saves context tokens.
|
||||
|
||||
1. Create a `skills` directory and a subdirectory for your skill:
|
||||
|
||||
**macOS/Linux**
|
||||
|
||||
```bash
|
||||
mkdir -p skills/security-audit
|
||||
```
|
||||
|
||||
**Windows (PowerShell)**
|
||||
|
||||
```powershell
|
||||
New-Item -ItemType Directory -Force -Path "skills\security-audit"
|
||||
```
|
||||
|
||||
2. Create a `skills/security-audit/SKILL.md` file:
|
||||
|
||||
```markdown
|
||||
---
|
||||
name: security-audit
|
||||
description:
|
||||
Expertise in auditing code for security vulnerabilities. Use when the user
|
||||
asks to "check for security issues" or "audit" their changes.
|
||||
---
|
||||
|
||||
# Security Auditor
|
||||
|
||||
You are an expert security researcher. When auditing code:
|
||||
|
||||
1. Look for common vulnerabilities (OWASP Top 10).
|
||||
2. Check for hardcoded secrets or API keys.
|
||||
3. Suggest remediation steps for any findings.
|
||||
```
|
||||
|
||||
Gemini CLI automatically discovers skills bundled with your extension. The model
|
||||
activates them when it identifies a relevant task.
|
||||
|
||||
## Step 8: Release your extension
|
||||
|
||||
When your extension is ready, share it with others via a Git repository or
|
||||
GitHub Releases. Refer to the [Extension Releasing Guide](./releasing.md) for
|
||||
detailed instructions and learn how to list your extension in the gallery.
|
||||
|
||||
## Next steps
|
||||
|
||||
- [Extension reference](reference.md): Deeply understand the extension format,
|
||||
commands, and configuration.
|
||||
- [Best practices](best-practices.md): Learn strategies for building great
|
||||
extensions.
|
||||
@@ -0,0 +1,462 @@
|
||||
import { Tabs, TabItem } from '@astrojs/starlight/components';
|
||||
|
||||
# Gemini CLI authentication setup
|
||||
|
||||
To use Gemini CLI, you'll need to authenticate with Google. This guide helps you
|
||||
quickly find the best way to sign in based on your account type and how you're
|
||||
using the CLI.
|
||||
|
||||
> [!TIP]
|
||||
> Looking for a high-level comparison of all available subscriptions?
|
||||
> To compare features and find the right quota for your needs, see our
|
||||
> [Plans page](https://geminicli.com/plans/).
|
||||
|
||||
For most users, we recommend starting Gemini CLI and logging in with your
|
||||
personal Google account.
|
||||
|
||||
## Choose your authentication method <a id="auth-methods"></a>
|
||||
|
||||
Select the authentication method that matches your situation in the table below:
|
||||
|
||||
| User Type / Scenario | Recommended Authentication Method | Google Cloud Project Required |
|
||||
| :--------------------------------------------------------------------- | :--------------------------------------------------------------- | :---------------------------------------------------------- |
|
||||
| Individual Google accounts | [Sign in with Google](#login-google) | No, with exceptions |
|
||||
| Organization users with a company, school, or Google Workspace account | [Sign in with Google](#login-google) | [Yes](#set-gcp) |
|
||||
| AI Studio user with a Gemini API key | [Use Gemini API Key](#gemini-api) | No |
|
||||
| Google Cloud Vertex AI user | [Vertex AI](#vertex-ai) | [Yes](#set-gcp) |
|
||||
| [Headless mode](#headless) | [Use Gemini API Key](#gemini-api) or<br /> [Vertex AI](#vertex-ai) | No (for Gemini API Key)<br /> [Yes](#set-gcp) (for Vertex AI) |
|
||||
|
||||
### What is my Google account type?
|
||||
|
||||
- **Individual Google accounts:** Includes all
|
||||
[free tier accounts](../resources/quota-and-pricing.md#free-usage) such as
|
||||
Gemini Code Assist for individuals, as well as paid subscriptions for
|
||||
[Google AI Pro and Ultra](https://gemini.google/subscriptions/).
|
||||
|
||||
- **Organization accounts:** Accounts using paid licenses through an
|
||||
organization such as a company, school, or
|
||||
[Google Workspace](https://workspace.google.com/). Includes
|
||||
[Google AI Ultra for Business](https://support.google.com/a/answer/16345165)
|
||||
subscriptions.
|
||||
|
||||
## (Recommended) Sign in with Google <a id="login-google"></a>
|
||||
|
||||
If you run Gemini CLI on your local machine, the simplest authentication method
|
||||
is logging in with your Google account. This method requires a web browser on a
|
||||
machine that can communicate with the terminal running Gemini CLI (for example,
|
||||
your local machine).
|
||||
|
||||
If you are a **Google AI Pro** or **Google AI Ultra** subscriber, use the Google
|
||||
account associated with your subscription.
|
||||
|
||||
To authenticate and use Gemini CLI:
|
||||
|
||||
1. Start the CLI:
|
||||
|
||||
```bash
|
||||
gemini
|
||||
```
|
||||
|
||||
2. Select **Sign in with Google**. Gemini CLI opens a sign in prompt using your
|
||||
web browser. Follow the on-screen instructions. Your credentials will be
|
||||
cached locally for future sessions.
|
||||
|
||||
### Do I need to set my Google Cloud project?
|
||||
|
||||
Most individual Google accounts (free and paid) don't require a Google Cloud
|
||||
project for authentication. However, you'll need to set a Google Cloud project
|
||||
when you meet at least one of the following conditions:
|
||||
|
||||
- You are using a company, school, or Google Workspace account.
|
||||
- You are using a Gemini Code Assist license from the Google Developer Program.
|
||||
- You are using a license from a Gemini Code Assist subscription.
|
||||
|
||||
For instructions, see [Set your Google Cloud Project](#set-gcp).
|
||||
|
||||
## Use Gemini API key <a id="gemini-api"></a>
|
||||
|
||||
If you don't want to authenticate using your Google account, you can use an API
|
||||
key from Google AI Studio.
|
||||
|
||||
To authenticate and use Gemini CLI with a Gemini API key:
|
||||
|
||||
1. Obtain your API key from
|
||||
[Google AI Studio](https://aistudio.google.com/app/apikey).
|
||||
|
||||
2. Set the `GEMINI_API_KEY` environment variable to your key. For example:
|
||||
|
||||
<Tabs>
|
||||
<TabItem label="macOS/Linux">
|
||||
|
||||
```bash
|
||||
# Replace YOUR_GEMINI_API_KEY with the key from AI Studio
|
||||
export GEMINI_API_KEY="YOUR_GEMINI_API_KEY"
|
||||
```
|
||||
|
||||
</TabItem>
|
||||
<TabItem label="Windows (PowerShell)">
|
||||
|
||||
```powershell
|
||||
# Replace YOUR_GEMINI_API_KEY with the key from AI Studio
|
||||
$env:GEMINI_API_KEY="YOUR_GEMINI_API_KEY"
|
||||
```
|
||||
|
||||
</TabItem>
|
||||
</Tabs>
|
||||
|
||||
To make this setting persistent, see
|
||||
[Persisting Environment Variables](#persisting-vars).
|
||||
|
||||
3. Start the CLI:
|
||||
|
||||
```bash
|
||||
gemini
|
||||
```
|
||||
|
||||
4. Select **Use Gemini API key**.
|
||||
|
||||
> [!WARNING]
|
||||
> Treat API keys, especially for services like Gemini, as sensitive
|
||||
> credentials. Protect them to prevent unauthorized access and potential misuse
|
||||
> of the service under your account.
|
||||
|
||||
## Use Vertex AI <a id="vertex-ai"></a>
|
||||
|
||||
To use Gemini CLI with Google Cloud's Vertex AI platform, choose from the
|
||||
following authentication options:
|
||||
|
||||
- A. Application Default Credentials (ADC) using `gcloud`.
|
||||
- B. Service account JSON key.
|
||||
- C. Google Cloud API key.
|
||||
|
||||
Regardless of your authentication method for Vertex AI, you'll need to set
|
||||
`GOOGLE_CLOUD_PROJECT` to your Google Cloud project ID with the Vertex AI API
|
||||
enabled, and `GOOGLE_CLOUD_LOCATION` to the location of your Vertex AI resources
|
||||
or the location where you want to run your jobs.
|
||||
|
||||
For example:
|
||||
|
||||
<Tabs>
|
||||
<TabItem label="macOS/Linux">
|
||||
|
||||
```bash
|
||||
# Replace with your project ID and desired location (for example, us-central1)
|
||||
export GOOGLE_CLOUD_PROJECT="YOUR_PROJECT_ID"
|
||||
export GOOGLE_CLOUD_LOCATION="YOUR_PROJECT_LOCATION"
|
||||
```
|
||||
|
||||
</TabItem>
|
||||
<TabItem label="Windows (PowerShell)">
|
||||
|
||||
```powershell
|
||||
# Replace with your project ID and desired location (for example, us-central1)
|
||||
$env:GOOGLE_CLOUD_PROJECT="YOUR_PROJECT_ID"
|
||||
$env:GOOGLE_CLOUD_LOCATION="YOUR_PROJECT_LOCATION"
|
||||
```
|
||||
|
||||
</TabItem>
|
||||
</Tabs>
|
||||
|
||||
To make any Vertex AI environment variable settings persistent, see
|
||||
[Persisting Environment Variables](#persisting-vars).
|
||||
|
||||
#### A. Vertex AI - application default credentials (ADC) using `gcloud`
|
||||
|
||||
Consider this authentication method if you have Google Cloud CLI installed.
|
||||
|
||||
If you have previously set `GOOGLE_API_KEY` or `GEMINI_API_KEY`, you must unset
|
||||
them to use ADC.
|
||||
|
||||
<Tabs>
|
||||
<TabItem label="macOS/Linux">
|
||||
|
||||
```bash
|
||||
unset GOOGLE_API_KEY GEMINI_API_KEY
|
||||
```
|
||||
|
||||
</TabItem>
|
||||
<TabItem label="Windows (PowerShell)">
|
||||
|
||||
```powershell
|
||||
Remove-Item Env:\GOOGLE_API_KEY, Env:\GEMINI_API_KEY -ErrorAction Ignore
|
||||
```
|
||||
|
||||
</TabItem>
|
||||
</Tabs>
|
||||
|
||||
1. Verify you have a Google Cloud project and Vertex AI API is enabled.
|
||||
|
||||
2. Log in to Google Cloud:
|
||||
|
||||
```bash
|
||||
gcloud auth application-default login
|
||||
```
|
||||
|
||||
3. [Configure your Google Cloud Project](#set-gcp).
|
||||
|
||||
4. Start the CLI:
|
||||
|
||||
```bash
|
||||
gemini
|
||||
```
|
||||
|
||||
5. Select **Vertex AI**.
|
||||
|
||||
#### B. Vertex AI - service account JSON key
|
||||
|
||||
Consider this method of authentication in non-interactive environments, CI/CD
|
||||
pipelines, or if your organization restricts user-based ADC or API key creation.
|
||||
|
||||
If you have previously set `GOOGLE_API_KEY` or `GEMINI_API_KEY`, you must unset
|
||||
them:
|
||||
|
||||
<Tabs>
|
||||
<TabItem label="macOS/Linux">
|
||||
|
||||
```bash
|
||||
unset GOOGLE_API_KEY GEMINI_API_KEY
|
||||
```
|
||||
|
||||
</TabItem>
|
||||
<TabItem label="Windows (PowerShell)">
|
||||
|
||||
```powershell
|
||||
Remove-Item Env:\GOOGLE_API_KEY, Env:\GEMINI_API_KEY -ErrorAction Ignore
|
||||
```
|
||||
|
||||
</TabItem>
|
||||
</Tabs>
|
||||
|
||||
1. [Create a service account and key](https://cloud.google.com/iam/docs/keys-create-delete)
|
||||
and download the provided JSON file. Assign the "Vertex AI User" role to the
|
||||
service account.
|
||||
|
||||
2. Set the `GOOGLE_APPLICATION_CREDENTIALS` environment variable to the JSON
|
||||
file's absolute path. For example:
|
||||
|
||||
<Tabs>
|
||||
<TabItem label="macOS/Linux">
|
||||
|
||||
```bash
|
||||
# Replace /path/to/your/keyfile.json with the actual path
|
||||
export GOOGLE_APPLICATION_CREDENTIALS="/path/to/your/keyfile.json"
|
||||
```
|
||||
|
||||
</TabItem>
|
||||
<TabItem label="Windows (PowerShell)">
|
||||
|
||||
```powershell
|
||||
# Replace C:\path\to\your\keyfile.json with the actual path
|
||||
$env:GOOGLE_APPLICATION_CREDENTIALS="C:\path\to\your\keyfile.json"
|
||||
```
|
||||
|
||||
</TabItem>
|
||||
</Tabs>
|
||||
|
||||
3. [Configure your Google Cloud Project](#set-gcp).
|
||||
|
||||
4. Start the CLI:
|
||||
|
||||
```bash
|
||||
gemini
|
||||
```
|
||||
|
||||
5. Select **Vertex AI**.
|
||||
|
||||
> [!WARNING]
|
||||
> Protect your service account key file as it gives access to
|
||||
> your resources.
|
||||
|
||||
#### C. Vertex AI - Google Cloud API key
|
||||
|
||||
1. Obtain a Google Cloud API key:
|
||||
[Get an API Key](https://cloud.google.com/vertex-ai/generative-ai/docs/start/api-keys?usertype=newuser).
|
||||
|
||||
2. Set the `GOOGLE_API_KEY` environment variable:
|
||||
|
||||
<Tabs>
|
||||
<TabItem label="macOS/Linux">
|
||||
|
||||
```bash
|
||||
# Replace YOUR_GOOGLE_API_KEY with your Vertex AI API key
|
||||
export GOOGLE_API_KEY="YOUR_GOOGLE_API_KEY"
|
||||
```
|
||||
|
||||
</TabItem>
|
||||
<TabItem label="Windows (PowerShell)">
|
||||
|
||||
```powershell
|
||||
# Replace YOUR_GOOGLE_API_KEY with your Vertex AI API key
|
||||
$env:GOOGLE_API_KEY="YOUR_GOOGLE_API_KEY"
|
||||
```
|
||||
|
||||
</TabItem>
|
||||
</Tabs>
|
||||
|
||||
If you see errors like `"API keys are not supported by this API..."`, your
|
||||
organization might restrict API key usage for this service. Try the other
|
||||
Vertex AI authentication methods instead.
|
||||
|
||||
3. [Configure your Google Cloud Project](#set-gcp).
|
||||
|
||||
4. Start the CLI:
|
||||
|
||||
```bash
|
||||
gemini
|
||||
```
|
||||
|
||||
5. Select **Vertex AI**.
|
||||
|
||||
## Set your Google Cloud project <a id="set-gcp"></a>
|
||||
|
||||
> [!IMPORTANT]
|
||||
> Most individual Google accounts (free and paid) don't require a
|
||||
> Google Cloud project for authentication.
|
||||
|
||||
When you sign in using your Google account, you may need to configure a Google
|
||||
Cloud project for Gemini CLI to use. This applies when you meet at least one of
|
||||
the following conditions:
|
||||
|
||||
- You are using a Company, School, or Google Workspace account.
|
||||
- You are using a Gemini Code Assist license from the Google Developer Program.
|
||||
- You are using a license from a Gemini Code Assist subscription.
|
||||
|
||||
To configure Gemini CLI to use a Google Cloud project, do the following:
|
||||
|
||||
1. [Find your Google Cloud Project ID](https://support.google.com/googleapi/answer/7014113).
|
||||
|
||||
2. [Enable the Gemini for Cloud API](https://cloud.google.com/gemini/docs/discover/set-up-gemini#enable-api).
|
||||
|
||||
3. [Configure necessary IAM access permissions](https://cloud.google.com/gemini/docs/discover/set-up-gemini#grant-iam).
|
||||
|
||||
4. Configure your environment variables. Set either the `GOOGLE_CLOUD_PROJECT`
|
||||
or `GOOGLE_CLOUD_PROJECT_ID` variable to the project ID to use with Gemini
|
||||
CLI. Gemini CLI checks for `GOOGLE_CLOUD_PROJECT` first, then falls back to
|
||||
`GOOGLE_CLOUD_PROJECT_ID`.
|
||||
|
||||
For example, to set the `GOOGLE_CLOUD_PROJECT_ID` variable:
|
||||
|
||||
<Tabs>
|
||||
<TabItem label="macOS/Linux">
|
||||
|
||||
```bash
|
||||
# Replace YOUR_PROJECT_ID with your actual Google Cloud project ID
|
||||
export GOOGLE_CLOUD_PROJECT="YOUR_PROJECT_ID"
|
||||
```
|
||||
|
||||
</TabItem>
|
||||
<TabItem label="Windows (PowerShell)">
|
||||
|
||||
```powershell
|
||||
# Replace YOUR_PROJECT_ID with your actual Google Cloud project ID
|
||||
$env:GOOGLE_CLOUD_PROJECT="YOUR_PROJECT_ID"
|
||||
```
|
||||
|
||||
</TabItem>
|
||||
</Tabs>
|
||||
|
||||
To make this setting persistent, see
|
||||
[Persisting Environment Variables](#persisting-vars).
|
||||
|
||||
## Persisting environment variables <a id="persisting-vars"></a>
|
||||
|
||||
To avoid setting environment variables for every terminal session, you can
|
||||
persist them with the following methods:
|
||||
|
||||
1. **Add your environment variables to your shell configuration file:** Append
|
||||
the environment variable commands to your shell's startup file.
|
||||
|
||||
<Tabs>
|
||||
<TabItem label="macOS/Linux">
|
||||
|
||||
(for example, `~/.bashrc`, `~/.zshrc`, or `~/.profile`):
|
||||
|
||||
```bash
|
||||
echo 'export GOOGLE_CLOUD_PROJECT="YOUR_PROJECT_ID"' >> ~/.bashrc
|
||||
source ~/.bashrc
|
||||
```
|
||||
|
||||
</TabItem>
|
||||
<TabItem label="Windows (PowerShell)">
|
||||
|
||||
(for example, `$PROFILE`):
|
||||
|
||||
```powershell
|
||||
Add-Content -Path $PROFILE -Value '$env:GOOGLE_CLOUD_PROJECT="YOUR_PROJECT_ID"'
|
||||
. $PROFILE
|
||||
```
|
||||
|
||||
</TabItem>
|
||||
</Tabs>
|
||||
|
||||
> [!WARNING]
|
||||
> Be aware that when you export API keys or service account
|
||||
> paths in your shell configuration file, any process launched from that
|
||||
> shell can read them.
|
||||
|
||||
2. **Use a `.env` file:** Create a `.gemini/.env` file in your project
|
||||
directory or home directory. Gemini CLI automatically loads variables from
|
||||
the first `.env` file it finds, searching up from the current directory,
|
||||
then in your home directory's `.gemini/.env` (for example, `~/.gemini/.env`
|
||||
or `%USERPROFILE%\.gemini\.env`).
|
||||
|
||||
Example for user-wide settings:
|
||||
|
||||
<Tabs>
|
||||
<TabItem label="macOS/Linux">
|
||||
|
||||
```bash
|
||||
mkdir -p ~/.gemini
|
||||
cat >> ~/.gemini/.env <<'EOF'
|
||||
GOOGLE_CLOUD_PROJECT="your-project-id"
|
||||
# Add other variables like GEMINI_API_KEY as needed
|
||||
EOF
|
||||
```
|
||||
|
||||
</TabItem>
|
||||
<TabItem label="Windows (PowerShell)">
|
||||
|
||||
```powershell
|
||||
New-Item -ItemType Directory -Force -Path "$env:USERPROFILE\.gemini"
|
||||
@"
|
||||
GOOGLE_CLOUD_PROJECT="your-project-id"
|
||||
# Add other variables like GEMINI_API_KEY as needed
|
||||
"@ | Out-File -FilePath "$env:USERPROFILE\.gemini\.env" -Encoding utf8 -Append
|
||||
```
|
||||
|
||||
</TabItem>
|
||||
</Tabs>
|
||||
|
||||
Variables are loaded from the first file found, not merged.
|
||||
|
||||
## Running in Google Cloud environments <a id="cloud-env"></a>
|
||||
|
||||
When running Gemini CLI within certain Google Cloud environments, authentication
|
||||
is automatic.
|
||||
|
||||
In a Google Cloud Shell environment, Gemini CLI typically authenticates
|
||||
automatically using your Cloud Shell credentials. In Compute Engine
|
||||
environments, Gemini CLI automatically uses Application Default Credentials
|
||||
(ADC) from the environment's metadata server.
|
||||
|
||||
If automatic authentication fails, use one of the interactive methods described
|
||||
on this page.
|
||||
|
||||
## Running in headless mode <a id="headless"></a>
|
||||
|
||||
[Headless mode](../cli/headless.md) will use your existing authentication
|
||||
method, if an existing authentication credential is cached.
|
||||
|
||||
If you have not already signed in with an authentication credential, you must
|
||||
configure authentication using environment variables:
|
||||
|
||||
- [Use Gemini API Key](#gemini-api)
|
||||
- [Vertex AI](#vertex-ai)
|
||||
|
||||
## What's next?
|
||||
|
||||
Your authentication method affects your quotas, pricing, Terms of Service, and
|
||||
privacy notices. Review the following pages to learn more:
|
||||
|
||||
- [Gemini CLI: Quotas and Pricing](../resources/quota-and-pricing.md).
|
||||
- [Gemini CLI: Terms of Service and Privacy Notice](../resources/tos-privacy.md).
|
||||
@@ -0,0 +1,125 @@
|
||||
# Gemini 3 Pro and Gemini 3 Flash on Gemini CLI
|
||||
|
||||
Learn about how you can use Gemini 3 Pro and Gemini 3 Flash on Gemini CLI.
|
||||
|
||||
<!-- prettier-ignore -->
|
||||
> [!NOTE]
|
||||
> Gemini 3.1 Pro Preview is rolling out. To determine whether you have
|
||||
> access to Gemini 3.1, use the `/model` command and select **Manual**. If you
|
||||
> have access, you will see `gemini-3.1-pro-preview`.
|
||||
>
|
||||
> If you have access to Gemini 3.1, it will be included in model routing when
|
||||
> you select **Auto (Gemini 3)**. You can also launch the Gemini 3.1 model
|
||||
> directly using the `-m` flag:
|
||||
>
|
||||
> ```
|
||||
> gemini -m gemini-3.1-pro-preview
|
||||
> ```
|
||||
>
|
||||
> Learn more about [models](../cli/model.md) and
|
||||
> [model routing](../cli/model-routing.md).
|
||||
|
||||
## How to get started with Gemini 3 on Gemini CLI
|
||||
|
||||
Get started by upgrading Gemini CLI to the latest version:
|
||||
|
||||
```bash
|
||||
npm install -g @google/gemini-cli@latest
|
||||
```
|
||||
|
||||
If your version is 0.21.1 or later:
|
||||
|
||||
1. Run `/model`.
|
||||
2. Select **Auto (Gemini 3)**.
|
||||
|
||||
For more information, see [Gemini CLI model selection](../cli/model.md).
|
||||
|
||||
### Usage limits and fallback
|
||||
|
||||
Gemini CLI will tell you when you reach your Gemini 3 Pro daily usage limit.
|
||||
When you encounter that limit, you’ll be given the option to switch to Gemini
|
||||
2.5 Pro, upgrade for higher limits, or stop. You’ll also be told when your usage
|
||||
limit resets and Gemini 3 Pro can be used again.
|
||||
|
||||
<!-- prettier-ignore -->
|
||||
> [!TIP]
|
||||
> Looking to upgrade for higher limits? To compare subscription
|
||||
> options and find the right quota for your needs, see our
|
||||
> [Plans page](https://geminicli.com/plans/).
|
||||
|
||||
Similarly, when you reach your daily usage limit for Gemini 2.5 Pro, you’ll see
|
||||
a message prompting fallback to Gemini 2.5 Flash.
|
||||
|
||||
### Capacity errors
|
||||
|
||||
There may be times when the Gemini 3 Pro model is overloaded. When that happens,
|
||||
Gemini CLI will ask you to decide whether you want to keep trying Gemini 3 Pro
|
||||
or fallback to Gemini 2.5 Pro.
|
||||
|
||||
<!-- prettier-ignore -->
|
||||
> [!NOTE]
|
||||
> The **Keep trying** option uses exponential backoff, in which Gemini
|
||||
> CLI waits longer between each retry, when the system is busy. If the retry
|
||||
> doesn't happen immediately, wait a few minutes for the request to
|
||||
> process.
|
||||
|
||||
### Model selection and routing types
|
||||
|
||||
When using Gemini CLI, you may want to control how your requests are routed
|
||||
between models. By default, Gemini CLI uses **Auto** routing.
|
||||
|
||||
When using Gemini 3 Pro, you may want to use Auto routing or Pro routing to
|
||||
manage your usage limits:
|
||||
|
||||
- **Auto routing:** Auto routing first determines whether a prompt involves a
|
||||
complex or simple operation. For simple prompts, it will automatically use
|
||||
Gemini 2.5 Flash. For complex prompts, if Gemini 3 Pro is enabled, it will use
|
||||
Gemini 3 Pro; otherwise, it will use Gemini 2.5 Pro.
|
||||
- **Pro routing:** If you want to ensure your task is processed by the most
|
||||
capable model, use `/model` and select **Pro**. Gemini CLI will prioritize the
|
||||
most capable model available, including Gemini 3 Pro if it has been enabled.
|
||||
|
||||
To learn more about selecting a model and routing, refer to
|
||||
[Gemini CLI Model Selection](../cli/model.md).
|
||||
|
||||
## How to enable Gemini 3 with Gemini CLI on Gemini Code Assist
|
||||
|
||||
If you're using Gemini Code Assist Standard or Gemini Code Assist Enterprise,
|
||||
enabling Gemini 3 Pro on Gemini CLI requires configuring your release channels.
|
||||
Using Gemini 3 Pro will require two steps: administrative enablement and user
|
||||
enablement.
|
||||
|
||||
To learn more about these settings, refer to
|
||||
[Configure Gemini Code Assist release channels](https://developers.google.com/gemini-code-assist/docs/configure-release-channels).
|
||||
|
||||
### Administrator instructions
|
||||
|
||||
An administrator with **Google Cloud Settings Admin** permissions must follow
|
||||
these directions:
|
||||
|
||||
- Navigate to the Google Cloud Project you're using with Gemini CLI for Code
|
||||
Assist.
|
||||
- Go to **Admin for Gemini** > **Settings**.
|
||||
- Under **Release channels for Gemini Code Assist in local IDEs** select
|
||||
**Preview**.
|
||||
- Click **Save changes**.
|
||||
|
||||
### User instructions
|
||||
|
||||
Wait for two to three minutes after your administrator has enabled **Preview**,
|
||||
then:
|
||||
|
||||
- Open Gemini CLI.
|
||||
- Use the `/settings` command.
|
||||
- Set **Preview Features** to `true`.
|
||||
|
||||
Restart Gemini CLI and you should have access to Gemini 3.
|
||||
|
||||
## Next steps
|
||||
|
||||
If you need help, we recommend searching for an existing
|
||||
[GitHub issue](https://github.com/google-gemini/gemini-cli/issues). If you
|
||||
cannot find a GitHub issue that matches your concern, you can
|
||||
[create a new issue](https://github.com/google-gemini/gemini-cli/issues/new/choose).
|
||||
For comments and feedback, consider opening a
|
||||
[GitHub discussion](https://github.com/google-gemini/gemini-cli/discussions).
|
||||
@@ -0,0 +1,209 @@
|
||||
# Get started with Gemini CLI
|
||||
|
||||
Welcome to Gemini CLI! This guide will help you install, configure, and start
|
||||
using Gemini CLI to enhance your workflow right from your terminal.
|
||||
|
||||
## Quickstart: Install, authenticate, configure, and use Gemini CLI
|
||||
|
||||
Gemini CLI brings the power of advanced language models directly to your command
|
||||
line interface. As an AI-powered assistant, Gemini CLI can help you with a
|
||||
variety of tasks, from understanding and generating code to reviewing and
|
||||
editing documents.
|
||||
|
||||
## Install
|
||||
|
||||
The standard method to install and run Gemini CLI uses `npm`:
|
||||
|
||||
```bash
|
||||
npm install -g @google/gemini-cli
|
||||
```
|
||||
|
||||
Once Gemini CLI is installed, run Gemini CLI from your command line:
|
||||
|
||||
```bash
|
||||
gemini
|
||||
```
|
||||
|
||||
For more installation options, see
|
||||
[Gemini CLI Installation](./installation.mdx).
|
||||
|
||||
## Authenticate
|
||||
|
||||
To begin using Gemini CLI, you must authenticate with a Google service. In most
|
||||
cases, you can log in with your existing Google account:
|
||||
|
||||
1. Run Gemini CLI after installation:
|
||||
|
||||
```bash
|
||||
gemini
|
||||
```
|
||||
|
||||
2. When asked "How would you like to authenticate for this project?" select **1.
|
||||
Sign in with Google**.
|
||||
|
||||
3. Select your Google account.
|
||||
|
||||
4. Click on **Sign in**.
|
||||
|
||||
Certain account types may require you to configure a Google Cloud project. For
|
||||
more information, including other authentication methods, see
|
||||
[Gemini CLI Authentication Setup](./authentication.mdx).
|
||||
|
||||
## Configure
|
||||
|
||||
Gemini CLI offers several ways to configure its behavior, including environment
|
||||
variables, command-line arguments, and settings files.
|
||||
|
||||
To explore your configuration options, see
|
||||
[Gemini CLI Configuration](../reference/configuration.md).
|
||||
|
||||
## Use
|
||||
|
||||
Once installed and authenticated, you can start using Gemini CLI by issuing
|
||||
commands and prompts in your terminal. Ask it to generate code, explain files,
|
||||
and more.
|
||||
|
||||
<!-- prettier-ignore -->
|
||||
> [!NOTE]
|
||||
> These examples demonstrate potential capabilities. Your actual
|
||||
> results can vary based on the model used and your project environment.
|
||||
|
||||
### Rename your photographs based on content
|
||||
|
||||
You can use Gemini CLI to automate file management tasks that require visual
|
||||
analysis. In this example, Gemini CLI renames images based on their actual
|
||||
subject matter.
|
||||
|
||||
Scenario: You have a folder containing the following files:
|
||||
|
||||
```bash
|
||||
photos/photo1.png
|
||||
photos/photo2.png
|
||||
photos/photo3.png
|
||||
```
|
||||
|
||||
Give Gemini the following prompt:
|
||||
|
||||
```cli
|
||||
Rename the photos in my "photos" directory based on their contents.
|
||||
```
|
||||
|
||||
Result: Gemini asks for permission to rename your files.
|
||||
|
||||
Select **Allow once** and your files are renamed:
|
||||
|
||||
```bash
|
||||
photos/yellow_flowers.png
|
||||
photos/antique_dresser.png
|
||||
photos/green_android_robot.png
|
||||
```
|
||||
|
||||
### Explain a repository by reading its code
|
||||
|
||||
Gemini CLI is effective for rapid codebase exploration. The following example
|
||||
shows how to ask Gemini CLI to fetch, analyze, and summarize a remote project.
|
||||
|
||||
Scenario: You want to understand how a popular open-source utility works by
|
||||
inspecting its code, not just its README.
|
||||
|
||||
Give Gemini CLI the following prompt:
|
||||
|
||||
```cli
|
||||
Clone the 'chalk' repository from https://github.com/chalk/chalk, read its key source files, and explain how it works.
|
||||
```
|
||||
|
||||
Result: Gemini performs a sequence of actions to answer your request.
|
||||
|
||||
1. First, it asks for permission to run `git clone` to download the repository.
|
||||
2. Next, it finds the important source files and asks for permission to read
|
||||
them.
|
||||
3. Finally, after analyzing the code, it provides a summary.
|
||||
|
||||
Gemini CLI returns an explanation based on the actual source code:
|
||||
|
||||
```markdown
|
||||
The `chalk` library is a popular npm package for styling terminal output with
|
||||
colors. After analyzing the source code, here's how it works:
|
||||
|
||||
- **Core functionality:** The main file sets up a chainable API. Each color or
|
||||
modifier (like `bold` or `italic`) is a getter that appends the corresponding
|
||||
ANSI escape code to an internal stack.
|
||||
|
||||
- **Chainable API:** When you call `chalk.red.bold('Hello')`, you are accessing
|
||||
getters. The `red` getter adds the red color code, and the `bold` getter adds
|
||||
the bold code.
|
||||
|
||||
- **Output generation:** When the chain is treated as a string (for example, in
|
||||
`console.log`), a final `toString()` method is called. This method joins all
|
||||
the stored ANSI codes, wraps them around the input string ('Hello'), and adds
|
||||
a reset code at the end. This produces the final, styled string that the
|
||||
terminal can render.
|
||||
```
|
||||
|
||||
### Combine two spreadsheets into one spreadsheet
|
||||
|
||||
Gemini CLI can process and transform data across multiple files. Use this
|
||||
capability to merge reports or reformat data sets without manual copying.
|
||||
|
||||
Scenario: You have two .csv files: `Revenue - 2023.csv` and
|
||||
`Revenue - 2024.csv`. Each file contains monthly revenue figures.
|
||||
|
||||
Give Gemini CLI the following prompt:
|
||||
|
||||
```cli
|
||||
Combine the two .csv files into a single .csv file, with each year a different column.
|
||||
```
|
||||
|
||||
Result: Gemini CLI reads each file and then asks for permission to write a new
|
||||
file. Provide your permission and Gemini CLI provides the combined data:
|
||||
|
||||
```csv
|
||||
Month,2023,2024
|
||||
January,0,1000
|
||||
February,0,1200
|
||||
March,0,2400
|
||||
April,900,500
|
||||
May,1000,800
|
||||
June,1000,900
|
||||
July,1200,1000
|
||||
August,1800,400
|
||||
September,2000,2000
|
||||
October,2400,3400
|
||||
November,3400,1800
|
||||
December,2100,9000
|
||||
```
|
||||
|
||||
### Run unit tests
|
||||
|
||||
Gemini CLI can generate boilerplate code and tests based on your existing
|
||||
implementation. This example demonstrates how to request code coverage for a
|
||||
JavaScript component.
|
||||
|
||||
Scenario: You've written a simple login page. You wish to write unit tests to
|
||||
ensure that your login page has code coverage.
|
||||
|
||||
Give Gemini CLI the following prompt:
|
||||
|
||||
```cli
|
||||
Write unit tests for Login.js.
|
||||
```
|
||||
|
||||
Result: Gemini CLI asks for permission to write a new file and creates a test
|
||||
for your login page.
|
||||
|
||||
## Check usage and quota
|
||||
|
||||
You can check your current token usage and quota information using the
|
||||
`/stats model` command. This command provides a snapshot of your current
|
||||
session's token usage, as well as your overall quota and usage for the supported
|
||||
models.
|
||||
|
||||
For more information on the `/stats` command and its subcommands, see the
|
||||
[Command Reference](../reference/commands.md#stats).
|
||||
|
||||
## Next steps
|
||||
|
||||
- Follow the [File management](../cli/tutorials/file-management.md) guide to
|
||||
start working with your codebase.
|
||||
- See [Shell commands](../cli/tutorials/shell-commands.md) to learn about
|
||||
terminal integration.
|
||||
@@ -0,0 +1,201 @@
|
||||
import { Tabs, TabItem } from '@astrojs/starlight/components';
|
||||
|
||||
# Gemini CLI installation, execution, and releases
|
||||
|
||||
This document provides an overview of Gemini CLI's system requirements,
|
||||
installation methods, and release types.
|
||||
|
||||
## Recommended system specifications
|
||||
|
||||
- **Operating System:**
|
||||
- macOS 15+
|
||||
- Windows 11 24H2+
|
||||
- Ubuntu 20.04+
|
||||
- **Hardware:**
|
||||
- "Casual" usage: 4GB+ RAM (short sessions, common tasks and edits)
|
||||
- "Power" usage: 16GB+ RAM (long sessions, large codebases, deep context)
|
||||
- **Runtime:** Node.js 20.0.0+
|
||||
- **Shell:** Bash, Zsh, or PowerShell
|
||||
- **Location:**
|
||||
[Gemini Code Assist supported locations](https://developers.google.com/gemini-code-assist/resources/available-locations#americas)
|
||||
- **Internet connection required**
|
||||
|
||||
## Install Gemini CLI
|
||||
|
||||
We recommend most users install Gemini CLI using one of the following
|
||||
installation methods. Note that Gemini CLI comes pre-installed on
|
||||
[**Cloud Shell**](https://docs.cloud.google.com/shell/docs) and
|
||||
[**Cloud Workstations**](https://cloud.google.com/workstations).
|
||||
|
||||
<Tabs>
|
||||
<TabItem label="npm">
|
||||
|
||||
Install globally with npm:
|
||||
|
||||
```bash
|
||||
npm install -g @google/gemini-cli
|
||||
```
|
||||
|
||||
</TabItem>
|
||||
<TabItem label="Homebrew (macOS/Linux)">
|
||||
|
||||
Install globally with Homebrew:
|
||||
|
||||
```bash
|
||||
brew install gemini-cli
|
||||
```
|
||||
|
||||
</TabItem>
|
||||
<TabItem label="MacPorts (macOS)">
|
||||
|
||||
Install globally with MacPorts:
|
||||
|
||||
```bash
|
||||
sudo port install gemini-cli
|
||||
```
|
||||
|
||||
</TabItem>
|
||||
<TabItem label="Anaconda">
|
||||
|
||||
Install with Anaconda (for restricted environments):
|
||||
|
||||
```bash
|
||||
# Create and activate a new environment
|
||||
conda create -y -n gemini_env -c conda-forge nodejs
|
||||
conda activate gemini_env
|
||||
|
||||
# Install Gemini CLI globally via npm (inside the environment)
|
||||
npm install -g @google/gemini-cli
|
||||
```
|
||||
|
||||
</TabItem>
|
||||
</Tabs>
|
||||
|
||||
## Run Gemini CLI
|
||||
|
||||
For most users, we recommend running Gemini CLI with the `gemini` command:
|
||||
|
||||
```bash
|
||||
gemini
|
||||
```
|
||||
|
||||
For a list of options and additional commands, see the
|
||||
[CLI cheatsheet](../cli/cli-reference.md).
|
||||
|
||||
You can also run Gemini CLI using one of the following advanced methods:
|
||||
|
||||
<Tabs>
|
||||
<TabItem label="npx">
|
||||
|
||||
Run instantly with npx. You can run Gemini CLI without permanent installation.
|
||||
|
||||
```bash
|
||||
# Using npx (no installation required)
|
||||
npx @google/gemini-cli
|
||||
```
|
||||
|
||||
You can also execute the CLI directly from the main branch on GitHub, which is
|
||||
helpful for testing features still in development:
|
||||
|
||||
```bash
|
||||
npx https://github.com/google-gemini/gemini-cli
|
||||
```
|
||||
|
||||
</TabItem>
|
||||
<TabItem label="Docker/Podman Sandbox">
|
||||
|
||||
For security and isolation, Gemini CLI can be run inside a container. This is
|
||||
the default way that the CLI executes tools that might have side effects.
|
||||
|
||||
- **Directly from the registry:** You can run the published sandbox image
|
||||
directly. This is useful for environments where you only have Docker and want
|
||||
to run the CLI.
|
||||
```bash
|
||||
# Run the published sandbox image for a specified CLI version
|
||||
docker run --rm -it us-docker.pkg.dev/gemini-code-dev/gemini-cli/sandbox:0.42.0-nightly.20260428.g59b2dea0e
|
||||
```
|
||||
- **Using the `--sandbox` flag:** If you have Gemini CLI installed locally
|
||||
(using the standard installation described above), you can instruct it to run
|
||||
inside the sandbox container.
|
||||
```bash
|
||||
gemini --sandbox -y -p "your prompt here"
|
||||
```
|
||||
|
||||
</TabItem>
|
||||
<TabItem label="From source">
|
||||
|
||||
Contributors to the project will want to run the CLI directly from the source
|
||||
code.
|
||||
|
||||
- **Development mode:** This method provides hot-reloading and is useful for
|
||||
active development.
|
||||
```bash
|
||||
# From the root of the repository
|
||||
npm run start
|
||||
```
|
||||
- **Production mode (React optimizations):** This method runs the CLI with React
|
||||
production mode enabled, which is useful for testing performance without
|
||||
development overhead.
|
||||
```bash
|
||||
# From the root of the repository
|
||||
npm run start:prod
|
||||
```
|
||||
- **Production-like mode (linked package):** This method simulates a global
|
||||
installation by linking your local package. It's useful for testing a local
|
||||
build in a production workflow.
|
||||
|
||||
```bash
|
||||
# Link the local cli package to your global node_modules
|
||||
npm link packages/cli
|
||||
|
||||
# Now you can run your local version using the `gemini` command
|
||||
gemini
|
||||
```
|
||||
|
||||
</TabItem>
|
||||
</Tabs>
|
||||
|
||||
## Releases
|
||||
|
||||
Gemini CLI has three release channels: stable, preview, and nightly. For most
|
||||
users, we recommend the stable release, which is the default installation.
|
||||
|
||||
<Tabs>
|
||||
<TabItem label="Stable">
|
||||
|
||||
Stable releases are published each week. A stable release is created from the
|
||||
previous week's preview release along with any bug fixes. The stable release
|
||||
uses the `latest` tag. Omitting the tag also installs the latest stable
|
||||
release by default.
|
||||
|
||||
```bash
|
||||
# Both commands install the latest stable release.
|
||||
npm install -g @google/gemini-cli
|
||||
npm install -g @google/gemini-cli@latest
|
||||
```
|
||||
|
||||
</TabItem>
|
||||
<TabItem label="Preview">
|
||||
|
||||
New preview releases will be published each week. These releases are not fully
|
||||
vetted and may contain regressions or other outstanding issues. Try out the
|
||||
preview release by using the `preview` tag:
|
||||
|
||||
```bash
|
||||
npm install -g @google/gemini-cli@preview
|
||||
```
|
||||
|
||||
</TabItem>
|
||||
<TabItem label="Nightly">
|
||||
|
||||
Nightly releases are published every day. The nightly release includes all
|
||||
changes from the main branch at time of release. It should be assumed there are
|
||||
pending validations and issues. You can help test the latest changes by
|
||||
installing with the `nightly` tag:
|
||||
|
||||
```bash
|
||||
npm install -g @google/gemini-cli@nightly
|
||||
```
|
||||
|
||||
</TabItem>
|
||||
</Tabs>
|
||||
@@ -0,0 +1,710 @@
|
||||
# Hooks Best Practices
|
||||
|
||||
This guide covers security considerations, performance optimization, debugging
|
||||
techniques, and privacy considerations for developing and deploying hooks in
|
||||
Gemini CLI.
|
||||
|
||||
## Performance
|
||||
|
||||
### Keep hooks fast
|
||||
|
||||
Hooks run synchronously—slow hooks delay the agent loop. Optimize for speed by
|
||||
using parallel operations:
|
||||
|
||||
```javascript
|
||||
// Sequential operations are slower
|
||||
const data1 = await fetch(url1).then((r) => r.json());
|
||||
const data2 = await fetch(url2).then((r) => r.json());
|
||||
|
||||
// Prefer parallel operations for better performance
|
||||
// Start requests concurrently
|
||||
const p1 = fetch(url1).then((r) => r.json());
|
||||
const p2 = fetch(url2).then((r) => r.json());
|
||||
|
||||
// Wait for all results
|
||||
const [data1, data2] = await Promise.all([p1, p2]);
|
||||
```
|
||||
|
||||
### Cache expensive operations
|
||||
|
||||
Store results between invocations to avoid repeated computation, especially for
|
||||
hooks that run frequently (like `BeforeTool` or `AfterModel`).
|
||||
|
||||
```javascript
|
||||
const fs = require('fs');
|
||||
const path = require('path');
|
||||
|
||||
const CACHE_FILE = '.gemini/hook-cache.json';
|
||||
|
||||
function readCache() {
|
||||
try {
|
||||
return JSON.parse(fs.readFileSync(CACHE_FILE, 'utf8'));
|
||||
} catch {
|
||||
return {};
|
||||
}
|
||||
}
|
||||
|
||||
function writeCache(data) {
|
||||
fs.writeFileSync(CACHE_FILE, JSON.stringify(data, null, 2));
|
||||
}
|
||||
|
||||
async function main() {
|
||||
const cache = readCache();
|
||||
const cacheKey = `tool-list-${(Date.now() / 3600000) | 0}`; // Hourly cache
|
||||
|
||||
if (cache[cacheKey]) {
|
||||
// Write JSON to stdout
|
||||
console.log(JSON.stringify(cache[cacheKey]));
|
||||
return;
|
||||
}
|
||||
|
||||
// Expensive operation
|
||||
const result = await computeExpensiveResult();
|
||||
cache[cacheKey] = result;
|
||||
writeCache(cache);
|
||||
|
||||
console.log(JSON.stringify(result));
|
||||
}
|
||||
```
|
||||
|
||||
### Use appropriate events
|
||||
|
||||
Choose hook events that match your use case to avoid unnecessary execution.
|
||||
|
||||
- **`AfterAgent`**: Fires **once** per turn after the model finishes its final
|
||||
response. Use this for quality validation (Retries) or final logging.
|
||||
- **`AfterModel`**: Fires after **every chunk** of LLM output. Use this for
|
||||
real-time redaction, PII filtering, or monitoring output as it streams.
|
||||
|
||||
If you only need to check the final completion, use `AfterAgent` to save
|
||||
performance.
|
||||
|
||||
### Filter with matchers
|
||||
|
||||
Use specific matchers to avoid unnecessary hook execution. Instead of matching
|
||||
all tools with `*`, specify only the tools you need. This saves the overhead of
|
||||
spawning a process for irrelevant events.
|
||||
|
||||
```json
|
||||
{
|
||||
"matcher": "write_file|replace",
|
||||
"hooks": [
|
||||
{
|
||||
"name": "validate-writes",
|
||||
"type": "command",
|
||||
"command": "./validate.sh"
|
||||
}
|
||||
]
|
||||
}
|
||||
```
|
||||
|
||||
### Optimize JSON parsing
|
||||
|
||||
For large inputs (like `AfterModel` receiving a large context), standard JSON
|
||||
parsing can be slow. If you only need one field, consider streaming parsers or
|
||||
lightweight extraction logic, though for most shell scripts `jq` is sufficient.
|
||||
|
||||
## Debugging
|
||||
|
||||
### The "Strict JSON" rule
|
||||
|
||||
The most common cause of hook failure is "polluting" the standard output.
|
||||
|
||||
- **stdout** is for **JSON only**.
|
||||
- **stderr** is for **logs and text**.
|
||||
|
||||
**Good:**
|
||||
|
||||
```bash
|
||||
#!/bin/bash
|
||||
echo "Starting check..." >&2 # <--- Redirect to stderr
|
||||
echo '{"decision": "allow"}'
|
||||
|
||||
```
|
||||
|
||||
### Log to files
|
||||
|
||||
Since hooks run in the background, writing to a dedicated log file is often the
|
||||
easiest way to debug complex logic.
|
||||
|
||||
```bash
|
||||
#!/usr/bin/env bash
|
||||
LOG_FILE=".gemini/hooks/debug.log"
|
||||
|
||||
# Log with timestamp
|
||||
log() {
|
||||
echo "[$(date '+%Y-%m-%d %H:%M:%S')] $*" >> "$LOG_FILE"
|
||||
}
|
||||
|
||||
input=$(cat)
|
||||
log "Received input: ${input:0:100}..."
|
||||
|
||||
# Hook logic here
|
||||
|
||||
log "Hook completed successfully"
|
||||
# Always output valid JSON to stdout at the end, even if just empty
|
||||
echo "{}"
|
||||
|
||||
```
|
||||
|
||||
### Use stderr for errors
|
||||
|
||||
Error messages on stderr are surfaced appropriately based on exit codes:
|
||||
|
||||
```javascript
|
||||
try {
|
||||
const result = dangerousOperation();
|
||||
console.log(JSON.stringify({ result }));
|
||||
} catch (error) {
|
||||
// Write the error description to stderr so the user/agent sees it
|
||||
console.error(`Hook error: ${error.message}`);
|
||||
process.exit(2); // Blocking error
|
||||
}
|
||||
```
|
||||
|
||||
### Test hooks independently
|
||||
|
||||
Run hook scripts manually with sample JSON input to verify they behave as
|
||||
expected before hooking them up to the CLI.
|
||||
|
||||
**macOS/Linux**
|
||||
|
||||
```bash
|
||||
# Create test input
|
||||
cat > test-input.json << 'EOF'
|
||||
{
|
||||
"session_id": "test-123",
|
||||
"cwd": "/tmp/test",
|
||||
"hook_event_name": "BeforeTool",
|
||||
"tool_name": "write_file",
|
||||
"tool_input": {
|
||||
"file_path": "test.txt",
|
||||
"content": "Test content"
|
||||
}
|
||||
}
|
||||
EOF
|
||||
|
||||
# Test the hook
|
||||
cat test-input.json | .gemini/hooks/my-hook.sh
|
||||
|
||||
# Check exit code
|
||||
echo "Exit code: $?"
|
||||
```
|
||||
|
||||
**Windows (PowerShell)**
|
||||
|
||||
```powershell
|
||||
# Create test input
|
||||
@"
|
||||
{
|
||||
"session_id": "test-123",
|
||||
"cwd": "C:\\temp\\test",
|
||||
"hook_event_name": "BeforeTool",
|
||||
"tool_name": "write_file",
|
||||
"tool_input": {
|
||||
"file_path": "test.txt",
|
||||
"content": "Test content"
|
||||
}
|
||||
}
|
||||
"@ | Out-File -FilePath test-input.json -Encoding utf8
|
||||
|
||||
# Test the hook
|
||||
Get-Content test-input.json | .\.gemini\hooks\my-hook.ps1
|
||||
|
||||
# Check exit code
|
||||
Write-Host "Exit code: $LASTEXITCODE"
|
||||
```
|
||||
|
||||
### Check exit codes
|
||||
|
||||
Gemini CLI uses exit codes for high-level flow control:
|
||||
|
||||
- **Exit 0 (Success)**: The hook ran successfully. The CLI parses `stdout` for
|
||||
JSON decisions.
|
||||
- **Exit 2 (System Block)**: A critical block occurred. `stderr` is used as the
|
||||
reason.
|
||||
- For **Agent/Model** events, this aborts the turn.
|
||||
- For **Tool** events, this blocks the tool but allows the agent to continue.
|
||||
- For **AfterAgent**, this triggers an automatic retry turn.
|
||||
|
||||
> **TIP**
|
||||
>
|
||||
> **Blocking vs. Stopping**: Use `decision: "deny"` (or Exit Code 2) to block a
|
||||
> **specific action**. Use `{"continue": false}` in your JSON output to **kill
|
||||
> the entire agent loop** immediately.
|
||||
|
||||
```bash
|
||||
#!/usr/bin/env bash
|
||||
set -e
|
||||
|
||||
# Hook logic
|
||||
if process_input; then
|
||||
echo '{"decision": "allow"}'
|
||||
exit 0
|
||||
else
|
||||
echo "Critical validation failure" >&2
|
||||
exit 2
|
||||
fi
|
||||
|
||||
```
|
||||
|
||||
### Enable telemetry
|
||||
|
||||
Hook execution is logged when `telemetry.logPrompts` is enabled. You can view
|
||||
these logs to debug execution flow.
|
||||
|
||||
```json
|
||||
{
|
||||
"telemetry": {
|
||||
"logPrompts": true
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
### Use hook panel
|
||||
|
||||
The `/hooks panel` command inside the CLI shows execution status and recent
|
||||
output:
|
||||
|
||||
```bash
|
||||
/hooks panel
|
||||
```
|
||||
|
||||
Check for:
|
||||
|
||||
- Hook execution counts
|
||||
- Recent successes/failures
|
||||
- Error messages
|
||||
- Execution timing
|
||||
|
||||
## Development
|
||||
|
||||
### Start simple
|
||||
|
||||
Begin with basic logging hooks before implementing complex logic:
|
||||
|
||||
```bash
|
||||
#!/usr/bin/env bash
|
||||
# Simple logging hook to understand input structure
|
||||
input=$(cat)
|
||||
echo "$input" >> .gemini/hook-inputs.log
|
||||
# Always return valid JSON
|
||||
echo "{}"
|
||||
|
||||
```
|
||||
|
||||
### Documenting your hooks
|
||||
|
||||
Maintainability is critical for complex hook systems. Use descriptions and
|
||||
comments to help yourself and others understand why a hook exists.
|
||||
|
||||
**Use the `description` field**: This text is displayed in the `/hooks panel` UI
|
||||
and helps diagnose issues.
|
||||
|
||||
```json
|
||||
{
|
||||
"hooks": {
|
||||
"BeforeTool": [
|
||||
{
|
||||
"matcher": "write_file|replace",
|
||||
"hooks": [
|
||||
{
|
||||
"name": "secret-scanner",
|
||||
"type": "command",
|
||||
"command": "$GEMINI_PROJECT_DIR/.gemini/hooks/block-secrets.sh",
|
||||
"description": "Scans code changes for API keys and secrets before writing"
|
||||
}
|
||||
]
|
||||
}
|
||||
]
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
**Add comments in hook scripts**: Explain performance expectations and
|
||||
dependencies.
|
||||
|
||||
```javascript
|
||||
#!/usr/bin/env node
|
||||
/**
|
||||
* RAG Tool Filter Hook
|
||||
*
|
||||
* Reduces the tool space by extracting keywords from the user's request.
|
||||
*
|
||||
* Performance: ~500ms average
|
||||
* Dependencies: @google/generative-ai
|
||||
*/
|
||||
```
|
||||
|
||||
### Use JSON libraries
|
||||
|
||||
Parse JSON with proper libraries instead of text processing.
|
||||
|
||||
**Bad:**
|
||||
|
||||
```bash
|
||||
# Fragile text parsing
|
||||
tool_name=$(echo "$input" | grep -oP '"tool_name":\s*"\K[^"]+')
|
||||
|
||||
```
|
||||
|
||||
**Good:**
|
||||
|
||||
```bash
|
||||
# Robust JSON parsing
|
||||
tool_name=$(echo "$input" | jq -r '.tool_name')
|
||||
|
||||
```
|
||||
|
||||
### Make scripts executable
|
||||
|
||||
Always make hook scripts executable on macOS/Linux:
|
||||
|
||||
```bash
|
||||
chmod +x .gemini/hooks/*.sh
|
||||
chmod +x .gemini/hooks/*.js
|
||||
|
||||
```
|
||||
|
||||
**Windows Note**: On Windows, PowerShell scripts (`.ps1`) don't use `chmod`, but
|
||||
you may need to ensure your execution policy allows them to run (for example,
|
||||
`Set-ExecutionPolicy RemoteSigned -Scope CurrentUser`).
|
||||
|
||||
### Version control
|
||||
|
||||
Commit hooks to share with your team:
|
||||
|
||||
```bash
|
||||
git add .gemini/hooks/
|
||||
git add .gemini/settings.json
|
||||
|
||||
```
|
||||
|
||||
**`.gitignore` considerations:**
|
||||
|
||||
```gitignore
|
||||
# Ignore hook cache and logs
|
||||
.gemini/hook-cache.json
|
||||
.gemini/hook-debug.log
|
||||
.gemini/memory/session-*.jsonl
|
||||
|
||||
# Keep hook scripts
|
||||
!.gemini/hooks/*.sh
|
||||
!.gemini/hooks/*.js
|
||||
|
||||
```
|
||||
|
||||
## Hook security
|
||||
|
||||
### Threat Model
|
||||
|
||||
Understanding where hooks come from and what they can do is critical for secure
|
||||
usage.
|
||||
|
||||
| Hook Source | Description |
|
||||
| :---------------------------- | :-------------------------------------------------------------------------------------------------------------------------------- |
|
||||
| **System** | Configured by system administrators (for example, `/etc/gemini-cli/settings.json`, `/Library/...`). Assumed to be the **safest**. |
|
||||
| **User** (`~/.gemini/...`) | Configured by you. You are responsible for ensuring they are safe. |
|
||||
| **Extensions** | You explicitly approve and install these. Security depends on the extension source (integrity). |
|
||||
| **Project** (`./.gemini/...`) | **Untrusted by default.** Safest in trusted internal repos; higher risk in third-party/public repos. |
|
||||
|
||||
#### Project Hook Security
|
||||
|
||||
When you open a project with hooks defined in `.gemini/settings.json`:
|
||||
|
||||
1. **Detection**: Gemini CLI detects the hooks.
|
||||
2. **Identification**: A unique identity is generated for each hook based on its
|
||||
`name` and `command`.
|
||||
3. **Warning**: If this specific hook identity has not been seen before, a
|
||||
**warning** is displayed.
|
||||
4. **Execution**: The hook is executed (unless specific security settings block
|
||||
it).
|
||||
5. **Trust**: The hook is marked as "trusted" for this project.
|
||||
|
||||
> **Modification detection**: If the `command` string of a project hook is
|
||||
> changed (for example, by a `git pull`), its identity changes. Gemini CLI will
|
||||
> treat it as a **new, untrusted hook** and warn you again. This prevents
|
||||
> malicious actors from silently swapping a verified command for a malicious
|
||||
> one.
|
||||
|
||||
### Risks
|
||||
|
||||
| Risk | Description |
|
||||
| :--------------------------- | :----------------------------------------------------------------------------------------------------------------------------------- |
|
||||
| **Arbitrary Code Execution** | Hooks run as your user. They can do anything you can do (delete files, install software). |
|
||||
| **Data Exfiltration** | A hook could read your input (prompts), output (code), or environment variables (`GEMINI_API_KEY`) and send them to a remote server. |
|
||||
| **Prompt Injection** | Malicious content in a file or web page could trick an LLM into running a tool that triggers a hook in an unexpected way. |
|
||||
|
||||
### Mitigation Strategies
|
||||
|
||||
#### Verify the source
|
||||
|
||||
**Verify the source** of any project hooks or extensions before enabling them.
|
||||
|
||||
- For open-source projects, a quick review of the hook scripts is recommended.
|
||||
- For extensions, ensure you trust the author or publisher (for example,
|
||||
verified publishers, well-known community members).
|
||||
- Be cautious with obfuscated scripts or compiled binaries from unknown sources.
|
||||
|
||||
#### Sanitize environment
|
||||
|
||||
Hooks inherit the environment of Gemini CLI process, which may include sensitive
|
||||
API keys. Gemini CLI provides a
|
||||
[redaction system](../reference/configuration.md#environment-variable-redaction)
|
||||
that automatically filters variables matching sensitive patterns (for example,
|
||||
`KEY`, `TOKEN`).
|
||||
|
||||
> **Disabled by Default**: Environment redaction is currently **OFF by
|
||||
> default**. We strongly recommend enabling it if you are running third-party
|
||||
> hooks or working in sensitive environments.
|
||||
|
||||
**Impact on hooks:**
|
||||
|
||||
- **Security**: Prevents your hook scripts from accidentally leaking secrets.
|
||||
- **Troubleshooting**: If your hook depends on a specific environment variable
|
||||
that is being blocked, you must explicitly allow it in `settings.json`.
|
||||
|
||||
```json
|
||||
{
|
||||
"security": {
|
||||
"environmentVariableRedaction": {
|
||||
"enabled": true,
|
||||
"allowed": ["MY_REQUIRED_TOOL_KEY"]
|
||||
}
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
**System administrators:** You can enforce redaction for all users in the system
|
||||
configuration.
|
||||
|
||||
## Troubleshooting
|
||||
|
||||
### Hook not executing
|
||||
|
||||
**Check hook name in `/hooks panel`:** Verify the hook appears in the list and
|
||||
is enabled.
|
||||
|
||||
**Verify matcher pattern:**
|
||||
|
||||
```bash
|
||||
# Test regex pattern
|
||||
echo "write_file|replace" | grep -E "write_.*|replace"
|
||||
|
||||
```
|
||||
|
||||
**Check disabled list:** Verify the hook is not listed in your `settings.json`:
|
||||
|
||||
```json
|
||||
{
|
||||
"hooks": {
|
||||
"disabled": ["my-hook-name"]
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
**Ensure script is executable**: For macOS and Linux users, verify the script
|
||||
has execution permissions:
|
||||
|
||||
```bash
|
||||
ls -la .gemini/hooks/my-hook.sh
|
||||
chmod +x .gemini/hooks/my-hook.sh
|
||||
```
|
||||
|
||||
**Windows Note**: On Windows, ensure your execution policy allows running
|
||||
scripts (for example, `Get-ExecutionPolicy`).
|
||||
|
||||
**Verify script path:** Ensure the path in `settings.json` resolves correctly.
|
||||
|
||||
```bash
|
||||
# Check path expansion
|
||||
echo "$GEMINI_PROJECT_DIR/.gemini/hooks/my-hook.sh"
|
||||
|
||||
# Verify file exists
|
||||
test -f "$GEMINI_PROJECT_DIR/.gemini/hooks/my-hook.sh" && echo "File exists"
|
||||
```
|
||||
|
||||
### Hook timing out
|
||||
|
||||
**Check configured timeout:** The default is 60000ms (1 minute). You can
|
||||
increase this in `settings.json`:
|
||||
|
||||
```json
|
||||
{
|
||||
"name": "slow-hook",
|
||||
"timeout": 120000
|
||||
}
|
||||
```
|
||||
|
||||
**Optimize slow operations:** Move heavy processing to background tasks or use
|
||||
caching.
|
||||
|
||||
### Invalid JSON output
|
||||
|
||||
**Validate JSON before outputting:**
|
||||
|
||||
```bash
|
||||
#!/usr/bin/env bash
|
||||
output='{"decision": "allow"}'
|
||||
|
||||
# Validate JSON
|
||||
if echo "$output" | jq empty 2>/dev/null; then
|
||||
echo "$output"
|
||||
else
|
||||
echo "Invalid JSON generated" >&2
|
||||
exit 1
|
||||
fi
|
||||
|
||||
```
|
||||
|
||||
### Environment variables not available
|
||||
|
||||
**Check if variable is set:**
|
||||
|
||||
```bash
|
||||
#!/usr/bin/env bash
|
||||
if [ -z "$GEMINI_PROJECT_DIR" ]; then
|
||||
echo "GEMINI_PROJECT_DIR not set" >&2
|
||||
exit 1
|
||||
fi
|
||||
|
||||
```
|
||||
|
||||
**Debug available variables:**
|
||||
|
||||
```bash
|
||||
env > .gemini/hook-env.log
|
||||
```
|
||||
|
||||
## Authoring secure hooks
|
||||
|
||||
When writing your own hooks, follow these practices to ensure they are robust
|
||||
and secure.
|
||||
|
||||
### Validate all inputs
|
||||
|
||||
Never trust data from hooks without validation. Hook inputs often come from the
|
||||
LLM or user prompts, which can be manipulated.
|
||||
|
||||
```bash
|
||||
#!/usr/bin/env bash
|
||||
input=$(cat)
|
||||
|
||||
# Validate JSON structure
|
||||
if ! echo "$input" | jq empty 2>/dev/null; then
|
||||
echo "Invalid JSON input" >&2
|
||||
exit 1
|
||||
fi
|
||||
|
||||
# Validate tool_name explicitly
|
||||
tool_name=$(echo "$input" | jq -r '.tool_name // empty')
|
||||
if [[ "$tool_name" != "write_file" && "$tool_name" != "read_file" ]]; then
|
||||
echo "Unexpected tool: $tool_name" >&2
|
||||
exit 1
|
||||
fi
|
||||
```
|
||||
|
||||
### Use timeouts
|
||||
|
||||
Prevent denial-of-service (hanging agents) by enforcing timeouts. Gemini CLI
|
||||
defaults to 60 seconds, but you should set stricter limits for fast hooks.
|
||||
|
||||
```json
|
||||
{
|
||||
"hooks": {
|
||||
"BeforeTool": [
|
||||
{
|
||||
"matcher": "*",
|
||||
"hooks": [
|
||||
{
|
||||
"name": "fast-validator",
|
||||
"type": "command",
|
||||
"command": "./hooks/validate.sh",
|
||||
"timeout": 5000 // 5 seconds
|
||||
}
|
||||
]
|
||||
}
|
||||
]
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
### Limit permissions
|
||||
|
||||
Run hooks with minimal required permissions:
|
||||
|
||||
```bash
|
||||
#!/usr/bin/env bash
|
||||
# Don't run as root
|
||||
if [ "$EUID" -eq 0 ]; then
|
||||
echo "Hook should not run as root" >&2
|
||||
exit 1
|
||||
fi
|
||||
|
||||
# Check file permissions before writing
|
||||
if [ -w "$file_path" ]; then
|
||||
# Safe to write
|
||||
else
|
||||
echo "Insufficient permissions" >&2
|
||||
exit 1
|
||||
fi
|
||||
```
|
||||
|
||||
### Example: Secret Scanner
|
||||
|
||||
Use `BeforeTool` hooks to prevent committing sensitive data. This is a powerful
|
||||
pattern for enhancing security in your workflow.
|
||||
|
||||
```javascript
|
||||
const SECRET_PATTERNS = [
|
||||
/api[_-]?key\s*[:=]\s*['"]?[a-zA-Z0-9_-]{20,}['"]?/i,
|
||||
/password\s*[:=]\s*['"]?[^\s'"]{8,}['"]?/i,
|
||||
/secret\s*[:=]\s*['"]?[a-zA-Z0-9_-]{20,}['"]?/i,
|
||||
/AKIA[0-9A-Z]{16}/, // AWS access key
|
||||
/ghp_[a-zA-Z0-9]{36}/, // GitHub personal access token
|
||||
/sk-[a-zA-Z0-9]{48}/, // OpenAI API key
|
||||
];
|
||||
|
||||
function containsSecret(content) {
|
||||
return SECRET_PATTERNS.some((pattern) => pattern.test(content));
|
||||
}
|
||||
```
|
||||
|
||||
## Privacy considerations
|
||||
|
||||
Hook inputs and outputs may contain sensitive information.
|
||||
|
||||
### What data is collected
|
||||
|
||||
Hook telemetry may include inputs (prompts, code) and outputs (decisions,
|
||||
reasons) unless disabled.
|
||||
|
||||
### Privacy settings
|
||||
|
||||
**Disable PII logging:** If you are working with sensitive data, disable prompt
|
||||
logging in your settings:
|
||||
|
||||
```json
|
||||
{
|
||||
"telemetry": {
|
||||
"logPrompts": false
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
**Suppress Output:** Individual hooks can request their metadata be hidden from
|
||||
logs and telemetry by returning `"suppressOutput": true` in their JSON response.
|
||||
|
||||
> **Note**
|
||||
|
||||
> `suppressOutput` only affects background logging. Any `systemMessage` or
|
||||
> `reason` included in the JSON will still be displayed to the user in the
|
||||
> terminal.
|
||||
|
||||
### Sensitive data in hooks
|
||||
|
||||
If your hooks process sensitive data:
|
||||
|
||||
1. **Minimize logging:** Don't write sensitive data to log files.
|
||||
2. **Sanitize outputs:** Remove sensitive data before outputting JSON or writing
|
||||
to stderr.
|
||||
@@ -0,0 +1,168 @@
|
||||
# Gemini CLI hooks
|
||||
|
||||
Hooks are scripts or programs that Gemini CLI executes at specific points in the
|
||||
agentic loop, allowing you to intercept and customize behavior without modifying
|
||||
the CLI's source code.
|
||||
|
||||
## What are hooks?
|
||||
|
||||
Hooks run synchronously as part of the agent loop—when a hook event fires,
|
||||
Gemini CLI waits for all matching hooks to complete before continuing.
|
||||
|
||||
With hooks, you can:
|
||||
|
||||
- **Add context:** Inject relevant information (like git history) before the
|
||||
model processes a request.
|
||||
- **Validate actions:** Review tool arguments and block potentially dangerous
|
||||
operations.
|
||||
- **Enforce policies:** Implement security scanners and compliance checks.
|
||||
- **Log interactions:** Track tool usage and model responses for auditing.
|
||||
- **Optimize behavior:** Dynamically filter available tools or adjust model
|
||||
parameters.
|
||||
|
||||
### Getting started
|
||||
|
||||
- **[Writing hooks guide](../hooks/writing-hooks.md)**: A tutorial on creating
|
||||
your first hook with comprehensive examples.
|
||||
- **[Best practices](../hooks/best-practices.md)**: Guidelines on security,
|
||||
performance, and debugging.
|
||||
- **[Hooks reference](../hooks/reference.md)**: The definitive technical
|
||||
specification of I/O schemas and exit codes.
|
||||
|
||||
## Core concepts
|
||||
|
||||
### Hook events
|
||||
|
||||
Hooks are triggered by specific events in Gemini CLI's lifecycle.
|
||||
|
||||
| Event | When It Fires | Impact | Common Use Cases |
|
||||
| --------------------- | ---------------------------------------------- | ---------------------- | -------------------------------------------- |
|
||||
| `SessionStart` | When a session begins (startup, resume, clear) | Inject Context | Initialize resources, load context |
|
||||
| `SessionEnd` | When a session ends (exit, clear) | Advisory | Clean up, save state |
|
||||
| `BeforeAgent` | After user submits prompt, before planning | Block Turn / Context | Add context, validate prompts, block turns |
|
||||
| `AfterAgent` | When agent loop ends | Retry / Halt | Review output, force retry or halt execution |
|
||||
| `BeforeModel` | Before sending request to LLM | Block Turn / Mock | Modify prompts, swap models, mock responses |
|
||||
| `AfterModel` | After receiving LLM response | Block Turn / Redact | Filter/redact responses, log interactions |
|
||||
| `BeforeToolSelection` | Before LLM selects tools | Filter Tools | Filter available tools, optimize selection |
|
||||
| `BeforeTool` | Before a tool executes | Block Tool / Rewrite | Validate arguments, block dangerous ops |
|
||||
| `AfterTool` | After a tool executes | Block Result / Context | Process results, run tests, hide results |
|
||||
| `PreCompress` | Before context compression | Advisory | Save state, notify user |
|
||||
| `Notification` | When a system notification occurs | Advisory | Forward to desktop alerts, logging |
|
||||
|
||||
### Global mechanics
|
||||
|
||||
Understanding these core principles is essential for building robust hooks.
|
||||
|
||||
#### Strict JSON requirements (The "Golden Rule")
|
||||
|
||||
Hooks communicate via `stdin` (Input) and `stdout` (Output).
|
||||
|
||||
1. **Silence is Mandatory**: Your script **must not** print any plain text to
|
||||
`stdout` other than the final JSON object. **Even a single `echo` or `print`
|
||||
call before the JSON will break parsing.**
|
||||
2. **Pollution = Failure**: If `stdout` contains non-JSON text, parsing will
|
||||
fail. The CLI will default to "Allow" and treat the entire output as a
|
||||
`systemMessage`.
|
||||
3. **Debug via Stderr**: Use `stderr` for **all** logging and debugging (for
|
||||
example, `echo "debug" >&2`). Gemini CLI captures `stderr` but never attempts
|
||||
to parse it as JSON.
|
||||
|
||||
#### Exit codes
|
||||
|
||||
Gemini CLI uses exit codes to determine the high-level outcome of a hook
|
||||
execution:
|
||||
|
||||
| Exit Code | Label | Behavioral Impact |
|
||||
| --------- | ---------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
|
||||
| **0** | **Success** | The `stdout` is parsed as JSON. **Preferred code** for all logic, including intentional blocks (for example, `{"decision": "deny"}`). |
|
||||
| **2** | **System Block** | **Critical Block**. The target action (tool, turn, or stop) is aborted. `stderr` is used as the rejection reason. High severity; used for security stops or script failures. |
|
||||
| **Other** | **Warning** | Non-fatal failure. A warning is shown, but the interaction proceeds using original parameters. |
|
||||
|
||||
#### Matchers
|
||||
|
||||
You can filter which specific tools or triggers fire your hook using the
|
||||
`matcher` field.
|
||||
|
||||
- **Tool events** (`BeforeTool`, `AfterTool`): Matchers are **Regular
|
||||
Expressions**. (for example, `"write_.*"`).
|
||||
- **Lifecycle events**: Matchers are **Exact Strings**. (for example,
|
||||
`"startup"`).
|
||||
- **Wildcards**: `"*"` or `""` (empty string) matches all occurrences.
|
||||
|
||||
## Configuration
|
||||
|
||||
Hooks are configured in `settings.json`. Gemini CLI merges configurations from
|
||||
multiple layers in the following order of precedence (highest to lowest):
|
||||
|
||||
1. **Project settings**: `.gemini/settings.json` in the current directory.
|
||||
2. **User settings**: `~/.gemini/settings.json`.
|
||||
3. **System settings**: `/etc/gemini-cli/settings.json`.
|
||||
4. **Extensions**: Hooks defined by installed extensions.
|
||||
|
||||
### Configuration schema
|
||||
|
||||
```json
|
||||
{
|
||||
"hooks": {
|
||||
"BeforeTool": [
|
||||
{
|
||||
"matcher": "write_file|replace",
|
||||
"hooks": [
|
||||
{
|
||||
"name": "security-check",
|
||||
"type": "command",
|
||||
"command": "$GEMINI_PROJECT_DIR/.gemini/hooks/security.sh",
|
||||
"timeout": 5000
|
||||
}
|
||||
]
|
||||
}
|
||||
]
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
#### Hook configuration fields
|
||||
|
||||
| Field | Type | Required | Description |
|
||||
| :------------ | :----- | :-------- | :------------------------------------------------------------------- |
|
||||
| `type` | string | **Yes** | The execution engine. Currently only `"command"` is supported. |
|
||||
| `command` | string | **Yes\*** | The shell command to execute. (Required when `type` is `"command"`). |
|
||||
| `name` | string | No | A friendly name for identifying the hook in logs and CLI commands. |
|
||||
| `timeout` | number | No | Execution timeout in milliseconds (default: 60000). |
|
||||
| `description` | string | No | A brief explanation of the hook's purpose. |
|
||||
|
||||
---
|
||||
|
||||
### Environment variables
|
||||
|
||||
Hooks are executed with a sanitized environment.
|
||||
|
||||
- `GEMINI_PROJECT_DIR`: The absolute path to the project root.
|
||||
- `GEMINI_PLANS_DIR`: The absolute path to the plans directory.
|
||||
- `GEMINI_SESSION_ID`: The unique ID for the current session.
|
||||
- `GEMINI_CWD`: The current working directory.
|
||||
- `CLAUDE_PROJECT_DIR`: (Alias) Provided for compatibility.
|
||||
|
||||
## Security and risks
|
||||
|
||||
<!-- prettier-ignore -->
|
||||
> [!WARNING]
|
||||
> Hooks execute arbitrary code with your user privileges. By
|
||||
> configuring hooks, you are allowing scripts to run shell commands on your
|
||||
> machine.
|
||||
|
||||
**Project-level hooks** are particularly risky when opening untrusted projects.
|
||||
Gemini CLI **fingerprints** project hooks. If a hook's name or command changes
|
||||
(for example, via `git pull`), it is treated as a **new, untrusted hook** and
|
||||
you will be warned before it executes.
|
||||
|
||||
See [Security Considerations](../hooks/best-practices.md#using-hooks-securely)
|
||||
for a detailed threat model.
|
||||
|
||||
## Managing hooks
|
||||
|
||||
Use the CLI commands to manage hooks without editing JSON manually:
|
||||
|
||||
- **View hooks:** `/hooks panel`
|
||||
- **Enable/Disable all:** `/hooks enable-all` or `/hooks disable-all`
|
||||
- **Toggle individual:** `/hooks enable <name>` or `/hooks disable <name>`
|
||||
@@ -0,0 +1,330 @@
|
||||
# Hooks reference
|
||||
|
||||
This document provides the technical specification for Gemini CLI hooks,
|
||||
including JSON schemas and API details.
|
||||
|
||||
## Global hook mechanics
|
||||
|
||||
- **Communication**: `stdin` for Input (JSON), `stdout` for Output (JSON), and
|
||||
`stderr` for logs and feedback.
|
||||
- **Exit codes**:
|
||||
- `0`: Success. `stdout` is parsed as JSON. **Preferred for all logic.**
|
||||
- `2`: System Block. The action is blocked; `stderr` is used as the rejection
|
||||
reason.
|
||||
- `Other`: Warning. A non-fatal failure occurred; the CLI continues with a
|
||||
warning.
|
||||
- **Silence is Mandatory**: Your script **must not** print any plain text to
|
||||
`stdout` other than the final JSON.
|
||||
|
||||
---
|
||||
|
||||
## Configuration schema
|
||||
|
||||
Hooks are defined in `settings.json` within the `hooks` object. Each event (for
|
||||
example, `BeforeTool`) contains an array of **hook definitions**.
|
||||
|
||||
### Hook definition
|
||||
|
||||
| Field | Type | Required | Description |
|
||||
| :----------- | :-------- | :------- | :-------------------------------------------------------------------------------------- |
|
||||
| `matcher` | `string` | No | A regex (for tools) or exact string (for lifecycle) to filter when the hook runs. |
|
||||
| `sequential` | `boolean` | No | If `true`, hooks in this group run one after another. If `false`, they run in parallel. |
|
||||
| `hooks` | `array` | **Yes** | An array of **hook configurations**. |
|
||||
|
||||
### Hook configuration
|
||||
|
||||
| Field | Type | Required | Description |
|
||||
| :------------ | :------- | :-------- | :------------------------------------------------------------------- |
|
||||
| `type` | `string` | **Yes** | The execution engine. Currently only `"command"` is supported. |
|
||||
| `command` | `string` | **Yes\*** | The shell command to execute. (Required when `type` is `"command"`). |
|
||||
| `name` | `string` | No | A friendly name for identifying the hook in logs and CLI commands. |
|
||||
| `timeout` | `number` | No | Execution timeout in milliseconds (default: 60000). |
|
||||
| `description` | `string` | No | A brief explanation of the hook's purpose. |
|
||||
|
||||
---
|
||||
|
||||
## Base input schema
|
||||
|
||||
All hooks receive these common fields via `stdin`:
|
||||
|
||||
```typescript
|
||||
{
|
||||
"session_id": string, // Unique ID for the current session
|
||||
"transcript_path": string, // Absolute path to session transcript JSON
|
||||
"cwd": string, // Current working directory
|
||||
"hook_event_name": string, // The firing event (for example "BeforeTool")
|
||||
"timestamp": string // ISO 8601 execution time
|
||||
}
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Common output fields
|
||||
|
||||
Most hooks support these fields in their `stdout` JSON:
|
||||
|
||||
| Field | Type | Description |
|
||||
| :--------------- | :-------- | :----------------------------------------------------------------------------- |
|
||||
| `systemMessage` | `string` | Displayed immediately to the user in the terminal. |
|
||||
| `suppressOutput` | `boolean` | If `true`, hides internal hook metadata from logs/telemetry. |
|
||||
| `continue` | `boolean` | If `false`, stops the entire agent loop immediately. |
|
||||
| `stopReason` | `string` | Displayed to the user when `continue` is `false`. |
|
||||
| `decision` | `string` | `"allow"` or `"deny"` (alias `"block"`). Specific impact depends on the event. |
|
||||
| `reason` | `string` | The feedback/error message provided when a `decision` is `"deny"`. |
|
||||
|
||||
---
|
||||
|
||||
## Tool hooks
|
||||
|
||||
### Matchers and tool names
|
||||
|
||||
For `BeforeTool` and `AfterTool` events, the `matcher` field in your settings is
|
||||
compared against the name of the tool being executed.
|
||||
|
||||
- **Built-in Tools**: You can match any built-in tool (for example, `read_file`,
|
||||
`run_shell_command`). See the [Tools Reference](../reference/tools) for a full
|
||||
list of available tool names.
|
||||
- **MCP Tools**: Tools from MCP servers follow the naming pattern
|
||||
`mcp_<server_name>_<tool_name>`.
|
||||
- **Regex Support**: Matchers support regular expressions (for example,
|
||||
`matcher: "read_.*"` matches all file reading tools).
|
||||
|
||||
### `BeforeTool`
|
||||
|
||||
Fires before a tool is invoked. Used for argument validation, security checks,
|
||||
and parameter rewriting.
|
||||
|
||||
- **Input Fields**:
|
||||
- `tool_name`: (`string`) The name of the tool being called.
|
||||
- `tool_input`: (`object`) The raw arguments generated by the model.
|
||||
- `mcp_context`: (`object`) Optional metadata for MCP-based tools.
|
||||
- `original_request_name`: (`string`) The original name of the tool being
|
||||
called, if this is a tail tool call.
|
||||
- **Relevant Output Fields**:
|
||||
- `decision`: Set to `"deny"` (or `"block"`) to prevent the tool from
|
||||
executing.
|
||||
- `reason`: Required if denied. This text is sent **to the agent** as a tool
|
||||
error, allowing it to respond or retry.
|
||||
- `hookSpecificOutput.tool_input`: An object that **merges with and
|
||||
overrides** the model's arguments before execution.
|
||||
- `continue`: Set to `false` to **kill the entire agent loop** immediately.
|
||||
- **Exit Code 2 (Block Tool)**: Prevents execution. Uses `stderr` as the
|
||||
`reason` sent to the agent. **The turn continues.**
|
||||
|
||||
### `AfterTool`
|
||||
|
||||
Fires after a tool executes. Used for result auditing, context injection, or
|
||||
hiding sensitive output from the agent.
|
||||
|
||||
- **Input Fields**:
|
||||
- `tool_name`: (`string`)
|
||||
- `tool_input`: (`object`) The original arguments.
|
||||
- `tool_response`: (`object`) The result containing `llmContent`,
|
||||
`returnDisplay`, and optional `error`.
|
||||
- `mcp_context`: (`object`)
|
||||
- `original_request_name`: (`string`) The original name of the tool being
|
||||
called, if this is a tail tool call.
|
||||
- **Relevant Output Fields**:
|
||||
- `decision`: Set to `"deny"` to hide the real tool output from the agent.
|
||||
- `reason`: Required if denied. This text **replaces** the tool result sent
|
||||
back to the model.
|
||||
- `hookSpecificOutput.additionalContext`: Text that is **appended** to the
|
||||
tool result for the agent.
|
||||
- `hookSpecificOutput.tailToolCallRequest`: (`{ name: string, args: object }`)
|
||||
A request to execute another tool immediately after this one. The result of
|
||||
this "tail call" will replace the original tool's response. Ideal for
|
||||
programmatic tool routing.
|
||||
- `continue`: Set to `false` to **kill the entire agent loop** immediately.
|
||||
- **Exit Code 2 (Block Result)**: Hides the tool result. Uses `stderr` as the
|
||||
replacement content sent to the agent. **The turn continues.**
|
||||
|
||||
---
|
||||
|
||||
## Agent hooks
|
||||
|
||||
### `BeforeAgent`
|
||||
|
||||
Fires after a user submits a prompt, but before the agent begins planning. Used
|
||||
for prompt validation or injecting dynamic context.
|
||||
|
||||
- **Input Fields**:
|
||||
- `prompt`: (`string`) The original text submitted by the user.
|
||||
- **Relevant Output Fields**:
|
||||
- `hookSpecificOutput.additionalContext`: Text that is **appended** to the
|
||||
prompt for this turn only.
|
||||
- `decision`: Set to `"deny"` to block the turn and **discard the user's
|
||||
message** (it will not appear in history).
|
||||
- `continue`: Set to `false` to block the turn but **save the message to
|
||||
history**.
|
||||
- `reason`: Required if denied or stopped.
|
||||
- **Exit Code 2 (Block Turn)**: Aborts the turn and erases the prompt from
|
||||
context. Same as `decision: "deny"`.
|
||||
|
||||
### `AfterAgent`
|
||||
|
||||
Fires once per turn after the model generates its final response. Primary use
|
||||
case is response validation and automatic retries.
|
||||
|
||||
- **Input Fields**:
|
||||
- `prompt`: (`string`) The user's original request.
|
||||
- `prompt_response`: (`string`) The final text generated by the agent.
|
||||
- `stop_hook_active`: (`boolean`) Indicates if this hook is already running as
|
||||
part of a retry sequence.
|
||||
- **Relevant Output Fields**:
|
||||
- `decision`: Set to `"deny"` to **reject the response** and force a retry.
|
||||
- `reason`: Required if denied. This text is sent **to the agent as a new
|
||||
prompt** to request a correction.
|
||||
- `continue`: Set to `false` to **stop the session** without retrying.
|
||||
- `hookSpecificOutput.clearContext`: If `true`, clears conversation history
|
||||
(LLM memory) while preserving UI display.
|
||||
- **Exit Code 2 (Retry)**: Rejects the response and triggers an automatic retry
|
||||
turn using `stderr` as the feedback prompt.
|
||||
|
||||
---
|
||||
|
||||
## Model hooks
|
||||
|
||||
### `BeforeModel`
|
||||
|
||||
Fires before sending a request to the LLM. Operates on a stable, SDK-agnostic
|
||||
request format.
|
||||
|
||||
- **Input Fields**:
|
||||
- `llm_request`: (`object`) Contains `model`, `messages`, and `config`
|
||||
(generation params).
|
||||
- **Relevant Output Fields**:
|
||||
- `hookSpecificOutput.llm_request`: An object that **overrides** parts of the
|
||||
outgoing request (for example, changing models or temperature).
|
||||
- `hookSpecificOutput.llm_response`: A **Synthetic Response** object. If
|
||||
provided, the CLI skips the LLM call entirely and uses this as the response.
|
||||
- `decision`: Set to `"deny"` to block the request and abort the turn.
|
||||
- **Exit Code 2 (Block Turn)**: Aborts the turn and skips the LLM call. Uses
|
||||
`stderr` as the error message.
|
||||
|
||||
### `BeforeToolSelection`
|
||||
|
||||
Fires before the LLM decides which tools to call. Used to filter the available
|
||||
toolset or force specific tool modes.
|
||||
|
||||
- **Input Fields**:
|
||||
- `llm_request`: (`object`) Same format as `BeforeModel`.
|
||||
- **Relevant Output Fields**:
|
||||
- `hookSpecificOutput.toolConfig.mode`: (`"AUTO" | "ANY" | "NONE"`)
|
||||
- `"NONE"`: Disables all tools (Wins over other hooks).
|
||||
- `"ANY"`: Forces at least one tool call.
|
||||
- `hookSpecificOutput.toolConfig.allowedFunctionNames`: (`string[]`) Whitelist
|
||||
of tool names.
|
||||
- **Union Strategy**: Multiple hooks' whitelists are **combined**.
|
||||
- **Limitations**: Does **not** support `decision`, `continue`, or
|
||||
`systemMessage`.
|
||||
|
||||
### `AfterModel`
|
||||
|
||||
Fires immediately after an LLM response chunk is received. Used for real-time
|
||||
redaction or PII filtering.
|
||||
|
||||
- **Input Fields**:
|
||||
- `llm_request`: (`object`) The original request.
|
||||
- `llm_response`: (`object`) The model's response (or a single chunk during
|
||||
streaming).
|
||||
- **Relevant Output Fields**:
|
||||
- `hookSpecificOutput.llm_response`: An object that **replaces** the model's
|
||||
response chunk.
|
||||
- `decision`: Set to `"deny"` to discard the response chunk and block the
|
||||
turn.
|
||||
- `continue`: Set to `false` to **kill the entire agent loop** immediately.
|
||||
- **Note on Streaming**: Fired for **every chunk** generated by the model.
|
||||
Modifying the response only affects the current chunk.
|
||||
- **Exit Code 2 (Block Response)**: Aborts the turn and discards the model's
|
||||
output. Uses `stderr` as the error message.
|
||||
|
||||
---
|
||||
|
||||
## Lifecycle & system hooks
|
||||
|
||||
### `SessionStart`
|
||||
|
||||
Fires on application startup, resuming a session, or after a `/clear` command.
|
||||
Used for loading initial context.
|
||||
|
||||
- **Input fields**:
|
||||
- `source`: (`"startup" | "resume" | "clear"`)
|
||||
- **Relevant output fields**:
|
||||
- `hookSpecificOutput.additionalContext`: (`string`)
|
||||
- **Interactive**: Injected as the first turn in history.
|
||||
- **Non-interactive**: Prepended to the user's prompt.
|
||||
- `systemMessage`: Shown at the start of the session.
|
||||
- **Advisory only**: `continue` and `decision` fields are **ignored**. Startup
|
||||
is never blocked.
|
||||
|
||||
### `SessionEnd`
|
||||
|
||||
Fires when the CLI exits or a session is cleared. Used for cleanup or final
|
||||
telemetry.
|
||||
|
||||
- **Input Fields**:
|
||||
- `reason`: (`"exit" | "clear" | "logout" | "prompt_input_exit" | "other"`)
|
||||
- **Relevant Output Fields**:
|
||||
- `systemMessage`: Displayed to the user during shutdown.
|
||||
- **Best Effort**: The CLI **will not wait** for this hook to complete and
|
||||
ignores all flow-control fields (`continue`, `decision`).
|
||||
|
||||
### `Notification`
|
||||
|
||||
Fires when the CLI emits a system alert (for example, Tool Permissions). Used
|
||||
for external logging or cross-platform alerts.
|
||||
|
||||
- **Input Fields**:
|
||||
- `notification_type`: (`"ToolPermission"`)
|
||||
- `message`: Summary of the alert.
|
||||
- `details`: JSON object with alert-specific metadata (for example, tool name,
|
||||
file path).
|
||||
- **Relevant Output Fields**:
|
||||
- `systemMessage`: Displayed alongside the system alert.
|
||||
- **Observability Only**: This hook **cannot** block alerts or grant permissions
|
||||
automatically. Flow-control fields are ignored.
|
||||
|
||||
### `PreCompress`
|
||||
|
||||
Fires before the CLI summarizes history to save tokens. Used for logging or
|
||||
state saving.
|
||||
|
||||
- **Input Fields**:
|
||||
- `trigger`: (`"auto" | "manual"`)
|
||||
- **Relevant Output Fields**:
|
||||
- `systemMessage`: Displayed to the user before compression.
|
||||
- **Advisory Only**: Fired asynchronously. It **cannot** block or modify the
|
||||
compression process. Flow-control fields are ignored.
|
||||
|
||||
---
|
||||
|
||||
## Stable Model API
|
||||
|
||||
Gemini CLI uses these structures to ensure hooks don't break across SDK updates.
|
||||
|
||||
**LLMRequest**:
|
||||
|
||||
```typescript
|
||||
{
|
||||
"model": string,
|
||||
"messages": Array<{
|
||||
"role": "user" | "model" | "system",
|
||||
"content": string // Non-text parts are filtered out for hooks
|
||||
}>,
|
||||
"config": { "temperature": number, ... },
|
||||
"toolConfig": { "mode": string, "allowedFunctionNames": string[] }
|
||||
}
|
||||
|
||||
```
|
||||
|
||||
**LLMResponse**:
|
||||
|
||||
```typescript
|
||||
{
|
||||
"candidates": Array<{
|
||||
"content": { "role": "model", "parts": string[] },
|
||||
"finishReason": string
|
||||
}>,
|
||||
"usageMetadata": { "totalTokenCount": number }
|
||||
}
|
||||
```
|
||||
@@ -0,0 +1,474 @@
|
||||
# Writing hooks for Gemini CLI
|
||||
|
||||
This guide will walk you through creating hooks for Gemini CLI, from a simple
|
||||
logging hook to a comprehensive workflow assistant.
|
||||
|
||||
## Prerequisites
|
||||
|
||||
Before you start, make sure you have:
|
||||
|
||||
- Gemini CLI installed and configured
|
||||
- Basic understanding of shell scripting or JavaScript/Node.js
|
||||
- Familiarity with JSON for hook input/output
|
||||
|
||||
## Quick start
|
||||
|
||||
Let's create a simple hook that logs all tool executions to understand the
|
||||
basics.
|
||||
|
||||
**Crucial Rule:** Always write logs to `stderr`. Write only the final JSON to
|
||||
`stdout`.
|
||||
|
||||
### Step 1: Create your hook script
|
||||
|
||||
Create a directory for hooks and a simple logging script.
|
||||
|
||||
> **Note**:
|
||||
>
|
||||
> This example uses `jq` to parse JSON. If you don't have it installed, you can
|
||||
> perform similar logic using Node.js or Python.
|
||||
|
||||
**macOS/Linux**
|
||||
|
||||
```bash
|
||||
mkdir -p .gemini/hooks
|
||||
cat > .gemini/hooks/log-tools.sh << 'EOF'
|
||||
#!/usr/bin/env bash
|
||||
# Read hook input from stdin
|
||||
input=$(cat)
|
||||
|
||||
# Extract tool name (requires jq)
|
||||
tool_name=$(echo "$input" | jq -r '.tool_name')
|
||||
|
||||
# Log to stderr (visible in terminal if hook fails, or captured in logs)
|
||||
echo "Logging tool: $tool_name" >&2
|
||||
|
||||
# Log to file
|
||||
echo "[$(date)] Tool executed: $tool_name" >> .gemini/tool-log.txt
|
||||
|
||||
# Return success (exit 0) with empty JSON
|
||||
echo "{}"
|
||||
exit 0
|
||||
EOF
|
||||
|
||||
chmod +x .gemini/hooks/log-tools.sh
|
||||
```
|
||||
|
||||
**Windows (PowerShell)**
|
||||
|
||||
```powershell
|
||||
New-Item -ItemType Directory -Force -Path ".gemini\hooks"
|
||||
@"
|
||||
# Read hook input from stdin
|
||||
`$inputJson = `$input | Out-String | ConvertFrom-Json
|
||||
|
||||
# Extract tool name
|
||||
`$toolName = `$inputJson.tool_name
|
||||
|
||||
# Log to stderr (visible in terminal if hook fails, or captured in logs)
|
||||
[Console]::Error.WriteLine("Logging tool: `$toolName")
|
||||
|
||||
# Log to file
|
||||
"[`$(Get-Date -Format 'o')] Tool executed: `$toolName" | Out-File -FilePath ".gemini\tool-log.txt" -Append -Encoding utf8
|
||||
|
||||
# Return success with empty JSON
|
||||
"{}"
|
||||
"@ | Out-File -FilePath ".gemini\hooks\log-tools.ps1" -Encoding utf8
|
||||
```
|
||||
|
||||
## Exit Code Strategies
|
||||
|
||||
There are two ways to control or block an action in Gemini CLI:
|
||||
|
||||
| Strategy | Exit Code | Implementation | Best For |
|
||||
| :------------------------- | :-------- | :----------------------------------------------------------------- | :---------------------------------------------------------- |
|
||||
| **Structured (Idiomatic)** | `0` | Return a JSON object like `{"decision": "deny", "reason": "..."}`. | Production hooks, custom user feedback, and complex logic. |
|
||||
| **Emergency Brake** | `2` | Print the error message to `stderr` and exit. | Simple security gates, script errors, or rapid prototyping. |
|
||||
|
||||
## Practical examples
|
||||
|
||||
### Security: Block secrets in commits
|
||||
|
||||
Prevent committing files containing API keys or passwords. Note that we use
|
||||
**Exit Code 0** to provide a structured denial message to the agent.
|
||||
|
||||
**`.gemini/hooks/block-secrets.sh`:**
|
||||
|
||||
```bash
|
||||
#!/usr/bin/env bash
|
||||
input=$(cat)
|
||||
|
||||
# Extract content being written
|
||||
content=$(echo "$input" | jq -r '.tool_input.content // .tool_input.new_string // ""')
|
||||
|
||||
# Check for secrets
|
||||
if echo "$content" | grep -qE 'api[_-]?key|password|secret'; then
|
||||
# Log to stderr
|
||||
echo "Blocked potential secret" >&2
|
||||
|
||||
# Return structured denial to stdout
|
||||
cat <<EOF
|
||||
{
|
||||
"decision": "deny",
|
||||
"reason": "Security Policy: Potential secret detected in content.",
|
||||
"systemMessage": "🔒 Security scanner blocked operation"
|
||||
}
|
||||
EOF
|
||||
exit 0
|
||||
fi
|
||||
|
||||
# Allow
|
||||
echo '{"decision": "allow"}'
|
||||
exit 0
|
||||
```
|
||||
|
||||
### Dynamic context injection (Git History)
|
||||
|
||||
Add relevant project context before each agent interaction.
|
||||
|
||||
**`.gemini/hooks/inject-context.sh`:**
|
||||
|
||||
```bash
|
||||
#!/usr/bin/env bash
|
||||
|
||||
# Get recent git commits for context
|
||||
context=$(git log -5 --oneline 2>/dev/null || echo "No git history")
|
||||
|
||||
# Return as JSON
|
||||
cat <<EOF
|
||||
{
|
||||
"hookSpecificOutput": {
|
||||
"hookEventName": "BeforeAgent",
|
||||
"additionalContext": "Recent commits:\n$context"
|
||||
}
|
||||
}
|
||||
EOF
|
||||
```
|
||||
|
||||
### RAG-based Tool Filtering (BeforeToolSelection)
|
||||
|
||||
Use `BeforeToolSelection` to intelligently reduce the tool space. This example
|
||||
uses a Node.js script to check the user's prompt and allow only relevant tools.
|
||||
|
||||
**`.gemini/hooks/filter-tools.js`:**
|
||||
|
||||
```javascript
|
||||
#!/usr/bin/env node
|
||||
const fs = require('fs');
|
||||
|
||||
async function main() {
|
||||
const input = JSON.parse(fs.readFileSync(0, 'utf-8'));
|
||||
const { llm_request } = input;
|
||||
|
||||
// Decoupled API: Access messages from llm_request
|
||||
const messages = llm_request.messages || [];
|
||||
const lastUserMessage = messages
|
||||
.slice()
|
||||
.reverse()
|
||||
.find((m) => m.role === 'user');
|
||||
|
||||
if (!lastUserMessage) {
|
||||
console.log(JSON.stringify({})); // Do nothing
|
||||
return;
|
||||
}
|
||||
|
||||
const text = lastUserMessage.content;
|
||||
const allowed = ['write_todos']; // Always allow memory
|
||||
|
||||
// Simple keyword matching
|
||||
if (text.includes('read') || text.includes('check')) {
|
||||
allowed.push('read_file', 'list_directory');
|
||||
}
|
||||
if (text.includes('test')) {
|
||||
allowed.push('run_shell_command');
|
||||
}
|
||||
|
||||
// If we found specific intent, filter tools. Otherwise allow all.
|
||||
if (allowed.length > 1) {
|
||||
console.log(
|
||||
JSON.stringify({
|
||||
hookSpecificOutput: {
|
||||
hookEventName: 'BeforeToolSelection',
|
||||
toolConfig: {
|
||||
mode: 'ANY', // Force usage of one of these tools (or AUTO)
|
||||
allowedFunctionNames: allowed,
|
||||
},
|
||||
},
|
||||
}),
|
||||
);
|
||||
} else {
|
||||
console.log(JSON.stringify({}));
|
||||
}
|
||||
}
|
||||
|
||||
main().catch((err) => {
|
||||
console.error(err);
|
||||
process.exit(1);
|
||||
});
|
||||
```
|
||||
|
||||
**`.gemini/settings.json`:**
|
||||
|
||||
```json
|
||||
{
|
||||
"hooks": {
|
||||
"BeforeToolSelection": [
|
||||
{
|
||||
"matcher": "*",
|
||||
"hooks": [
|
||||
{
|
||||
"name": "intent-filter",
|
||||
"type": "command",
|
||||
"command": "node .gemini/hooks/filter-tools.js"
|
||||
}
|
||||
]
|
||||
}
|
||||
]
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
> **TIP**
|
||||
>
|
||||
> **Union Aggregation Strategy**: `BeforeToolSelection` is unique in that it
|
||||
> combines the results of all matching hooks. If you have multiple filtering
|
||||
> hooks, the agent will receive the **union** of all whitelisted tools. Only
|
||||
> using `mode: "NONE"` will override other hooks to disable all tools.
|
||||
|
||||
## Complete example: Smart Development Workflow Assistant
|
||||
|
||||
This comprehensive example demonstrates all hook events working together. We
|
||||
will build a system that maintains memory, filters tools, and checks for
|
||||
security.
|
||||
|
||||
### Architecture
|
||||
|
||||
1. **SessionStart**: Load project memories.
|
||||
2. **BeforeAgent**: Inject memories into context.
|
||||
3. **BeforeToolSelection**: Filter tools based on intent.
|
||||
4. **BeforeTool**: Scan for secrets.
|
||||
5. **AfterModel**: Record interactions.
|
||||
6. **AfterAgent**: Validate final response quality (Retry).
|
||||
7. **SessionEnd**: Consolidate memories.
|
||||
|
||||
### Configuration (`.gemini/settings.json`)
|
||||
|
||||
```json
|
||||
{
|
||||
"hooks": {
|
||||
"SessionStart": [
|
||||
{
|
||||
"matcher": "startup",
|
||||
"hooks": [
|
||||
{
|
||||
"name": "init",
|
||||
"type": "command",
|
||||
"command": "node .gemini/hooks/init.js"
|
||||
}
|
||||
]
|
||||
}
|
||||
],
|
||||
"BeforeAgent": [
|
||||
{
|
||||
"matcher": "*",
|
||||
"hooks": [
|
||||
{
|
||||
"name": "memory",
|
||||
"type": "command",
|
||||
"command": "node .gemini/hooks/inject-memories.js"
|
||||
}
|
||||
]
|
||||
}
|
||||
],
|
||||
"BeforeToolSelection": [
|
||||
{
|
||||
"matcher": "*",
|
||||
"hooks": [
|
||||
{
|
||||
"name": "filter",
|
||||
"type": "command",
|
||||
"command": "node .gemini/hooks/rag-filter.js"
|
||||
}
|
||||
]
|
||||
}
|
||||
],
|
||||
"BeforeTool": [
|
||||
{
|
||||
"matcher": "write_file",
|
||||
"hooks": [
|
||||
{
|
||||
"name": "security",
|
||||
"type": "command",
|
||||
"command": "node .gemini/hooks/security.js"
|
||||
}
|
||||
]
|
||||
}
|
||||
],
|
||||
"AfterModel": [
|
||||
{
|
||||
"matcher": "*",
|
||||
"hooks": [
|
||||
{
|
||||
"name": "record",
|
||||
"type": "command",
|
||||
"command": "node .gemini/hooks/record.js"
|
||||
}
|
||||
]
|
||||
}
|
||||
],
|
||||
"AfterAgent": [
|
||||
{
|
||||
"matcher": "*",
|
||||
"hooks": [
|
||||
{
|
||||
"name": "validate",
|
||||
"type": "command",
|
||||
"command": "node .gemini/hooks/validate.js"
|
||||
}
|
||||
]
|
||||
}
|
||||
],
|
||||
"SessionEnd": [
|
||||
{
|
||||
"matcher": "exit",
|
||||
"hooks": [
|
||||
{
|
||||
"name": "save",
|
||||
"type": "command",
|
||||
"command": "node .gemini/hooks/consolidate.js"
|
||||
}
|
||||
]
|
||||
}
|
||||
]
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
### Hook Scripts
|
||||
|
||||
> **Note**: For brevity, these scripts use `console.error` for logging and
|
||||
> standard `console.log` for JSON output.
|
||||
|
||||
#### 1. Initialize (`init.js`)
|
||||
|
||||
```javascript
|
||||
#!/usr/bin/env node
|
||||
// Initialize DB or resources
|
||||
console.error('Initializing assistant...');
|
||||
|
||||
// Output to user
|
||||
console.log(
|
||||
JSON.stringify({
|
||||
systemMessage: '🧠 Smart Assistant Loaded',
|
||||
}),
|
||||
);
|
||||
```
|
||||
|
||||
#### 2. Inject Memories (`inject-memories.js`)
|
||||
|
||||
```javascript
|
||||
#!/usr/bin/env node
|
||||
const fs = require('fs');
|
||||
|
||||
async function main() {
|
||||
const input = JSON.parse(fs.readFileSync(0, 'utf-8'));
|
||||
// Assume we fetch memories from a DB here
|
||||
const memories = '- [Memory] Always use TypeScript for this project.';
|
||||
|
||||
console.log(
|
||||
JSON.stringify({
|
||||
hookSpecificOutput: {
|
||||
hookEventName: 'BeforeAgent',
|
||||
additionalContext: `\n## Relevant Memories\n${memories}`,
|
||||
},
|
||||
}),
|
||||
);
|
||||
}
|
||||
main();
|
||||
```
|
||||
|
||||
#### 3. Security Check (`security.js`)
|
||||
|
||||
```javascript
|
||||
#!/usr/bin/env node
|
||||
const fs = require('fs');
|
||||
const input = JSON.parse(fs.readFileSync(0));
|
||||
const content = input.tool_input.content || '';
|
||||
|
||||
if (content.includes('SECRET_KEY')) {
|
||||
console.log(
|
||||
JSON.stringify({
|
||||
decision: 'deny',
|
||||
reason: 'Found SECRET_KEY in content',
|
||||
systemMessage: '🚨 Blocked sensitive commit',
|
||||
}),
|
||||
);
|
||||
process.exit(0);
|
||||
}
|
||||
|
||||
console.log(JSON.stringify({ decision: 'allow' }));
|
||||
```
|
||||
|
||||
#### 4. Record Interaction (`record.js`)
|
||||
|
||||
```javascript
|
||||
#!/usr/bin/env node
|
||||
const fs = require('fs');
|
||||
const path = require('path');
|
||||
|
||||
const input = JSON.parse(fs.readFileSync(0));
|
||||
const { llm_request, llm_response } = input;
|
||||
const logFile = path.join(
|
||||
process.env.GEMINI_PROJECT_DIR,
|
||||
'.gemini/memory/session.jsonl',
|
||||
);
|
||||
|
||||
fs.appendFileSync(
|
||||
logFile,
|
||||
JSON.stringify({
|
||||
request: llm_request,
|
||||
response: llm_response,
|
||||
timestamp: new Date().toISOString(),
|
||||
}) + '\n',
|
||||
);
|
||||
|
||||
console.log(JSON.stringify({}));
|
||||
```
|
||||
|
||||
#### 5. Validate Response (`validate.js`)
|
||||
|
||||
```javascript
|
||||
#!/usr/bin/env node
|
||||
const fs = require('fs');
|
||||
const input = JSON.parse(fs.readFileSync(0));
|
||||
const response = input.prompt_response;
|
||||
|
||||
// Example: Check if the agent forgot to include a summary
|
||||
if (!response.includes('Summary:')) {
|
||||
console.log(
|
||||
JSON.stringify({
|
||||
decision: 'block', // Triggers an automatic retry turn
|
||||
reason: 'Your response is missing a Summary section. Please add one.',
|
||||
systemMessage: '🔄 Requesting missing summary...',
|
||||
}),
|
||||
);
|
||||
process.exit(0);
|
||||
}
|
||||
|
||||
console.log(JSON.stringify({ decision: 'allow' }));
|
||||
```
|
||||
|
||||
#### 6. Consolidate Memories (`consolidate.js`)
|
||||
|
||||
```javascript
|
||||
#!/usr/bin/env node
|
||||
// Logic to save final session state
|
||||
console.error('Consolidating memories for session end...');
|
||||
```
|
||||
|
||||
## Packaging as an extension
|
||||
|
||||
While project-level hooks are great for specific repositories, you can share
|
||||
your hooks across multiple projects by packaging them as a
|
||||
[Gemini CLI extension](../extensions/index.md). This provides version control,
|
||||
easy distribution, and centralized management.
|
||||
@@ -0,0 +1,271 @@
|
||||
# Gemini CLI companion plugin: Interface specification
|
||||
|
||||
> Last Updated: September 15, 2025
|
||||
|
||||
This document defines the contract for building a companion plugin to enable
|
||||
Gemini CLI's IDE mode. For VS Code, these features (native diffing, context
|
||||
awareness) are provided by the official extension
|
||||
([marketplace](https://marketplace.visualstudio.com/items?itemName=Google.gemini-cli-vscode-ide-companion)).
|
||||
This specification is for contributors who wish to bring similar functionality
|
||||
to other editors like JetBrains IDEs, Sublime Text, etc.
|
||||
|
||||
## I. The communication interface
|
||||
|
||||
Gemini CLI and the IDE plugin communicate through a local communication channel.
|
||||
|
||||
### 1. Transport layer: MCP over HTTP
|
||||
|
||||
The plugin **MUST** run a local HTTP server that implements the **Model Context
|
||||
Protocol (MCP)**.
|
||||
|
||||
- **Protocol:** The server must be a valid MCP server. We recommend using an
|
||||
existing MCP SDK for your language of choice if available.
|
||||
- **Endpoint:** The server should expose a single endpoint (for example, `/mcp`)
|
||||
for all MCP communication.
|
||||
- **Port:** The server **MUST** listen on a dynamically assigned port (that is,
|
||||
listen on port `0`).
|
||||
|
||||
### 2. Discovery mechanism: The port file
|
||||
|
||||
For Gemini CLI to connect, it needs to discover which IDE instance it's running
|
||||
in and what port your server is using. The plugin **MUST** facilitate this by
|
||||
creating a "discovery file."
|
||||
|
||||
- **How the CLI finds the file:** The CLI determines the Process ID (PID) of the
|
||||
IDE it's running in by traversing the process tree. It then looks for a
|
||||
discovery file that contains this PID in its name.
|
||||
- **File location:** The file must be created in a specific directory:
|
||||
`os.tmpdir()/gemini/ide/`. Your plugin must create this directory if it
|
||||
doesn't exist.
|
||||
- **File naming convention:** The filename is critical and **MUST** follow the
|
||||
pattern: `gemini-ide-server-${PID}-${PORT}.json`
|
||||
- `${PID}`: The process ID of the parent IDE process. Your plugin must
|
||||
determine this PID and include it in the filename.
|
||||
- `${PORT}`: The port your MCP server is listening on.
|
||||
- **File content and workspace validation:** The file **MUST** contain a JSON
|
||||
object with the following structure:
|
||||
|
||||
```json
|
||||
{
|
||||
"port": 12345,
|
||||
"workspacePath": "/path/to/project1:/path/to/project2",
|
||||
"authToken": "a-very-secret-token",
|
||||
"ideInfo": {
|
||||
"name": "vscode",
|
||||
"displayName": "VS Code"
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
- `port` (number, required): The port of the MCP server.
|
||||
- `workspacePath` (string, required): A list of all open workspace root paths,
|
||||
delimited by the OS-specific path separator (`:` for Linux/macOS, `;` for
|
||||
Windows). The CLI uses this path to ensure it's running in the same project
|
||||
folder that's open in the IDE. If the CLI's current working directory is not
|
||||
a sub-directory of `workspacePath`, the connection will be rejected. Your
|
||||
plugin **MUST** provide the correct, absolute path(s) to the root of the
|
||||
open workspace(s).
|
||||
- `authToken` (string, required): A secret token for securing the connection.
|
||||
The CLI will include this token in an `Authorization: Bearer <token>` header
|
||||
on all requests.
|
||||
- `ideInfo` (object, required): Information about the IDE.
|
||||
- `name` (string, required): A short, lowercase identifier for the IDE (for
|
||||
example, `vscode`, `jetbrains`).
|
||||
- `displayName` (string, required): A user-friendly name for the IDE (for
|
||||
example, `VS Code`, `JetBrains IDE`).
|
||||
|
||||
- **Authentication:** To secure the connection, the plugin **MUST** generate a
|
||||
unique, secret token and include it in the discovery file. The CLI will then
|
||||
include this token in the `Authorization` header for all requests to the MCP
|
||||
server (for example, `Authorization: Bearer a-very-secret-token`). Your server
|
||||
**MUST** validate this token on every request and reject any that are
|
||||
unauthorized.
|
||||
- **Tie-breaking with environment variables (recommended):** For the most
|
||||
reliable experience, your plugin **SHOULD** both create the discovery file and
|
||||
set the `GEMINI_CLI_IDE_SERVER_PORT` environment variable in the integrated
|
||||
terminal. The file serves as the primary discovery mechanism, but the
|
||||
environment variable is crucial for tie-breaking. If a user has multiple IDE
|
||||
windows open for the same workspace, the CLI uses the
|
||||
`GEMINI_CLI_IDE_SERVER_PORT` variable to identify and connect to the correct
|
||||
window's server.
|
||||
|
||||
## II. The context interface
|
||||
|
||||
To enable context awareness, the plugin **MAY** provide the CLI with real-time
|
||||
information about the user's activity in the IDE.
|
||||
|
||||
### `ide/contextUpdate` notification
|
||||
|
||||
The plugin **MAY** send an `ide/contextUpdate`
|
||||
[notification](https://modelcontextprotocol.io/specification/2025-06-18/basic/index#notifications)
|
||||
to the CLI whenever the user's context changes.
|
||||
|
||||
- **Triggering events:** This notification should be sent (with a recommended
|
||||
debounce of 50ms) when:
|
||||
- A file is opened, closed, or focused.
|
||||
- The user's cursor position or text selection changes in the active file.
|
||||
- **Payload (`IdeContext`):** The notification parameters **MUST** be an
|
||||
`IdeContext` object:
|
||||
|
||||
```typescript
|
||||
interface IdeContext {
|
||||
workspaceState?: {
|
||||
openFiles?: File[];
|
||||
isTrusted?: boolean;
|
||||
};
|
||||
}
|
||||
|
||||
interface File {
|
||||
// Absolute path to the file
|
||||
path: string;
|
||||
// Last focused Unix timestamp (for ordering)
|
||||
timestamp: number;
|
||||
// True if this is the currently focused file
|
||||
isActive?: boolean;
|
||||
cursor?: {
|
||||
// 1-based line number
|
||||
line: number;
|
||||
// 1-based character number
|
||||
character: number;
|
||||
};
|
||||
// The text currently selected by the user
|
||||
selectedText?: string;
|
||||
}
|
||||
```
|
||||
|
||||
<!-- prettier-ignore -->
|
||||
> [!NOTE]
|
||||
> The `openFiles` list should only include files that exist on disk.
|
||||
> Virtual files (for example, unsaved files without a path, editor settings pages)
|
||||
> **MUST** be excluded.
|
||||
|
||||
### How the CLI uses this context
|
||||
|
||||
After receiving the `IdeContext` object, the CLI performs several normalization
|
||||
and truncation steps before sending the information to the model.
|
||||
|
||||
- **File ordering:** The CLI uses the `timestamp` field to determine the most
|
||||
recently used files. It sorts the `openFiles` list based on this value.
|
||||
Therefore, your plugin **MUST** provide an accurate Unix timestamp for when a
|
||||
file was last focused.
|
||||
- **Active file:** The CLI considers only the most recent file (after sorting)
|
||||
to be the "active" file. It will ignore the `isActive` flag on all other files
|
||||
and clear their `cursor` and `selectedText` fields. Your plugin should focus
|
||||
on setting `isActive: true` and providing cursor/selection details only for
|
||||
the currently focused file.
|
||||
- **Truncation:** To manage token limits, the CLI truncates both the file list
|
||||
(to 10 files) and the `selectedText` (to 16KB).
|
||||
|
||||
While the CLI handles the final truncation, it is highly recommended that your
|
||||
plugin also limits the amount of context it sends.
|
||||
|
||||
## III. The diffing interface
|
||||
|
||||
To enable interactive code modifications, the plugin **MAY** expose a diffing
|
||||
interface. This allows the CLI to request that the IDE open a diff view, showing
|
||||
proposed changes to a file. The user can then review, edit, and ultimately
|
||||
accept or reject these changes directly within the IDE.
|
||||
|
||||
### `openDiff` tool
|
||||
|
||||
The plugin **MUST** register an `openDiff` tool on its MCP server.
|
||||
|
||||
- **Description:** This tool instructs the IDE to open a modifiable diff view
|
||||
for a specific file.
|
||||
- **Request (`OpenDiffRequest`):** The tool is invoked via a `tools/call`
|
||||
request. The `arguments` field within the request's `params` **MUST** be an
|
||||
`OpenDiffRequest` object.
|
||||
|
||||
```typescript
|
||||
interface OpenDiffRequest {
|
||||
// The absolute path to the file to be diffed.
|
||||
filePath: string;
|
||||
// The proposed new content for the file.
|
||||
newContent: string;
|
||||
}
|
||||
```
|
||||
|
||||
- **Response (`CallToolResult`):** The tool **MUST** immediately return a
|
||||
`CallToolResult` to acknowledge the request and report whether the diff view
|
||||
was successfully opened.
|
||||
|
||||
- On Success: If the diff view was opened successfully, the response **MUST**
|
||||
contain empty content (that is, `content: []`).
|
||||
- On Failure: If an error prevented the diff view from opening, the response
|
||||
**MUST** have `isError: true` and include a `TextContent` block in the
|
||||
`content` array describing the error.
|
||||
|
||||
The actual outcome of the diff (acceptance or rejection) is communicated
|
||||
asynchronously via notifications.
|
||||
|
||||
### `closeDiff` tool
|
||||
|
||||
The plugin **MUST** register a `closeDiff` tool on its MCP server.
|
||||
|
||||
- **Description:** This tool instructs the IDE to close an open diff view for a
|
||||
specific file.
|
||||
- **Request (`CloseDiffRequest`):** The tool is invoked via a `tools/call`
|
||||
request. The `arguments` field within the request's `params` **MUST** be an
|
||||
`CloseDiffRequest` object.
|
||||
|
||||
```typescript
|
||||
interface CloseDiffRequest {
|
||||
// The absolute path to the file whose diff view should be closed.
|
||||
filePath: string;
|
||||
}
|
||||
```
|
||||
|
||||
- **Response (`CallToolResult`):** The tool **MUST** return a `CallToolResult`.
|
||||
- On Success: If the diff view was closed successfully, the response **MUST**
|
||||
include a single **TextContent** block in the content array containing the
|
||||
file's final content before closing.
|
||||
- On Failure: If an error prevented the diff view from closing, the response
|
||||
**MUST** have `isError: true` and include a `TextContent` block in the
|
||||
`content` array describing the error.
|
||||
|
||||
### `ide/diffAccepted` notification
|
||||
|
||||
When the user accepts the changes in a diff view (for example, by clicking an
|
||||
"Apply" or "Save" button), the plugin **MUST** send an `ide/diffAccepted`
|
||||
notification to the CLI.
|
||||
|
||||
- **Payload:** The notification parameters **MUST** include the file path and
|
||||
the final content of the file. The content may differ from the original
|
||||
`newContent` if the user made manual edits in the diff view.
|
||||
|
||||
```typescript
|
||||
{
|
||||
// The absolute path to the file that was diffed.
|
||||
filePath: string;
|
||||
// The full content of the file after acceptance.
|
||||
content: string;
|
||||
}
|
||||
```
|
||||
|
||||
### `ide/diffRejected` notification
|
||||
|
||||
When the user rejects the changes (for example, by closing the diff view without
|
||||
accepting), the plugin **MUST** send an `ide/diffRejected` notification to the
|
||||
CLI.
|
||||
|
||||
- **Payload:** The notification parameters **MUST** include the file path of the
|
||||
rejected diff.
|
||||
|
||||
```typescript
|
||||
{
|
||||
// The absolute path to the file that was diffed.
|
||||
filePath: string;
|
||||
}
|
||||
```
|
||||
|
||||
## IV. The lifecycle interface
|
||||
|
||||
The plugin **MUST** manage its resources and the discovery file correctly based
|
||||
on the IDE's lifecycle.
|
||||
|
||||
- **On activation (IDE startup/plugin enabled):**
|
||||
1. Start the MCP server.
|
||||
2. Create the discovery file.
|
||||
- **On deactivation (IDE shutdown/plugin disabled):**
|
||||
1. Stop the MCP server.
|
||||
2. Delete the discovery file.
|
||||
@@ -0,0 +1,307 @@
|
||||
# IDE Integration
|
||||
|
||||
Gemini CLI can integrate with your IDE to provide a more seamless and
|
||||
context-aware experience. This integration allows the CLI to understand your
|
||||
workspace better and enables powerful features like native in-editor diffing.
|
||||
|
||||
There are two primary ways to integrate Gemini CLI with an IDE:
|
||||
|
||||
1. **VS Code companion extension**: Install the "Gemini CLI Companion"
|
||||
extension on [Antigravity](https://antigravity.google),
|
||||
[Visual Studio Code](https://code.visualstudio.com/), or other VS Code
|
||||
compatible editors.
|
||||
2. **Agent Client Protocol (ACP)**: An open protocol for interoperability
|
||||
between AI coding agents and IDEs. This method is used for integrations with
|
||||
tools like JetBrains and Zed, which leverage the ACP Agent Registry for easy
|
||||
discovery and installation of compatible agents like Gemini CLI.
|
||||
|
||||
## VS Code companion extension
|
||||
|
||||
The **Gemini CLI Companion extension** grants Gemini CLI direct access to your
|
||||
VS Code compatible IDEs and improves your experience by providing real-time
|
||||
context such as open files, cursor positions, and text selection. The extension
|
||||
also enables a native diffing interface so you can seamlessly review and apply
|
||||
AI-generated code changes directly within your editor.
|
||||
|
||||
### Features
|
||||
|
||||
- **Workspace context:** The CLI automatically gains awareness of your workspace
|
||||
to provide more relevant and accurate responses. This context includes:
|
||||
|
||||
- The **10 most recently accessed files** in your workspace.
|
||||
- Your active cursor position.
|
||||
- Any text you have selected (up to a 16KB limit; longer selections will be
|
||||
truncated).
|
||||
|
||||
- **Native diffing:** When Gemini suggests code modifications, you can view the
|
||||
changes directly within your IDE's native diff viewer. This lets you review,
|
||||
edit, and accept or reject the suggested changes seamlessly.
|
||||
|
||||
- **VS Code commands:** You can access Gemini CLI features directly from the VS
|
||||
Code Command Palette (`Cmd+Shift+P` or `Ctrl+Shift+P`):
|
||||
- `Gemini CLI: Run`: Starts a new Gemini CLI session in the integrated
|
||||
terminal.
|
||||
- `Gemini CLI: Accept Diff`: Accepts the changes in the active diff editor.
|
||||
- `Gemini CLI: Close Diff Editor`: Rejects the changes and closes the active
|
||||
diff editor.
|
||||
- `Gemini CLI: View Third-Party Notices`: Displays the third-party notices for
|
||||
the extension.
|
||||
|
||||
### Installation and setup
|
||||
|
||||
There are three ways to set up the IDE integration:
|
||||
|
||||
#### 1. Automatic nudge (recommended)
|
||||
|
||||
When you run Gemini CLI inside a supported editor, it will automatically detect
|
||||
your environment and prompt you to connect. Answering "Yes" will automatically
|
||||
run the necessary setup, which includes installing the companion extension and
|
||||
enabling the connection.
|
||||
|
||||
#### 2. Manual installation from CLI
|
||||
|
||||
If you previously dismissed the prompt or want to install the extension
|
||||
manually, you can run the following command inside Gemini CLI:
|
||||
|
||||
```
|
||||
/ide install
|
||||
```
|
||||
|
||||
This will find the correct extension for your IDE and install it.
|
||||
|
||||
#### 3. Manual installation from a marketplace
|
||||
|
||||
You can also install the extension directly from a marketplace.
|
||||
|
||||
- **For Visual Studio Code:** Install from the
|
||||
[VS Code Marketplace](https://marketplace.visualstudio.com/items?itemName=google.gemini-cli-vscode-ide-companion).
|
||||
- **For VS Code forks:** To support forks of VS Code, the extension is also
|
||||
published on the
|
||||
[Open VSX Registry](https://open-vsx.org/extension/google/gemini-cli-vscode-ide-companion).
|
||||
Follow your editor's instructions for installing extensions from this
|
||||
registry.
|
||||
|
||||
<!-- prettier-ignore -->
|
||||
> [!NOTE]
|
||||
> The "Gemini CLI Companion" extension may appear towards the bottom of
|
||||
> search results. If you don't see it immediately, try scrolling down or
|
||||
> sorting by "Newly Published".
|
||||
>
|
||||
> After manually installing the extension, you must run `/ide enable` in the CLI
|
||||
> to activate the integration.
|
||||
|
||||
### Usage
|
||||
|
||||
#### Enabling and disabling
|
||||
|
||||
You can control the IDE integration from within the CLI:
|
||||
|
||||
- To enable the connection to the IDE, run:
|
||||
```
|
||||
/ide enable
|
||||
```
|
||||
- To disable the connection, run:
|
||||
```
|
||||
/ide disable
|
||||
```
|
||||
|
||||
When enabled, Gemini CLI will automatically attempt to connect to the IDE
|
||||
companion extension.
|
||||
|
||||
#### Checking the status
|
||||
|
||||
To check the connection status and see the context the CLI has received from the
|
||||
IDE, run:
|
||||
|
||||
```
|
||||
/ide status
|
||||
```
|
||||
|
||||
If connected, this command will show the IDE it's connected to and a list of
|
||||
recently opened files it is aware of.
|
||||
|
||||
<!-- prettier-ignore -->
|
||||
> [!NOTE]
|
||||
> The file list is limited to 10 recently accessed files within your
|
||||
> workspace and only includes local files on disk.
|
||||
|
||||
#### Working with diffs
|
||||
|
||||
When you ask Gemini to modify a file, it can open a diff view directly in your
|
||||
editor.
|
||||
|
||||
**To accept a diff**, you can perform any of the following actions:
|
||||
|
||||
- Click the **checkmark icon** in the diff editor's title bar.
|
||||
- Save the file (for example, with `Cmd+S` or `Ctrl+S`).
|
||||
- Open the Command Palette and run **Gemini CLI: Accept Diff**.
|
||||
- Respond with `yes` in the CLI when prompted.
|
||||
|
||||
**To reject a diff**, you can:
|
||||
|
||||
- Click the **'x' icon** in the diff editor's title bar.
|
||||
- Close the diff editor tab.
|
||||
- Open the Command Palette and run **Gemini CLI: Close Diff Editor**.
|
||||
- Respond with `no` in the CLI when prompted.
|
||||
|
||||
You can also **modify the suggested changes** directly in the diff view before
|
||||
accepting them.
|
||||
|
||||
If you select ‘Allow for this session’ in the CLI, changes will no longer show
|
||||
up in the IDE as they will be auto-accepted.
|
||||
|
||||
## Agent Client Protocol (ACP)
|
||||
|
||||
ACP is an open protocol that standardizes how AI coding agents communicate with
|
||||
code editors and IDEs. It addresses the challenge of fragmented distribution,
|
||||
where agents traditionally needed custom integrations for each client. With ACP,
|
||||
developers can implement their agent once, and it becomes compatible with any
|
||||
ACP-compliant editor.
|
||||
|
||||
For a comprehensive introduction to ACP, including its architecture and
|
||||
benefits, refer to the official
|
||||
[ACP Introduction](https://agentclientprotocol.com/get-started/introduction)
|
||||
documentation.
|
||||
|
||||
### The ACP Agent Registry
|
||||
|
||||
Gemini CLI is officially available in the **ACP Agent Registry**. This allows
|
||||
you to install and update Gemini CLI directly within supporting IDEs and
|
||||
eliminates the need for manual downloads or IDE-specific extensions.
|
||||
|
||||
Using the registry ensures:
|
||||
|
||||
- **Ease of use**: Discover and install agents directly within your IDE
|
||||
settings.
|
||||
- **Latest versions**: Ensures users always have access to the most up-to-date
|
||||
agent implementations.
|
||||
|
||||
For more details on how the registry works, visit the official
|
||||
[ACP Agent Registry](https://agentclientprotocol.com/get-started/registry) page.
|
||||
You can learn about how specific IDEs leverage this integration in the following
|
||||
section.
|
||||
|
||||
### IDE-specific integration
|
||||
|
||||
Gemini CLI is an ACP-compatible agent available in the ACP Agent Registry.
|
||||
Here’s how different IDEs leverage the ACP and the registry:
|
||||
|
||||
#### JetBrains IDEs
|
||||
|
||||
JetBrains IDEs (like IntelliJ IDEA, PyCharm, or GoLand) offer built-in registry
|
||||
support, allowing users to find and install ACP-compatible agents directly.
|
||||
|
||||
For more details, refer to the official
|
||||
[JetBrains AI Blog announcement](https://blog.jetbrains.com/ai/2026/01/acp-agent-registry/).
|
||||
|
||||
#### Zed
|
||||
|
||||
Zed, a modern code editor, also integrates with the ACP Agent Registry. This
|
||||
allows Zed users to easily browse, install, and manage ACP agents.
|
||||
|
||||
Learn more about Zed's integration with the ACP Registry in their
|
||||
[blog post](https://zed.dev/blog/acp-registry).
|
||||
|
||||
#### Other ACP-compatible IDEs
|
||||
|
||||
Any other IDE that supports the ACP Agent Registry can install Gemini CLI
|
||||
directly through their in-built registry features.
|
||||
|
||||
## Using with sandboxing
|
||||
|
||||
If you are using Gemini CLI within a sandbox, be aware of the following:
|
||||
|
||||
- **On macOS:** The IDE integration requires network access to communicate with
|
||||
the IDE companion extension. You must use a Seatbelt profile that allows
|
||||
network access.
|
||||
- **In a Docker container:** If you run Gemini CLI inside a Docker (or Podman)
|
||||
container, the IDE integration can still connect to the VS Code extension
|
||||
running on your host machine. The CLI is configured to automatically find the
|
||||
IDE server on `host.docker.internal`. No special configuration is usually
|
||||
required, but you may need to ensure your Docker networking setup allows
|
||||
connections from the container to the host.
|
||||
|
||||
## Troubleshooting
|
||||
|
||||
### VS Code companion extension errors
|
||||
|
||||
#### Connection errors
|
||||
|
||||
- **Message:**
|
||||
`🔴 Disconnected: Failed to connect to IDE companion extension in [IDE Name]. Please ensure the extension is running. To install the extension, run /ide install.`
|
||||
|
||||
- **Cause:** Gemini CLI could not find the necessary environment variables
|
||||
(`GEMINI_CLI_IDE_WORKSPACE_PATH` or `GEMINI_CLI_IDE_SERVER_PORT`) to connect
|
||||
to the IDE. This usually means the IDE companion extension is not running or
|
||||
did not initialize correctly.
|
||||
- **Solution:**
|
||||
1. Make sure you have installed the **Gemini CLI Companion** extension in
|
||||
your IDE and that it is enabled.
|
||||
2. Open a new terminal window in your IDE to ensure it picks up the correct
|
||||
environment.
|
||||
|
||||
- **Message:**
|
||||
`🔴 Disconnected: IDE connection error. The connection was lost unexpectedly. Please try reconnecting by running /ide enable`
|
||||
- **Cause:** The connection to the IDE companion was lost.
|
||||
- **Solution:** Run `/ide enable` to try and reconnect. If the issue
|
||||
continues, open a new terminal window or restart your IDE.
|
||||
|
||||
#### Manual PID override
|
||||
|
||||
If automatic IDE detection fails, or if you are running Gemini CLI in a
|
||||
standalone terminal and want to manually associate it with a specific IDE
|
||||
instance, you can set the `GEMINI_CLI_IDE_PID` environment variable to the
|
||||
process ID (PID) of your IDE.
|
||||
|
||||
**macOS/Linux**
|
||||
|
||||
```bash
|
||||
export GEMINI_CLI_IDE_PID=12345
|
||||
```
|
||||
|
||||
**Windows (PowerShell)**
|
||||
|
||||
```powershell
|
||||
$env:GEMINI_CLI_IDE_PID=12345
|
||||
```
|
||||
|
||||
When this variable is set, Gemini CLI will skip automatic detection and attempt
|
||||
to connect using the provided PID.
|
||||
|
||||
#### Configuration errors
|
||||
|
||||
- **Message:**
|
||||
`🔴 Disconnected: Directory mismatch. Gemini CLI is running in a different location than the open workspace in [IDE Name]. Please run the CLI from one of the following directories: [List of directories]`
|
||||
|
||||
- **Cause:** The CLI's current working directory is outside the workspace you
|
||||
have open in your IDE.
|
||||
- **Solution:** `cd` into the same directory that is open in your IDE and
|
||||
restart the CLI.
|
||||
|
||||
- **Message:**
|
||||
`🔴 Disconnected: To use this feature, please open a workspace folder in [IDE Name] and try again.`
|
||||
- **Cause:** You have no workspace open in your IDE.
|
||||
- **Solution:** Open a workspace in your IDE and restart the CLI.
|
||||
|
||||
#### General errors
|
||||
|
||||
- **Message:**
|
||||
`IDE integration is not supported in your current environment. To use this feature, run Gemini CLI in one of these supported IDEs: [List of IDEs]`
|
||||
|
||||
- **Cause:** You are running Gemini CLI in a terminal or environment that is
|
||||
not a supported IDE.
|
||||
- **Solution:** Run Gemini CLI from the integrated terminal of a supported
|
||||
IDE, like Antigravity or VS Code.
|
||||
|
||||
- **Message:**
|
||||
`No installer is available for IDE. Please install Gemini CLI Companion extension manually from the marketplace.`
|
||||
- **Cause:** You ran `/ide install`, but the CLI does not have an automated
|
||||
installer for your specific IDE.
|
||||
- **Solution:** Open your IDE's extension marketplace, search for "Gemini CLI
|
||||
Companion", and
|
||||
[install it manually](#3-manual-installation-from-a-marketplace).
|
||||
|
||||
### ACP integration errors
|
||||
|
||||
For issues related to ACP integration, refer to the debugging and telemetry
|
||||
section in the [ACP Mode](../cli/acp-mode.md) documentation.
|
||||
+139
@@ -0,0 +1,139 @@
|
||||
# Gemini CLI documentation
|
||||
|
||||
Gemini CLI brings the power of Gemini models directly into your terminal. Use it
|
||||
to understand code, automate tasks, and build workflows with your local project
|
||||
context.
|
||||
|
||||
## Install
|
||||
|
||||
```bash
|
||||
npm install -g @google/gemini-cli
|
||||
```
|
||||
|
||||
## Get started
|
||||
|
||||
Jump in to Gemini CLI.
|
||||
|
||||
- **[Quickstart](./get-started/index.md):** Your first session with Gemini CLI.
|
||||
- **[Installation](./get-started/installation.mdx):** How to install Gemini CLI
|
||||
on your system.
|
||||
- **[Authentication](./get-started/authentication.mdx):** Setup instructions for
|
||||
personal and enterprise accounts.
|
||||
- **[CLI cheatsheet](./cli/cli-reference.md):** A quick reference for common
|
||||
commands and options.
|
||||
- **[Gemini 3 on Gemini CLI](./get-started/gemini-3.md):** Learn about Gemini 3
|
||||
support in Gemini CLI.
|
||||
|
||||
## Use Gemini CLI
|
||||
|
||||
User-focused guides and tutorials for daily development workflows.
|
||||
|
||||
- **[File management](./cli/tutorials/file-management.md):** How to work with
|
||||
local files and directories.
|
||||
- **[Get started with Agent skills](./cli/tutorials/skills-getting-started.md):**
|
||||
Getting started with specialized expertise.
|
||||
- **[Manage context and memory](./cli/tutorials/memory-management.md):**
|
||||
Managing persistent instructions and facts.
|
||||
- **[Execute shell commands](./cli/tutorials/shell-commands.md):** Executing
|
||||
system commands safely.
|
||||
- **[Manage sessions and history](./cli/tutorials/session-management.md):**
|
||||
Resuming, managing, and rewinding conversations.
|
||||
- **[Plan tasks with todos](./cli/tutorials/task-planning.md):** Using todos for
|
||||
complex workflows.
|
||||
- **[Web search and fetch](./cli/tutorials/web-tools.md):** Searching and
|
||||
fetching content from the web.
|
||||
- **[Set up an MCP server](./cli/tutorials/mcp-setup.md):** Set up an MCP
|
||||
server.
|
||||
- **[Automate tasks](./cli/tutorials/automation.md):** Automate tasks.
|
||||
|
||||
## Features
|
||||
|
||||
Technical documentation for each capability of Gemini CLI.
|
||||
|
||||
- **[Extensions](./extensions/index.md):** Extend Gemini CLI with new tools and
|
||||
capabilities.
|
||||
- **[Agent Skills](./cli/skills.md):** Use specialized agents for specific
|
||||
tasks.
|
||||
- **[Checkpointing](./cli/checkpointing.md):** Automatic session snapshots.
|
||||
- **[Headless mode](./cli/headless.md):** Programmatic and scripting interface.
|
||||
- **[Hooks](./hooks/index.md):** Customize Gemini CLI behavior with scripts.
|
||||
- **[IDE integration](./ide-integration/index.md):** Integrate Gemini CLI with
|
||||
your favorite IDE.
|
||||
- **[MCP servers](./tools/mcp-server.md):** Connect to and use remote agents.
|
||||
- **[Model routing](./cli/model-routing.md):** Automatic fallback resilience.
|
||||
- **[Model selection](./cli/model.md):** Choose the best model for your needs.
|
||||
- **[Plan mode 🔬](./cli/plan-mode.md):** Use a safe, read-only mode for
|
||||
planning complex changes.
|
||||
- **[Subagents 🔬](./core/subagents.md):** Using specialized agents for specific
|
||||
tasks.
|
||||
- **[Remote subagents 🔬](./core/remote-agents.md):** Connecting to and using
|
||||
remote agents.
|
||||
- **[Rewind](./cli/rewind.md):** Rewind and replay sessions.
|
||||
- **[Sandboxing](./cli/sandbox.md):** Isolate tool execution.
|
||||
- **[Settings](./cli/settings.md):** Full configuration reference.
|
||||
- **[Telemetry](./cli/telemetry.md):** Usage and performance metric details.
|
||||
- **[Token caching](./cli/token-caching.md):** Performance optimization.
|
||||
|
||||
## Configuration
|
||||
|
||||
Settings and customization options for Gemini CLI.
|
||||
|
||||
- **[Custom commands](./cli/custom-commands.md):** Personalized shortcuts.
|
||||
- **[Enterprise configuration](./cli/enterprise.md):** Professional environment
|
||||
controls.
|
||||
- **[Ignore files (.geminiignore)](./cli/gemini-ignore.md):** Exclusion pattern
|
||||
reference.
|
||||
- **[Model configuration](./cli/generation-settings.md):** Fine-tune generation
|
||||
parameters like temperature and thinking budget.
|
||||
- **[Project context (GEMINI.md)](./cli/gemini-md.md):** Technical hierarchy of
|
||||
context files.
|
||||
- **[System prompt override](./cli/system-prompt.md):** Instruction replacement
|
||||
logic.
|
||||
- **[Themes](./cli/themes.md):** UI personalization technical guide.
|
||||
- **[Trusted folders](./cli/trusted-folders.md):** Security permission logic.
|
||||
|
||||
## Reference
|
||||
|
||||
Deep technical documentation and API specifications.
|
||||
|
||||
- **[Command reference](./reference/commands.md):** Detailed slash command
|
||||
guide.
|
||||
- **[Configuration reference](./reference/configuration.md):** Settings and
|
||||
environment variables.
|
||||
- **[Keyboard shortcuts](./reference/keyboard-shortcuts.md):** Productivity
|
||||
tips.
|
||||
- **[Memory import processor](./reference/memport.md):** How Gemini CLI
|
||||
processes memory from various sources.
|
||||
- **[Policy engine](./reference/policy-engine.md):** Fine-grained execution
|
||||
control.
|
||||
- **[Tools reference](./reference/tools.md):** Information on how tools are
|
||||
defined, registered, and used.
|
||||
|
||||
## Resources
|
||||
|
||||
Support, release history, and legal information.
|
||||
|
||||
- **[FAQ](./resources/faq.md):** Answers to frequently asked questions.
|
||||
- **[Quota and pricing](./resources/quota-and-pricing.md):** Limits and billing
|
||||
details.
|
||||
- **[Terms and privacy](./resources/tos-privacy.md):** Official notices and
|
||||
terms.
|
||||
- **[Troubleshooting](./resources/troubleshooting.md):** Common issues and
|
||||
solutions.
|
||||
- **[Uninstall](./resources/uninstall.md):** How to uninstall Gemini CLI.
|
||||
|
||||
## Development
|
||||
|
||||
- **[Contribution guide](/docs/contributing):** How to contribute to Gemini CLI.
|
||||
- **[Integration testing](./integration-tests.md):** Running integration tests.
|
||||
- **[Issue and PR automation](./issue-and-pr-automation.md):** Automation for
|
||||
issues and pull requests.
|
||||
- **[Local development](./local-development.md):** Setting up a local
|
||||
development environment.
|
||||
- **[NPM package structure](./npm.md):** The structure of the NPM packages.
|
||||
|
||||
## Releases
|
||||
|
||||
- **[Release notes](./changelogs/index.md):** Release notes for all versions.
|
||||
- **[Stable release](./changelogs/latest.md):** The latest stable release.
|
||||
- **[Preview release](./changelogs/preview.md):** The latest preview release.
|
||||
@@ -0,0 +1,293 @@
|
||||
# Integration tests
|
||||
|
||||
This document provides information about the integration testing framework used
|
||||
in this project.
|
||||
|
||||
## Overview
|
||||
|
||||
The integration tests are designed to validate the end-to-end functionality of
|
||||
Gemini CLI. They execute the built binary in a controlled environment and verify
|
||||
that it behaves as expected when interacting with the file system.
|
||||
|
||||
These tests are located in the `integration-tests` directory and are run using a
|
||||
custom test runner.
|
||||
|
||||
## Building the tests
|
||||
|
||||
Prior to running any integration tests, you need to create a release bundle that
|
||||
you want to actually test:
|
||||
|
||||
```bash
|
||||
npm run bundle
|
||||
```
|
||||
|
||||
You must re-run this command after making any changes to the CLI source code,
|
||||
but not after making changes to tests.
|
||||
|
||||
## Running the tests
|
||||
|
||||
The integration tests are not run as part of the default `npm run test` command.
|
||||
They must be run explicitly using the `npm run test:integration:all` script.
|
||||
|
||||
The integration tests can also be run using the following shortcut:
|
||||
|
||||
```bash
|
||||
npm run test:e2e
|
||||
```
|
||||
|
||||
## Running a specific set of tests
|
||||
|
||||
To run a subset of test files, you can use
|
||||
`npm run <integration test command> <file_name1> ....` where <integration
|
||||
test command> is either `test:e2e` or `test:integration*` and `<file_name>`
|
||||
is any of the `.test.js` files in the `integration-tests/` directory. For
|
||||
example, the following command runs `list_directory.test.js` and
|
||||
`write_file.test.js`:
|
||||
|
||||
```bash
|
||||
npm run test:e2e list_directory write_file
|
||||
```
|
||||
|
||||
### Running a single test by name
|
||||
|
||||
To run a single test by its name, use the `--test-name-pattern` flag:
|
||||
|
||||
```bash
|
||||
npm run test:e2e -- --test-name-pattern "reads a file"
|
||||
```
|
||||
|
||||
### Regenerating model responses
|
||||
|
||||
Some integration tests use faked out model responses, which may need to be
|
||||
regenerated from time to time as the implementations change.
|
||||
|
||||
To regenerate these golden files, set the REGENERATE_MODEL_GOLDENS environment
|
||||
variable to "true" when running the tests, for example:
|
||||
|
||||
**WARNING**: If running locally you should review these updated responses for
|
||||
any information about yourself or your system that gemini may have included in
|
||||
these responses.
|
||||
|
||||
```bash
|
||||
REGENERATE_MODEL_GOLDENS="true" npm run test:e2e
|
||||
```
|
||||
|
||||
**WARNING**: Make sure you run **await rig.cleanup()** at the end of your test,
|
||||
else the golden files will not be updated.
|
||||
|
||||
### Deflaking a test
|
||||
|
||||
Before adding a **new** integration test, you should test it at least 5 times
|
||||
with the deflake script or workflow to make sure that it is not flaky.
|
||||
|
||||
### Deflake script
|
||||
|
||||
```bash
|
||||
npm run deflake -- --runs=5 --command="npm run test:e2e -- -- --test-name-pattern '<your-new-test-name>'"
|
||||
```
|
||||
|
||||
#### Deflake workflow
|
||||
|
||||
```bash
|
||||
gh workflow run deflake.yml --ref <your-branch> -f test_name_pattern="<your-test-name-pattern>"
|
||||
```
|
||||
|
||||
### Running all tests
|
||||
|
||||
To run the entire suite of integration tests, use the following command:
|
||||
|
||||
```bash
|
||||
npm run test:integration:all
|
||||
```
|
||||
|
||||
### Sandbox matrix
|
||||
|
||||
The `all` command will run tests for `no sandboxing`, `docker` and `podman`.
|
||||
Each individual type can be run using the following commands:
|
||||
|
||||
```bash
|
||||
npm run test:integration:sandbox:none
|
||||
```
|
||||
|
||||
```bash
|
||||
npm run test:integration:sandbox:docker
|
||||
```
|
||||
|
||||
```bash
|
||||
npm run test:integration:sandbox:podman
|
||||
```
|
||||
|
||||
## Memory regression tests
|
||||
|
||||
Memory regression tests are designed to detect heap growth and leaks across key
|
||||
CLI scenarios. They are located in the `memory-tests` directory.
|
||||
|
||||
These tests are distinct from standard integration tests because they measure
|
||||
memory usage and compare it against committed baselines.
|
||||
|
||||
### Running memory tests
|
||||
|
||||
Memory tests are not run as part of the default `npm run test` or
|
||||
`npm run test:e2e` commands. They are run nightly in CI but can be run manually:
|
||||
|
||||
```bash
|
||||
npm run test:memory
|
||||
```
|
||||
|
||||
### Updating baselines
|
||||
|
||||
If you intentionally change behavior that affects memory usage, you may need to
|
||||
update the baselines. Set the `UPDATE_MEMORY_BASELINES` environment variable to
|
||||
`true`:
|
||||
|
||||
```bash
|
||||
UPDATE_MEMORY_BASELINES=true npm run test:memory
|
||||
```
|
||||
|
||||
This will run the tests, take median snapshots, and overwrite
|
||||
`memory-tests/baselines.json`. You should review the changes and commit the
|
||||
updated baseline file.
|
||||
|
||||
### How it works
|
||||
|
||||
The harness (`MemoryTestHarness` in `packages/test-utils`):
|
||||
|
||||
- Forces garbage collection multiple times to reduce noise.
|
||||
- Takes median snapshots to filter spikes.
|
||||
- Compares against baselines with a 10% tolerance.
|
||||
- Can analyze sustained leaks across 3 snapshots using `analyzeSnapshots()`.
|
||||
|
||||
## Performance regression tests
|
||||
|
||||
Performance regression tests are designed to detect wall-clock time, CPU usage,
|
||||
and event loop delay regressions across key CLI scenarios. They are located in
|
||||
the `perf-tests` directory.
|
||||
|
||||
These tests are distinct from standard integration tests because they measure
|
||||
performance metrics and compare it against committed baselines.
|
||||
|
||||
### Running performance tests
|
||||
|
||||
Performance tests are not run as part of the default `npm run test` or
|
||||
`npm run test:e2e` commands. They are run nightly in CI but can be run manually:
|
||||
|
||||
```bash
|
||||
npm run test:perf
|
||||
```
|
||||
|
||||
### Updating baselines
|
||||
|
||||
If you intentionally change behavior that affects performance, you may need to
|
||||
update the baselines. Set the `UPDATE_PERF_BASELINES` environment variable to
|
||||
`true`:
|
||||
|
||||
```bash
|
||||
UPDATE_PERF_BASELINES=true npm run test:perf
|
||||
```
|
||||
|
||||
This will run the tests multiple times (with warmup), apply IQR outlier
|
||||
filtering, and overwrite `perf-tests/baselines.json`. You should review the
|
||||
changes and commit the updated baseline file.
|
||||
|
||||
### How it works
|
||||
|
||||
The harness (`PerfTestHarness` in `packages/test-utils`):
|
||||
|
||||
- Measures wall-clock time using `performance.now()`.
|
||||
- Measures CPU usage using `process.cpuUsage()`.
|
||||
- Monitors event loop delay using `perf_hooks.monitorEventLoopDelay()`.
|
||||
- Applies IQR (Interquartile Range) filtering to remove outlier samples.
|
||||
- Compares against baselines with a 15% tolerance.
|
||||
|
||||
## Diagnostics
|
||||
|
||||
The integration test runner provides several options for diagnostics to help
|
||||
track down test failures.
|
||||
|
||||
### Keeping test output
|
||||
|
||||
You can preserve the temporary files created during a test run for inspection.
|
||||
This is useful for debugging issues with file system operations.
|
||||
|
||||
To keep the test output set the `KEEP_OUTPUT` environment variable to `true`.
|
||||
|
||||
```bash
|
||||
KEEP_OUTPUT=true npm run test:integration:sandbox:none
|
||||
```
|
||||
|
||||
When output is kept, the test runner will print the path to the unique directory
|
||||
for the test run.
|
||||
|
||||
### Verbose output
|
||||
|
||||
For more detailed debugging, set the `VERBOSE` environment variable to `true`.
|
||||
|
||||
```bash
|
||||
VERBOSE=true npm run test:integration:sandbox:none
|
||||
```
|
||||
|
||||
When using `VERBOSE=true` and `KEEP_OUTPUT=true` in the same command, the output
|
||||
is streamed to the console and also saved to a log file within the test's
|
||||
temporary directory.
|
||||
|
||||
The verbose output is formatted to clearly identify the source of the logs:
|
||||
|
||||
```
|
||||
--- TEST: <log dir>:<test-name> ---
|
||||
... output from the gemini command ...
|
||||
--- END TEST: <log dir>:<test-name> ---
|
||||
```
|
||||
|
||||
## Linting and formatting
|
||||
|
||||
To ensure code quality and consistency, the integration test files are linted as
|
||||
part of the main build process. You can also manually run the linter and
|
||||
auto-fixer.
|
||||
|
||||
### Running the linter
|
||||
|
||||
To check for linting errors, run the following command:
|
||||
|
||||
```bash
|
||||
npm run lint
|
||||
```
|
||||
|
||||
You can include the `:fix` flag in the command to automatically fix any fixable
|
||||
linting errors:
|
||||
|
||||
```bash
|
||||
npm run lint:fix
|
||||
```
|
||||
|
||||
## Directory structure
|
||||
|
||||
The integration tests create a unique directory for each test run inside the
|
||||
`.integration-tests` directory. Within this directory, a subdirectory is created
|
||||
for each test file, and within that, a subdirectory is created for each
|
||||
individual test case.
|
||||
|
||||
This structure makes it easy to locate the artifacts for a specific test run,
|
||||
file, or case.
|
||||
|
||||
```
|
||||
.integration-tests/
|
||||
└── <run-id>/
|
||||
└── <test-file-name>.test.js/
|
||||
└── <test-case-name>/
|
||||
├── output.log
|
||||
└── ...other test artifacts...
|
||||
```
|
||||
|
||||
## Continuous integration
|
||||
|
||||
To ensure the integration tests are always run, a GitHub Actions workflow is
|
||||
defined in `.github/workflows/chained_e2e.yml`. This workflow automatically runs
|
||||
the integrations tests for pull requests against the `main` branch, or when a
|
||||
pull request is added to a merge queue.
|
||||
|
||||
The workflow runs the tests in different sandboxing environments to ensure
|
||||
Gemini CLI is tested across each:
|
||||
|
||||
- `sandbox:none`: Runs the tests without any sandboxing.
|
||||
- `sandbox:docker`: Runs the tests in a Docker container.
|
||||
- `sandbox:podman`: Runs the tests in a Podman container.
|
||||
@@ -0,0 +1,203 @@
|
||||
# Automation and triage processes
|
||||
|
||||
This document provides a detailed overview of the automated processes we use to
|
||||
manage and triage issues and pull requests. Our goal is to provide prompt
|
||||
feedback and ensure that contributions are reviewed and integrated efficiently.
|
||||
Understanding this automation will help you as a contributor know what to expect
|
||||
and how to best interact with our repository bots.
|
||||
|
||||
## Guiding principle: Issues and pull requests
|
||||
|
||||
First and foremost, almost every Pull Request (PR) should be linked to a
|
||||
corresponding Issue. The issue describes the "what" and the "why" (the bug or
|
||||
feature), while the PR is the "how" (the implementation). This separation helps
|
||||
us track work, prioritize features, and maintain clear historical context. Our
|
||||
automation is built around this principle.
|
||||
|
||||
<!-- prettier-ignore -->
|
||||
> [!NOTE]
|
||||
> Issues tagged as "🔒Maintainers only" are reserved for project
|
||||
> maintainers. We will not accept pull requests related to these issues.
|
||||
|
||||
---
|
||||
|
||||
## Detailed automation workflows
|
||||
|
||||
Here is a breakdown of the specific automation workflows that run in our
|
||||
repository.
|
||||
|
||||
### 1. When you open an issue: `Automated Issue Triage`
|
||||
|
||||
This is the first bot you will interact with when you create an issue. Its job
|
||||
is to perform an initial analysis and apply the correct labels.
|
||||
|
||||
- **Workflow File**: `.github/workflows/gemini-automated-issue-triage.yml`
|
||||
- **When it runs**: Immediately after an issue is created or reopened.
|
||||
- **What it does**:
|
||||
- It uses a Gemini model to analyze the issue's title and body against a
|
||||
detailed set of guidelines.
|
||||
- **Applies one `area/*` label**: Categorizes the issue into a functional area
|
||||
of the project (for example, `area/ux`, `area/models`, `area/platform`).
|
||||
- **Applies one `kind/*` label**: Identifies the type of issue (for example,
|
||||
`kind/bug`, `kind/enhancement`, `kind/question`).
|
||||
- **Applies one `priority/*` label**: Assigns a priority from P0 (critical) to
|
||||
P3 (low) based on the described impact.
|
||||
- **May apply `status/need-information`**: If the issue lacks critical details
|
||||
(like logs or reproduction steps), it will be flagged for more information.
|
||||
- **May apply `status/need-retesting`**: If the issue references a CLI version
|
||||
that is more than six versions old, it will be flagged for retesting on a
|
||||
current version.
|
||||
- **What you should do**:
|
||||
- Fill out the issue template as completely as possible. The more detail you
|
||||
provide, the more accurate the triage will be.
|
||||
- If the `status/need-information` label is added, provide the requested
|
||||
details in a comment.
|
||||
|
||||
### 2. When you open a pull request: `Continuous Integration (CI)`
|
||||
|
||||
This workflow ensures that all changes meet our quality standards before they
|
||||
can be merged.
|
||||
|
||||
- **Workflow File**: `.github/workflows/ci.yml`
|
||||
- **When it runs**: On every push to a pull request.
|
||||
- **What it does**:
|
||||
- **Lint**: Checks that your code adheres to our project's formatting and
|
||||
style rules.
|
||||
- **Test**: Runs our full suite of automated tests across macOS, Windows, and
|
||||
Linux, and on multiple Node.js versions. This is the most time-consuming
|
||||
part of the CI process.
|
||||
- **Post Coverage Comment**: After all tests have successfully passed, a bot
|
||||
will post a comment on your PR. This comment provides a summary of how well
|
||||
your changes are covered by tests.
|
||||
- **What you should do**:
|
||||
- Ensure all CI checks pass. A green checkmark ✅ will appear next to your
|
||||
commit when everything is successful.
|
||||
- If a check fails (a red "X" ❌), click the "Details" link next to the failed
|
||||
check to view the logs, identify the problem, and push a fix.
|
||||
|
||||
### 3. Ongoing triage for pull requests: `PR Auditing and Label Sync`
|
||||
|
||||
This workflow runs periodically to ensure all open PRs are correctly linked to
|
||||
issues and have consistent labels.
|
||||
|
||||
- **Workflow File**: `.github/workflows/gemini-scheduled-pr-triage.yml`
|
||||
- **When it runs**: Every 15 minutes on all open pull requests.
|
||||
- **What it does**:
|
||||
- **Checks for a linked issue**: The bot scans your PR description for a
|
||||
keyword that links it to an issue (for example, `Fixes #123`,
|
||||
`Closes #456`).
|
||||
- **Adds `status/need-issue`**: If no linked issue is found, the bot will add
|
||||
the `status/need-issue` label to your PR. This is a clear signal that an
|
||||
issue needs to be created and linked.
|
||||
- **Synchronizes labels**: If an issue _is_ linked, the bot ensures the PR's
|
||||
labels perfectly match the issue's labels. It will add any missing labels
|
||||
and remove any that don't belong, and it will remove the `status/need-issue`
|
||||
label if it was present.
|
||||
- **What you should do**:
|
||||
- **Always link your PR to an issue.** This is the most important step. Add a
|
||||
line like `Resolves #<issue-number>` to your PR description.
|
||||
- This will ensure your PR is correctly categorized and moves through the
|
||||
review process smoothly.
|
||||
|
||||
### 4. Ongoing triage for issues: `Scheduled Issue Triage`
|
||||
|
||||
This is a fallback workflow to ensure that no issue gets missed by the triage
|
||||
process.
|
||||
|
||||
- **Workflow File**: `.github/workflows/gemini-scheduled-issue-triage.yml`
|
||||
- **When it runs**: Every hour on all open issues.
|
||||
- **What it does**:
|
||||
- It actively seeks out issues that either have no labels at all or still have
|
||||
the `status/need-triage` label.
|
||||
- It then triggers the same powerful Gemini-based analysis as the initial
|
||||
triage bot to apply the correct labels.
|
||||
- **What you should do**:
|
||||
- You typically don't need to do anything. This workflow is a safety net to
|
||||
ensure every issue is eventually categorized, even if the initial triage
|
||||
fails.
|
||||
|
||||
### 5. Automatic unassignment of inactive contributors: `Unassign Inactive Issue Assignees`
|
||||
|
||||
To keep the list of open `help wanted` issues accessible to all contributors,
|
||||
this workflow automatically removes **external contributors** who have not
|
||||
opened a linked pull request within **7 days** of being assigned. Maintainers,
|
||||
org members, and repo collaborators with write access or above are always exempt
|
||||
and will never be auto-unassigned.
|
||||
|
||||
- **Workflow File**: `.github/workflows/unassign-inactive-assignees.yml`
|
||||
- **When it runs**: Every day at 09:00 UTC, and can be triggered manually with
|
||||
an optional `dry_run` mode.
|
||||
- **What it does**:
|
||||
1. Finds every open issue labeled `help wanted` that has at least one
|
||||
assignee.
|
||||
2. Identifies privileged users (team members, repo collaborators with write+
|
||||
access, maintainers) and skips them entirely.
|
||||
3. For each remaining (external) assignee it reads the issue's timeline to
|
||||
determine:
|
||||
- The exact date they were assigned (using `assigned` timeline events).
|
||||
- Whether they have opened a PR that is already linked/cross-referenced to
|
||||
the issue.
|
||||
4. Each cross-referenced PR is fetched to verify it is **ready for review**:
|
||||
open and non-draft, or already merged. Draft PRs do not count.
|
||||
5. If an assignee has been assigned for **more than 7 days** and no qualifying
|
||||
PR is found, they are automatically unassigned and a comment is posted
|
||||
explaining the reason and how to re-claim the issue.
|
||||
6. Assignees who have a non-draft, open or merged PR linked to the issue are
|
||||
**never** unassigned by this workflow.
|
||||
- **What you should do**:
|
||||
- **Open a real PR, not a draft**: Within 7 days of being assigned, open a PR
|
||||
that is ready for review and include `Fixes #<issue-number>` in the
|
||||
description. Draft PRs do not satisfy the requirement and will not prevent
|
||||
auto-unassignment.
|
||||
- **Re-assign if unassigned by mistake**: Comment `/assign` on the issue to
|
||||
assign yourself again.
|
||||
- **Unassign yourself** if you can no longer work on the issue by commenting
|
||||
`/unassign`, so other contributors can pick it up right away.
|
||||
|
||||
### 6. Automatically label PRs by size: `PR Size Labeler`
|
||||
|
||||
To help maintainers estimate review effort and keep the PR history clean, this
|
||||
workflow automatically tags every pull request with a size label representing
|
||||
the total volume of line changes.
|
||||
|
||||
- **Workflow File**: `.github/workflows/pr-size-labeler.yml`
|
||||
- **When it runs**: Immediately after a pull request is created, synchronized
|
||||
(new commits pushed), or reopened. It can also be triggered manually via
|
||||
`workflow_dispatch` with a PR number.
|
||||
- **What it does**:
|
||||
- **Calculates total changes**: Summarizes additions and deletions across all
|
||||
changed files in a single consolidated API request.
|
||||
- **Applies standard size labels**:
|
||||
- `size/XS`: < 10 lines changed
|
||||
- `size/S`: 10-49 lines changed
|
||||
- `size/M`: 50-249 lines changed
|
||||
- `size/L`: 250-999 lines changed
|
||||
- `size/XL`: >= 1000 lines changed
|
||||
- **Updates size tag atomically**: Adds the new correct size label and removes
|
||||
any obsolete size labels in one atomic step.
|
||||
- **Updates/Posts PR size info comment**: Instead of spamming a new comment on
|
||||
every commit push, it updates the existing size labeler status comment
|
||||
inline to keep the PR conversation timeline perfectly neat and clean.
|
||||
- **What you should do**:
|
||||
- You do not need to take any actions. The workflow runs automatically and
|
||||
updates the label and comment seamlessly as you push new updates.
|
||||
|
||||
### 7. Release automation
|
||||
|
||||
This workflow handles the process of packaging and publishing new versions of
|
||||
Gemini CLI.
|
||||
|
||||
- **Workflow File**: `.github/workflows/release-manual.yml`
|
||||
- **When it runs**: On a daily schedule for "nightly" releases, and manually for
|
||||
official patch/minor releases.
|
||||
- **What it does**:
|
||||
- Automatically builds the project, bumps the version numbers, and publishes
|
||||
the packages to npm.
|
||||
- Creates a corresponding release on GitHub with generated release notes.
|
||||
- **What you should do**:
|
||||
- As a contributor, you don't need to do anything for this process. You can be
|
||||
confident that once your PR is merged into the `main` branch, your changes
|
||||
will be included in the very next nightly release.
|
||||
|
||||
We hope this detailed overview is helpful. If you have any questions about our
|
||||
automation or processes, don't hesitate to ask!
|
||||
@@ -0,0 +1,182 @@
|
||||
# Local development guide
|
||||
|
||||
This guide provides instructions for setting up and using local development
|
||||
features for Gemini CLI.
|
||||
|
||||
## Tracing
|
||||
|
||||
Gemini CLI uses OpenTelemetry (OTel) to record traces that help you debug agent
|
||||
behavior. Traces instrument key events like model calls, tool scheduler
|
||||
operations, and tool calls.
|
||||
|
||||
Traces provide deep visibility into agent behavior and help you debug complex
|
||||
issues. They are captured automatically when you enable telemetry.
|
||||
|
||||
### View traces
|
||||
|
||||
You can view traces using Genkit Developer UI, Jaeger, or Google Cloud.
|
||||
|
||||
#### Use Genkit
|
||||
|
||||
Genkit provides a web-based UI for viewing traces and other telemetry data.
|
||||
|
||||
1. **Start the Genkit telemetry server:**
|
||||
|
||||
Run the following command to start the Genkit server:
|
||||
|
||||
```bash
|
||||
npm run telemetry -- --target=genkit
|
||||
```
|
||||
|
||||
The script will output the URL for the Genkit Developer UI. For example:
|
||||
`Genkit Developer UI: http://localhost:4000`
|
||||
|
||||
2. **Run Gemini CLI:**
|
||||
|
||||
In a separate terminal, run your Gemini CLI command:
|
||||
|
||||
```bash
|
||||
gemini
|
||||
```
|
||||
|
||||
3. **View the traces:**
|
||||
|
||||
Open the Genkit Developer UI URL in your browser and navigate to the
|
||||
**Traces** tab to view the traces.
|
||||
|
||||
#### Use Jaeger
|
||||
|
||||
You can view traces in the Jaeger UI for local development.
|
||||
|
||||
1. **Start the telemetry collector:**
|
||||
|
||||
Run the following command in your terminal to download and start Jaeger and
|
||||
an OTel collector:
|
||||
|
||||
```bash
|
||||
npm run telemetry -- --target=local
|
||||
```
|
||||
|
||||
This command configures your workspace for local telemetry and provides a
|
||||
link to the Jaeger UI (usually `http://localhost:16686`).
|
||||
|
||||
- **Collector logs:** `~/.gemini/tmp/<projectHash>/otel/collector.log`
|
||||
|
||||
2. **Run Gemini CLI:**
|
||||
|
||||
In a separate terminal, run your Gemini CLI command:
|
||||
|
||||
```bash
|
||||
gemini
|
||||
```
|
||||
|
||||
3. **View the traces:**
|
||||
|
||||
After running your command, open the Jaeger UI link in your browser to view
|
||||
the traces.
|
||||
|
||||
#### Use Google Cloud
|
||||
|
||||
You can use an OpenTelemetry collector to forward telemetry data to Google Cloud
|
||||
Trace for custom processing or routing.
|
||||
|
||||
<!-- prettier-ignore -->
|
||||
> [!WARNING]
|
||||
> Ensure you complete the
|
||||
> [Google Cloud telemetry prerequisites](./cli/telemetry.md#prerequisites)
|
||||
> (Project ID, authentication, IAM roles, and APIs) before using this method.
|
||||
|
||||
1. **Configure `.gemini/settings.json`:**
|
||||
|
||||
```json
|
||||
{
|
||||
"telemetry": {
|
||||
"enabled": true,
|
||||
"target": "gcp",
|
||||
"useCollector": true
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
2. **Start the telemetry collector:**
|
||||
|
||||
Run the following command to start a local OTel collector that forwards to
|
||||
Google Cloud:
|
||||
|
||||
```bash
|
||||
npm run telemetry -- --target=gcp
|
||||
```
|
||||
|
||||
The script outputs links to view traces, metrics, and logs in the Google
|
||||
Cloud Console.
|
||||
|
||||
- **Collector logs:** `~/.gemini/tmp/<projectHash>/otel/collector-gcp.log`
|
||||
|
||||
3. **Run Gemini CLI:**
|
||||
|
||||
In a separate terminal, run your Gemini CLI command:
|
||||
|
||||
```bash
|
||||
gemini
|
||||
```
|
||||
|
||||
4. **View logs, metrics, and traces:**
|
||||
|
||||
After sending prompts, view your data in the Google Cloud Console. See the
|
||||
[telemetry documentation](./cli/telemetry.md#view-google-cloud-telemetry)
|
||||
for links to Logs, Metrics, and Trace explorers.
|
||||
|
||||
For more detailed information on telemetry, see the
|
||||
[telemetry documentation](./cli/telemetry.md).
|
||||
|
||||
### Instrument code with traces
|
||||
|
||||
You can add traces to your own code for more detailed instrumentation.
|
||||
|
||||
Adding traces helps you debug and understand the flow of execution. Use the
|
||||
`runInDevTraceSpan` function to wrap any section of code in a trace span.
|
||||
|
||||
Here is a basic example:
|
||||
|
||||
```typescript
|
||||
import { runInDevTraceSpan } from '@google/gemini-cli-core';
|
||||
import { GeminiCliOperation } from '@google/gemini-cli-core/lib/telemetry/constants.js';
|
||||
|
||||
await runInDevTraceSpan(
|
||||
{
|
||||
operation: GeminiCliOperation.ToolCall,
|
||||
attributes: {
|
||||
[GEN_AI_AGENT_NAME]: 'gemini-cli',
|
||||
},
|
||||
},
|
||||
async ({ metadata }) => {
|
||||
// metadata allows you to record the input and output of the
|
||||
// operation as well as other attributes.
|
||||
metadata.input = { key: 'value' };
|
||||
// Set custom attributes.
|
||||
metadata.attributes['custom.attribute'] = 'custom.value';
|
||||
|
||||
// Your code to be traced goes here.
|
||||
try {
|
||||
const output = await somethingRisky();
|
||||
metadata.output = output;
|
||||
return output;
|
||||
} catch (e) {
|
||||
metadata.error = e;
|
||||
throw e;
|
||||
}
|
||||
},
|
||||
);
|
||||
```
|
||||
|
||||
In this example:
|
||||
|
||||
- `operation`: The operation type of the span, represented by the
|
||||
`GeminiCliOperation` enum.
|
||||
- `metadata.input`: (Optional) An object containing the input data for the
|
||||
traced operation.
|
||||
- `metadata.output`: (Optional) An object containing the output data from the
|
||||
traced operation.
|
||||
- `metadata.attributes`: (Optional) A record of custom attributes to add to the
|
||||
span.
|
||||
- `metadata.error`: (Optional) An error object to record if the operation fails.
|
||||
@@ -0,0 +1,103 @@
|
||||
graph LR
|
||||
%% --- Style Definitions ---
|
||||
classDef new fill:#98fb98,color:#000
|
||||
classDef changed fill:#add8e6,color:#000
|
||||
classDef unchanged fill:#f0f0f0,color:#000
|
||||
|
||||
%% --- Subgraphs ---
|
||||
subgraph "Context Providers"
|
||||
direction TB
|
||||
A["gemini.tsx"]
|
||||
B["AppContainer.tsx"]
|
||||
end
|
||||
|
||||
subgraph "Contexts"
|
||||
direction TB
|
||||
CtxSession["SessionContext"]
|
||||
CtxVim["VimModeContext"]
|
||||
CtxSettings["SettingsContext"]
|
||||
CtxApp["AppContext"]
|
||||
CtxConfig["ConfigContext"]
|
||||
CtxUIState["UIStateContext"]
|
||||
CtxUIActions["UIActionsContext"]
|
||||
end
|
||||
|
||||
subgraph "Component Consumers"
|
||||
direction TB
|
||||
ConsumerApp["App"]
|
||||
ConsumerAppContainer["AppContainer"]
|
||||
ConsumerAppHeader["AppHeader"]
|
||||
ConsumerDialogManager["DialogManager"]
|
||||
ConsumerHistoryItem["HistoryItemDisplay"]
|
||||
ConsumerComposer["Composer"]
|
||||
ConsumerMainContent["MainContent"]
|
||||
ConsumerNotifications["Notifications"]
|
||||
end
|
||||
|
||||
%% --- Provider -> Context Connections ---
|
||||
A -.-> CtxSession
|
||||
A -.-> CtxVim
|
||||
A -.-> CtxSettings
|
||||
|
||||
B -.-> CtxApp
|
||||
B -.-> CtxConfig
|
||||
B -.-> CtxUIState
|
||||
B -.-> CtxUIActions
|
||||
B -.-> CtxSettings
|
||||
|
||||
%% --- Context -> Consumer Connections ---
|
||||
CtxSession -.-> ConsumerAppContainer
|
||||
CtxSession -.-> ConsumerApp
|
||||
|
||||
CtxVim -.-> ConsumerAppContainer
|
||||
CtxVim -.-> ConsumerComposer
|
||||
CtxVim -.-> ConsumerApp
|
||||
|
||||
CtxSettings -.-> ConsumerAppContainer
|
||||
CtxSettings -.-> ConsumerAppHeader
|
||||
CtxSettings -.-> ConsumerDialogManager
|
||||
CtxSettings -.-> ConsumerApp
|
||||
|
||||
CtxApp -.-> ConsumerAppHeader
|
||||
CtxApp -.-> ConsumerNotifications
|
||||
|
||||
CtxConfig -.-> ConsumerAppHeader
|
||||
CtxConfig -.-> ConsumerHistoryItem
|
||||
CtxConfig -.-> ConsumerComposer
|
||||
CtxConfig -.-> ConsumerDialogManager
|
||||
|
||||
|
||||
|
||||
CtxUIState -.-> ConsumerApp
|
||||
CtxUIState -.-> ConsumerMainContent
|
||||
CtxUIState -.-> ConsumerComposer
|
||||
CtxUIState -.-> ConsumerDialogManager
|
||||
|
||||
CtxUIActions -.-> ConsumerComposer
|
||||
CtxUIActions -.-> ConsumerDialogManager
|
||||
|
||||
%% --- Apply Styles ---
|
||||
%% New Elements (Green)
|
||||
class B,CtxApp,CtxConfig,CtxUIState,CtxUIActions,ConsumerAppHeader,ConsumerDialogManager,ConsumerComposer,ConsumerMainContent,ConsumerNotifications new
|
||||
|
||||
%% Heavily Changed Elements (Blue)
|
||||
class A,ConsumerApp,ConsumerAppContainer,ConsumerHistoryItem changed
|
||||
|
||||
%% Mostly Unchanged Elements (Gray)
|
||||
class CtxSession,CtxVim,CtxSettings unchanged
|
||||
|
||||
%% --- Link Styles ---
|
||||
%% CtxSession (Red)
|
||||
linkStyle 0,8,9 stroke:#e57373,stroke-width:2px
|
||||
%% CtxVim (Orange)
|
||||
linkStyle 1,10,11,12 stroke:#ffb74d,stroke-width:2px
|
||||
%% CtxSettings (Yellow)
|
||||
linkStyle 2,7,13,14,15,16 stroke:#fff176,stroke-width:2px
|
||||
%% CtxApp (Green)
|
||||
linkStyle 3,17,18 stroke:#81c784,stroke-width:2px
|
||||
%% CtxConfig (Blue)
|
||||
linkStyle 4,19,20,21,22 stroke:#64b5f6,stroke-width:2px
|
||||
%% CtxUIState (Indigo)
|
||||
linkStyle 5,23,24,25,26 stroke:#7986cb,stroke-width:2px
|
||||
%% CtxUIActions (Violet)
|
||||
linkStyle 6,27,28 stroke:#ba68c8,stroke-width:2px
|
||||
@@ -0,0 +1,64 @@
|
||||
graph TD
|
||||
%% --- Style Definitions ---
|
||||
classDef new fill:#98fb98,color:#000
|
||||
classDef changed fill:#add8e6,color:#000
|
||||
classDef unchanged fill:#f0f0f0,color:#000
|
||||
classDef dispatcher fill:#f9e79f,color:#000,stroke:#333,stroke-width:1px
|
||||
classDef container fill:#f5f5f5,color:#000,stroke:#ccc
|
||||
|
||||
%% --- Component Tree ---
|
||||
subgraph "Entry Point"
|
||||
A["gemini.tsx"]
|
||||
end
|
||||
|
||||
subgraph "State & Logic Wrapper"
|
||||
B["AppContainer.tsx"]
|
||||
end
|
||||
|
||||
subgraph "Primary Layout"
|
||||
C["App.tsx"]
|
||||
end
|
||||
|
||||
A -.-> B
|
||||
B -.-> C
|
||||
|
||||
subgraph "UI Containers"
|
||||
direction LR
|
||||
C -.-> D["MainContent"]
|
||||
C -.-> G["Composer"]
|
||||
C -.-> F["DialogManager"]
|
||||
C -.-> E["Notifications"]
|
||||
end
|
||||
|
||||
subgraph "MainContent"
|
||||
direction TB
|
||||
D -.-> H["AppHeader"]
|
||||
D -.-> I["HistoryItemDisplay"]:::dispatcher
|
||||
D -.-> L["ShowMoreLines"]
|
||||
end
|
||||
|
||||
subgraph "Composer"
|
||||
direction TB
|
||||
G -.-> K_Prompt["InputPrompt"]
|
||||
G -.-> K_Footer["Footer"]
|
||||
end
|
||||
|
||||
subgraph "DialogManager"
|
||||
F -.-> J["Various Dialogs<br>(Auth, Theme, Settings, etc.)"]
|
||||
end
|
||||
|
||||
%% --- Apply Styles ---
|
||||
class B,D,E,F,G,H,J,K_Prompt,L new
|
||||
class A,C,I changed
|
||||
class K_Footer unchanged
|
||||
|
||||
%% --- Link Styles ---
|
||||
%% MainContent Branch (Blue)
|
||||
linkStyle 2,6,7,8 stroke:#64b5f6,stroke-width:2px
|
||||
%% Composer Branch (Green)
|
||||
linkStyle 3,9,10 stroke:#81c784,stroke-width:2px
|
||||
%% DialogManager Branch (Orange)
|
||||
linkStyle 4,11 stroke:#ffb74d,stroke-width:2px
|
||||
%% Notifications Branch (Violet)
|
||||
linkStyle 5 stroke:#ba68c8,stroke-width:2px
|
||||
|
||||
+62
@@ -0,0 +1,62 @@
|
||||
# Package overview
|
||||
|
||||
This monorepo contains two main packages: `@google/gemini-cli` and
|
||||
`@google/gemini-cli-core`.
|
||||
|
||||
## `@google/gemini-cli`
|
||||
|
||||
This is the main package for Gemini CLI. It is responsible for the user
|
||||
interface, command parsing, and all other user-facing functionality.
|
||||
|
||||
When this package is published, it is bundled into a single executable file.
|
||||
This bundle includes all of the package's dependencies, including
|
||||
`@google/gemini-cli-core`. This means that whether a user installs the package
|
||||
with `npm install -g @google/gemini-cli` or runs it directly with
|
||||
`npx @google/gemini-cli`, they are using this single, self-contained executable.
|
||||
|
||||
## `@google/gemini-cli-core`
|
||||
|
||||
This package contains the core logic for interacting with the Gemini API. It is
|
||||
responsible for making API requests, handling authentication, and managing the
|
||||
local cache.
|
||||
|
||||
This package is not bundled. When it is published, it is published as a standard
|
||||
Node.js package with its own dependencies. This allows it to be used as a
|
||||
standalone package in other projects, if needed. All transpiled js code in the
|
||||
`dist` folder is included in the package.
|
||||
|
||||
## NPM workspaces
|
||||
|
||||
This project uses
|
||||
[NPM Workspaces](https://docs.npmjs.com/cli/v10/using-npm/workspaces) to manage
|
||||
the packages within this monorepo. This simplifies development by allowing us to
|
||||
manage dependencies and run scripts across multiple packages from the root of
|
||||
the project.
|
||||
|
||||
### How it works
|
||||
|
||||
The root `package.json` file defines the workspaces for this project:
|
||||
|
||||
```json
|
||||
{
|
||||
"workspaces": ["packages/*"]
|
||||
}
|
||||
```
|
||||
|
||||
This tells NPM that any folder inside the `packages` directory is a separate
|
||||
package that should be managed as part of the workspace.
|
||||
|
||||
### Benefits of workspaces
|
||||
|
||||
- **Simplified dependency management**: Running `npm install` from the root of
|
||||
the project will install all dependencies for all packages in the workspace
|
||||
and link them together. This means you don't need to run `npm install` in each
|
||||
package's directory.
|
||||
- **Automatic linking**: Packages within the workspace can depend on each other.
|
||||
When you run `npm install`, NPM will automatically create symlinks between the
|
||||
packages. This means that when you make changes to one package, the changes
|
||||
are immediately available to other packages that depend on it.
|
||||
- **Simplified script execution**: You can run scripts in any package from the
|
||||
root of the project using the `--workspace` flag. For example, to run the
|
||||
`build` script in the `cli` package, you can run
|
||||
`npm run build --workspace @google/gemini-cli`.
|
||||
@@ -0,0 +1,21 @@
|
||||
{
|
||||
"/docs/architecture": "/docs/cli/index",
|
||||
"/docs/cli/commands": "/docs/reference/commands",
|
||||
"/docs/cli": "/docs",
|
||||
"/docs/cli/index": "/docs",
|
||||
"/docs/cli/keyboard-shortcuts": "/docs/reference/keyboard-shortcuts",
|
||||
"/docs/cli/uninstall": "/docs/resources/uninstall",
|
||||
"/docs/core/concepts": "/docs",
|
||||
"/docs/core/memport": "/docs/reference/memport",
|
||||
"/docs/core/policy-engine": "/docs/reference/policy-engine",
|
||||
"/docs/core/tools-api": "/docs/reference/tools",
|
||||
"/docs/reference/tools-api": "/docs/reference/tools",
|
||||
"/docs/faq": "/docs/resources/faq",
|
||||
"/docs/get-started/configuration": "/docs/reference/configuration",
|
||||
"/docs/get-started/configuration-v1": "/docs/reference/configuration",
|
||||
"/docs/get-started/examples": "/docs/get-started/index",
|
||||
"/docs/index": "/docs",
|
||||
"/docs/quota-and-pricing": "/docs/resources/quota-and-pricing",
|
||||
"/docs/tos-privacy": "/docs/resources/tos-privacy",
|
||||
"/docs/troubleshooting": "/docs/resources/troubleshooting"
|
||||
}
|
||||
@@ -0,0 +1,597 @@
|
||||
# CLI commands
|
||||
|
||||
Gemini CLI supports several built-in commands to help you manage your session,
|
||||
customize the interface, and control its behavior. These commands are prefixed
|
||||
with a forward slash (`/`), an at symbol (`@`), or an exclamation mark (`!`).
|
||||
|
||||
## Slash commands (`/`)
|
||||
|
||||
Slash commands provide meta-level control over the CLI itself.
|
||||
|
||||
### Built-in Commands
|
||||
|
||||
### `/about`
|
||||
|
||||
- **Description:** Show version info. Share this information when filing issues.
|
||||
|
||||
### `/agents`
|
||||
|
||||
- **Description:** Manage local and remote subagents.
|
||||
- **Sub-commands:**
|
||||
- **`list`**:
|
||||
- **Description:** Lists all discovered agents, including built-in, local,
|
||||
and remote agents.
|
||||
- **Usage:** `/agents list`
|
||||
- **`reload`** (alias: `refresh`):
|
||||
- **Description:** Rescans agent directories (`~/.gemini/agents` and
|
||||
`.gemini/agents`) and reloads the registry.
|
||||
- **Usage:** `/agents reload`
|
||||
- **`enable`**:
|
||||
- **Description:** Enables a specific subagent.
|
||||
- **Usage:** `/agents enable <agent-name>`
|
||||
- **`disable`**:
|
||||
- **Description:** Disables a specific subagent.
|
||||
- **Usage:** `/agents disable <agent-name>`
|
||||
- **`config`**:
|
||||
- **Description:** Opens a configuration dialog for the specified agent to
|
||||
adjust its model, temperature, or execution limits.
|
||||
- **Usage:** `/agents config <agent-name>`
|
||||
|
||||
### `/auth`
|
||||
|
||||
- **Description:** Open a dialog that lets you change the authentication method.
|
||||
|
||||
### `/bug`
|
||||
|
||||
- **Description:** File an issue about Gemini CLI. By default, the issue is
|
||||
filed within the GitHub repository for Gemini CLI. The string you enter after
|
||||
`/bug` will become the headline for the bug being filed. The default `/bug`
|
||||
behavior can be modified using the `advanced.bugCommand` setting in your
|
||||
`.gemini/settings.json` files.
|
||||
|
||||
### `/chat`
|
||||
|
||||
- **Description:** Alias for `/resume`. Both commands now expose the same
|
||||
session browser action and checkpoint subcommands.
|
||||
- **Menu layout when typing `/chat` (or `/resume`)**:
|
||||
- `-- auto --`
|
||||
- `list` (selecting this opens the auto-saved session browser)
|
||||
- `-- checkpoints --`
|
||||
- `list`, `save`, `resume`, `delete`, `share` (manual tagged checkpoints)
|
||||
- Unique prefixes (for example `/cha` or `/resu`) resolve to the same grouped
|
||||
menu.
|
||||
- **Sub-commands:**
|
||||
- **`debug`**
|
||||
- **Description:** Export the most recent API request as a JSON payload.
|
||||
- **`delete <tag>`**
|
||||
- **Description:** Deletes a saved conversation checkpoint.
|
||||
- **Equivalent:** `/resume delete <tag>`
|
||||
- **`list`**
|
||||
- **Description:** Lists available tags for manually saved checkpoints.
|
||||
- **Note:** This command only lists chats saved within the current project.
|
||||
Because chat history is project-scoped, chats saved in other project
|
||||
directories will not be displayed.
|
||||
- **Equivalent:** `/resume list`
|
||||
- **`resume <tag>`**
|
||||
- **Description:** Resumes a conversation from a previous save.
|
||||
- **Note:** You can only resume chats that were saved within the current
|
||||
project. To resume a chat from a different project, you must run the
|
||||
Gemini CLI from that project's directory.
|
||||
- **Equivalent:** `/resume resume <tag>`
|
||||
- **`save <tag>`**
|
||||
- **Description:** Saves the current conversation history. You must add a
|
||||
`<tag>` for identifying the conversation state.
|
||||
- **Details on checkpoint location:** The default locations for saved chat
|
||||
checkpoints are:
|
||||
- Linux/macOS: `~/.gemini/tmp/<project_hash>/`
|
||||
- Windows: `C:\Users\<YourUsername>\.gemini\tmp\<project_hash>\`
|
||||
- **Behavior:** Chats are saved into a project-specific directory,
|
||||
determined by where you run the CLI. Consequently, saved chats are only
|
||||
accessible when working within that same project.
|
||||
- **Note:** These checkpoints are for manually saving and resuming
|
||||
conversation states. For automatic checkpoints created before file
|
||||
modifications, see the
|
||||
[Checkpointing documentation](../cli/checkpointing.md).
|
||||
- **Equivalent:** `/resume save <tag>`
|
||||
- **`share [filename]`**
|
||||
- **Description:** Writes the current conversation to a provided Markdown or
|
||||
JSON file. If no filename is provided, then the CLI will generate one.
|
||||
- **Usage:** `/chat share file.md` or `/chat share file.json`.
|
||||
- **Equivalent:** `/resume share [filename]`
|
||||
|
||||
### `/clear`
|
||||
|
||||
- **Description:** Clear the terminal screen, including the visible session
|
||||
history and scrollback within the CLI. The underlying session data (for
|
||||
history recall) might be preserved depending on the exact implementation, but
|
||||
the visual display is cleared.
|
||||
- **Keyboard shortcut:** Press **Ctrl+L** at any time to perform a clear action.
|
||||
|
||||
### `/commands`
|
||||
|
||||
- **Description:** Manage custom slash commands loaded from `.toml` files.
|
||||
- **Sub-commands:**
|
||||
- **`list`**:
|
||||
- **Description:** List available custom command `.toml` files from all
|
||||
sources (user-level `~/.gemini/commands/`, project-level
|
||||
`<project>/.gemini/commands/`, and active extensions).
|
||||
- **Usage:** `/commands list`
|
||||
- **`reload`**:
|
||||
- **Description:** Reload custom command definitions from all sources
|
||||
(user-level `~/.gemini/commands/`, project-level
|
||||
`<project>/.gemini/commands/`, MCP prompts, and extensions). Use this to
|
||||
pick up new or modified `.toml` files without restarting the CLI.
|
||||
- **Usage:** `/commands reload`
|
||||
|
||||
### `/compress`
|
||||
|
||||
- **Description:** Replace the entire chat context with a summary. This saves on
|
||||
tokens used for future tasks while retaining a high level summary of what has
|
||||
happened.
|
||||
|
||||
### `/copy`
|
||||
|
||||
- **Description:** Copies the last output produced by Gemini CLI to your
|
||||
clipboard, for easy sharing or reuse.
|
||||
- **Behavior:**
|
||||
- Local sessions use system clipboard tools (pbcopy/xclip/clip).
|
||||
- Remote sessions (SSH/WSL) use OSC 52 and require terminal support.
|
||||
- **Note:** This command requires platform-specific clipboard tools to be
|
||||
installed.
|
||||
- On Linux, it requires `xclip` or `xsel`. You can typically install them
|
||||
using your system's package manager.
|
||||
- On macOS, it requires `pbcopy`, and on Windows, it requires `clip`. These
|
||||
tools are typically pre-installed on their respective systems.
|
||||
|
||||
### `/directory` (or `/dir`)
|
||||
|
||||
- **Description:** Manage workspace directories for multi-directory support.
|
||||
- **Sub-commands:**
|
||||
- **`add`**:
|
||||
- **Description:** Add a directory to the workspace. The path can be
|
||||
absolute or relative to the current working directory. Moreover, the
|
||||
reference from home directory is supported as well.
|
||||
- **Usage:** `/directory add <path1>,<path2>`
|
||||
- **Note:** Disabled in restrictive sandbox profiles. If you're using that,
|
||||
use `--include-directories` when starting the session instead.
|
||||
- **`show`**:
|
||||
- **Description:** Display all directories added by `/directory add` and
|
||||
`--include-directories`.
|
||||
- **Usage:** `/directory show`
|
||||
|
||||
### `/docs`
|
||||
|
||||
- **Description:** Open Gemini CLI documentation in your browser.
|
||||
|
||||
### `/editor`
|
||||
|
||||
- **Description:** Open a dialog for selecting supported editors.
|
||||
|
||||
### `/extensions`
|
||||
|
||||
- **Description:** Manage extensions. See
|
||||
[Gemini CLI Extensions](../extensions/index.md).
|
||||
- **Sub-commands:**
|
||||
- **`config`**:
|
||||
- **Description:** Configure extension settings.
|
||||
- **`disable`**:
|
||||
- **Description:** Disable an extension.
|
||||
- **`enable`**:
|
||||
- **Description:** Enable an extension.
|
||||
- **`explore`**:
|
||||
- **Description:** Open extensions page in your browser.
|
||||
- **`install`**:
|
||||
- **Description:** Install an extension from a git repo or local path.
|
||||
- **`link`**:
|
||||
- **Description:** Link an extension from a local path.
|
||||
- **`list`**:
|
||||
- **Description:** List active extensions.
|
||||
- **`restart`**:
|
||||
- **Description:** Restart all extensions.
|
||||
- **`uninstall`**:
|
||||
- **Description:** Uninstall an extension.
|
||||
- **`update`**:
|
||||
- **Description:** Update extensions. Usage: update <extension-names>|--all
|
||||
|
||||
### `/help` (or `/?`)
|
||||
|
||||
- **Description:** Display help information about Gemini CLI, including
|
||||
available commands and their usage.
|
||||
|
||||
### `/hooks`
|
||||
|
||||
- **Description:** Manage hooks, which allow you to intercept and customize
|
||||
Gemini CLI behavior at specific lifecycle events.
|
||||
- **Sub-commands:**
|
||||
- **`disable-all`**:
|
||||
- **Description:** Disable all enabled hooks.
|
||||
- **`disable <hook-name>`**:
|
||||
- **Description:** Disable a hook by name.
|
||||
- **`enable-all`**:
|
||||
- **Description:** Enable all disabled hooks.
|
||||
- **`enable <hook-name>`**:
|
||||
- **Description:** Enable a hook by name.
|
||||
- **`list`** (or `show`, `panel`):
|
||||
- **Description:** Display all registered hooks with their status.
|
||||
|
||||
### `/ide`
|
||||
|
||||
- **Description:** Manage IDE integration.
|
||||
- **Sub-commands:**
|
||||
- **`disable`**:
|
||||
- **Description:** Disable IDE integration.
|
||||
- **`enable`**:
|
||||
- **Description:** Enable IDE integration.
|
||||
- **`install`**:
|
||||
- **Description:** Install required IDE companion.
|
||||
- **`status`**:
|
||||
- **Description:** Check status of IDE integration.
|
||||
|
||||
### `/init`
|
||||
|
||||
- **Description:** To help users easily create a `GEMINI.md` file, this command
|
||||
analyzes the current directory and generates a tailored context file, making
|
||||
it simpler for them to provide project-specific instructions to the Gemini
|
||||
agent.
|
||||
|
||||
### `/mcp`
|
||||
|
||||
- **Description:** Manage configured Model Context Protocol (MCP) servers.
|
||||
- **Sub-commands:**
|
||||
- **`auth`**:
|
||||
- **Description:** Authenticate with an OAuth-enabled MCP server.
|
||||
- **Usage:** `/mcp auth <server-name>`
|
||||
- **Details:** If `<server-name>` is provided, it initiates the OAuth flow
|
||||
for that server. If no server name is provided, it lists all configured
|
||||
servers that support OAuth authentication.
|
||||
- **`desc`**
|
||||
- **Description:** List configured MCP servers and tools with descriptions.
|
||||
- **`disable`**
|
||||
- **Description:** Disable an MCP server.
|
||||
- **`enable`**
|
||||
- **Description:** Enable a disabled MCP server.
|
||||
- **`list`** or **`ls`**:
|
||||
- **Description:** List configured MCP servers and tools. This is the
|
||||
default action if no subcommand is specified.
|
||||
- **`reload`**:
|
||||
- **Description:** Reloads all MCP servers and re-discovers their available
|
||||
tools.
|
||||
- **`schema`**:
|
||||
- **Description:** List configured MCP servers and tools with descriptions
|
||||
and schemas.
|
||||
|
||||
### `/memory`
|
||||
|
||||
- **Description:** Manage the AI's instructional context (hierarchical memory
|
||||
loaded from `GEMINI.md` files).
|
||||
- **Sub-commands:**
|
||||
- **`list`**:
|
||||
- **Description:** Lists the paths of the GEMINI.md files in use for
|
||||
hierarchical memory.
|
||||
- **`refresh`**:
|
||||
- **Description:** Reload the hierarchical instructional memory from all
|
||||
`GEMINI.md` files found in the configured locations (global,
|
||||
project/ancestors, and sub-directories). This command updates the model
|
||||
with the latest `GEMINI.md` content.
|
||||
- **`show`**:
|
||||
- **Description:** Display the full, concatenated content of the current
|
||||
hierarchical memory that has been loaded from all `GEMINI.md` files. This
|
||||
lets you inspect the instructional context being provided to the Gemini
|
||||
model.
|
||||
- **Note:** For more details on how `GEMINI.md` files contribute to
|
||||
hierarchical memory, see the
|
||||
[CLI Configuration documentation](./configuration.md).
|
||||
|
||||
### `/model`
|
||||
|
||||
- **Description:** Manage model configuration.
|
||||
- **Sub-commands:**
|
||||
- **`manage`**:
|
||||
- **Description:** Opens a dialog to configure the model.
|
||||
- **`set`**:
|
||||
- **Description:** Set the model to use.
|
||||
- **Usage:** `/model set <model-name> [--persist]`
|
||||
|
||||
### `/permissions`
|
||||
|
||||
- **Description:** Manage folder trust settings and other permissions.
|
||||
- **Sub-commands:**
|
||||
- **`trust`**:
|
||||
- **Description:** Manage folder trust settings.
|
||||
- **Usage:** `/permissions trust [<directory-path>]`
|
||||
|
||||
### `/plan`
|
||||
|
||||
- **Description:** Switch to Plan Mode (read-only) and view the current plan if
|
||||
one has been generated.
|
||||
- **Note:** This feature is enabled by default. It can be disabled via the
|
||||
`general.plan.enabled` setting in your configuration.
|
||||
- **Sub-commands:**
|
||||
- **`copy`**:
|
||||
- **Description:** Copy the currently approved plan to your clipboard.
|
||||
|
||||
### `/policies`
|
||||
|
||||
- **Description:** Manage policies.
|
||||
- **Sub-commands:**
|
||||
- **`list`**:
|
||||
- **Description:** List all active policies grouped by mode.
|
||||
|
||||
### `/privacy`
|
||||
|
||||
- **Description:** Display the Privacy Notice and allow users to select whether
|
||||
they consent to the collection of their data for service improvement purposes.
|
||||
|
||||
### `/quit` (or `/exit`)
|
||||
|
||||
- **Description:** Exit Gemini CLI.
|
||||
- **Flags:**
|
||||
- **`--delete`** _(optional)_: Exit and permanently delete the current
|
||||
session's history and temporary files (chat recording, tool outputs). Useful
|
||||
for privacy or one-off tasks where you don't want to leave any traces.
|
||||
- **Usage:** `/quit --delete` or `/exit --delete`
|
||||
|
||||
### `/restore`
|
||||
|
||||
- **Description:** Restores the project files to the state they were in just
|
||||
before a tool was executed. This is particularly useful for undoing file edits
|
||||
made by a tool. If run without a tool call ID, it will list available
|
||||
checkpoints to restore from.
|
||||
- **Usage:** `/restore [tool_call_id]`
|
||||
- **Note:** Only available if checkpointing is configured via
|
||||
[settings](./configuration.md). See
|
||||
[Checkpointing documentation](../cli/checkpointing.md) for more details.
|
||||
|
||||
### `/rewind`
|
||||
|
||||
- **Description:** Navigates backward through the conversation history, letting
|
||||
you review past interactions and potentially revert both chat state and file
|
||||
changes.
|
||||
- **Usage:** Press **Esc** twice as a shortcut.
|
||||
- **Features:**
|
||||
- **Select Interaction:** Preview user prompts and file changes.
|
||||
- **Action Selection:** Choose to rewind history only, revert code changes
|
||||
only, or both.
|
||||
|
||||
### `/resume`
|
||||
|
||||
- **Description:** Browse and resume previous conversation sessions, and manage
|
||||
manual chat checkpoints.
|
||||
- **Features:**
|
||||
- **Auto sessions:** Run `/resume` to open the interactive session browser for
|
||||
automatically saved conversations.
|
||||
- **Chat checkpoints:** Use checkpoint subcommands directly (`/resume save`,
|
||||
`/resume resume`, etc.).
|
||||
- **Management:** Delete unwanted sessions directly from the browser
|
||||
- **Resume:** Select any session to resume and continue the conversation
|
||||
- **Search:** Use `/` to search through conversation content across all
|
||||
sessions
|
||||
- **Session Browser:** Interactive interface showing all saved sessions with
|
||||
timestamps, message counts, and first user message for context
|
||||
- **Sorting:** Sort sessions by date or message count
|
||||
- **Note:** All conversations are automatically saved as you chat - no manual
|
||||
saving required. See [Session Management](../cli/session-management.md) for
|
||||
complete details.
|
||||
- **Alias:** `/chat` provides the same behavior and subcommands.
|
||||
- **Sub-commands:**
|
||||
- **`list`**
|
||||
- **Description:** Lists available tags for manual chat checkpoints.
|
||||
- **`save <tag>`**
|
||||
- **Description:** Saves the current conversation as a tagged checkpoint.
|
||||
- **`resume <tag>`** (alias: `load`)
|
||||
- **Description:** Loads a previously saved tagged checkpoint.
|
||||
- **`delete <tag>`**
|
||||
- **Description:** Deletes a tagged checkpoint.
|
||||
- **`share [filename]`**
|
||||
- **Description:** Exports the current conversation to Markdown or JSON.
|
||||
- **`debug`**
|
||||
- **Description:** Export the most recent API request as JSON payload
|
||||
(nightly builds).
|
||||
- **Compatibility alias:** `/resume checkpoints ...` is still accepted for the
|
||||
same checkpoint commands.
|
||||
|
||||
### `/settings`
|
||||
|
||||
- **Description:** Open the settings editor to view and modify Gemini CLI
|
||||
settings.
|
||||
- **Details:** This command provides a user-friendly interface for changing
|
||||
settings that control the behavior and appearance of Gemini CLI. It is
|
||||
equivalent to manually editing the `.gemini/settings.json` file, but with
|
||||
validation and guidance to prevent errors. See the
|
||||
[settings documentation](../cli/settings.md) for a full list of available
|
||||
settings.
|
||||
- **Usage:** Simply run `/settings` and the editor will open. You can then
|
||||
browse or search for specific settings, view their current values, and modify
|
||||
them as desired. Changes to some settings are applied immediately, while
|
||||
others require a restart.
|
||||
|
||||
### `/shells` (or `/bashes`)
|
||||
|
||||
- **Description:** Toggle the background shells view. This lets you view and
|
||||
manage long-running processes that you've sent to the background.
|
||||
|
||||
### `/setup-github`
|
||||
|
||||
- **Description:** Set up GitHub Actions to triage issues and review PRs with
|
||||
Gemini.
|
||||
|
||||
### `/skills`
|
||||
|
||||
- **Description:** Manage Agent Skills, which provide on-demand expertise and
|
||||
specialized workflows.
|
||||
- **Sub-commands:**
|
||||
- **`disable <name>`**:
|
||||
- **Description:** Disable a specific skill by name.
|
||||
- **Usage:** `/skills disable <name>`
|
||||
- **`enable <name>`**:
|
||||
- **Description:** Enable a specific skill by name.
|
||||
- **Usage:** `/skills enable <name>`
|
||||
- **`list`**:
|
||||
- **Description:** List all discovered skills and their current status
|
||||
(enabled/disabled).
|
||||
- **`reload`**:
|
||||
- **Description:** Refresh the list of discovered skills from all tiers
|
||||
(workspace, user, and extensions).
|
||||
|
||||
### `/stats`
|
||||
|
||||
- **Description:** Display detailed statistics for the current Gemini CLI
|
||||
session.
|
||||
- **Sub-commands:**
|
||||
- **`session`**:
|
||||
- **Description:** Show session-specific usage statistics, including
|
||||
duration, tool calls, and performance metrics. This is the default view.
|
||||
- **`model`**:
|
||||
- **Description:** Show model-specific usage statistics, including token
|
||||
counts and quota information.
|
||||
- **`tools`**:
|
||||
- **Description:** Show tool-specific usage statistics.
|
||||
|
||||
### `/terminal-setup`
|
||||
|
||||
- **Description:** Configure terminal keybindings for multiline input (VS Code,
|
||||
Cursor, Windsurf).
|
||||
|
||||
### `/theme`
|
||||
|
||||
- **Description:** Open a dialog that lets you change the visual theme of Gemini
|
||||
CLI.
|
||||
|
||||
### `/tools`
|
||||
|
||||
- **Description:** Display a list of tools that are currently available within
|
||||
Gemini CLI.
|
||||
- **Usage:** `/tools [desc]`
|
||||
- **Sub-commands:**
|
||||
- **`desc`** or **`descriptions`**:
|
||||
- **Description:** Show detailed descriptions of each tool, including each
|
||||
tool's name with its full description as provided to the model.
|
||||
- **`nodesc`** or **`nodescriptions`**:
|
||||
- **Description:** Hide tool descriptions, showing only the tool names.
|
||||
|
||||
### `/upgrade`
|
||||
|
||||
- **Description:** Open the Gemini Code Assist upgrade page in your browser.
|
||||
This lets you upgrade your tier for higher usage limits.
|
||||
- **Note:** This command is only available when logged in with Google.
|
||||
|
||||
### `/vim`
|
||||
|
||||
- **Description:** Toggle vim mode on or off. When vim mode is enabled, the
|
||||
input area supports vim-style navigation and editing commands in both NORMAL
|
||||
and INSERT modes.
|
||||
- **Features:**
|
||||
- **Count support:** Prefix commands with numbers (for example, `3h`, `5w`,
|
||||
`10G`)
|
||||
- **Editing commands:** Delete with `x`, change with `c`, insert with `i`,
|
||||
`a`, `o`, `O`; complex operations like `dd`, `cc`, `dw`, `cw`
|
||||
- **INSERT mode:** Standard text input with escape to return to NORMAL mode
|
||||
- **NORMAL mode:** Navigate with `h`, `j`, `k`, `l`; jump by words with `w`,
|
||||
`b`, `e`; go to line start/end with `0`, `$`, `^`; go to specific lines with
|
||||
`G` (or `gg` for first line)
|
||||
- **Persistent setting:** Vim mode preference is saved to
|
||||
`~/.gemini/settings.json` and restored between sessions
|
||||
- **Repeat last command:** Use `.` to repeat the last editing operation
|
||||
- **Status indicator:** When enabled, shows `[NORMAL]` or `[INSERT]` in the
|
||||
footer
|
||||
|
||||
### Custom commands
|
||||
|
||||
Custom commands allow you to create personalized shortcuts for your most-used
|
||||
prompts. For detailed instructions on how to create, manage, and use them, see
|
||||
the dedicated [Custom Commands documentation](../cli/custom-commands.md).
|
||||
|
||||
## Input prompt shortcuts
|
||||
|
||||
These shortcuts apply directly to the input prompt for text manipulation.
|
||||
|
||||
- **Undo:**
|
||||
|
||||
- **Keyboard shortcut:** Press **Ctrl+z** (Windows), **Cmd+z** (macOS), or
|
||||
**Alt+z** (Linux/WSL) to undo the last action in the input prompt.
|
||||
|
||||
- **Redo:**
|
||||
- **Keyboard shortcut:** Press **Shift+Cmd+Z** (macOS), or **Shift+Alt+Z**
|
||||
(Linux/WSL) to redo the last undone action in the input prompt.
|
||||
|
||||
## At commands (`@`)
|
||||
|
||||
At commands are used to include the content of files or directories as part of
|
||||
your prompt to Gemini. These commands include git-aware filtering.
|
||||
|
||||
- **`@<path_to_file_or_directory>`**
|
||||
|
||||
- **Description:** Inject the content of the specified file or files into your
|
||||
current prompt. This is useful for asking questions about specific code,
|
||||
text, or collections of files.
|
||||
- **Examples:**
|
||||
- `@path/to/your/file.txt Explain this text.`
|
||||
- `@src/my_project/ Summarize the code in this directory.`
|
||||
- `What is this file about? @README.md`
|
||||
- **Details:**
|
||||
- If a path to a single file is provided, the content of that file is read.
|
||||
- If a path to a directory is provided, the command attempts to read the
|
||||
content of files within that directory and any subdirectories.
|
||||
- Spaces in paths should be escaped with a backslash (for example,
|
||||
`@My\ Documents/file.txt`).
|
||||
- The command uses the `read_many_files` tool internally. The content is
|
||||
fetched and then inserted into your query before being sent to the Gemini
|
||||
model.
|
||||
- **Git-aware filtering:** By default, git-ignored files (like
|
||||
`node_modules/`, `dist/`, `.env`, `.git/`) are excluded. This behavior can
|
||||
be changed via the `context.fileFiltering` settings.
|
||||
- **File types:** The command is intended for text-based files. While it
|
||||
might attempt to read any file, binary files or very large files might be
|
||||
skipped or truncated by the underlying `read_many_files` tool to ensure
|
||||
performance and relevance. The tool indicates if files were skipped.
|
||||
- **Output:** The CLI will show a tool call message indicating that
|
||||
`read_many_files` was used, along with a message detailing the status and
|
||||
the path(s) that were processed.
|
||||
|
||||
- **`@` (Lone at symbol)**
|
||||
- **Description:** If you type a lone `@` symbol without a path, the query is
|
||||
passed as-is to the Gemini model. This might be useful if you are
|
||||
specifically talking _about_ the `@` symbol in your prompt.
|
||||
|
||||
### Error handling for `@` commands
|
||||
|
||||
- If the path specified after `@` is not found or is invalid, an error message
|
||||
will be displayed, and the query might not be sent to the Gemini model, or it
|
||||
will be sent without the file content.
|
||||
- If the `read_many_files` tool encounters an error (for example, permission
|
||||
issues), this will also be reported.
|
||||
|
||||
## Shell mode and passthrough commands (`!`)
|
||||
|
||||
The `!` prefix lets you interact with your system's shell directly from within
|
||||
Gemini CLI.
|
||||
|
||||
- **`!<shell_command>`**
|
||||
|
||||
- **Description:** Execute the given `<shell_command>` using `bash` on
|
||||
Linux/macOS or `powershell.exe -NoProfile -Command` on Windows (unless you
|
||||
override `ComSpec`). Any output or errors from the command are displayed in
|
||||
the terminal.
|
||||
- **Examples:**
|
||||
- `!ls -la` (executes `ls -la` and returns to Gemini CLI)
|
||||
- `!git status` (executes `git status` and returns to Gemini CLI)
|
||||
|
||||
- **`!` (Toggle shell mode)**
|
||||
|
||||
- **Description:** Typing `!` on its own toggles shell mode.
|
||||
- **Entering shell mode:**
|
||||
- When active, shell mode uses a different coloring and a "Shell Mode
|
||||
Indicator".
|
||||
- While in shell mode, text you type is interpreted directly as a shell
|
||||
command.
|
||||
- **Exiting shell mode:**
|
||||
- When exited, the UI reverts to its standard appearance and normal Gemini
|
||||
CLI behavior resumes.
|
||||
|
||||
- **Caution for all `!` usage:** Commands you execute in shell mode have the
|
||||
same permissions and impact as if you ran them directly in your terminal.
|
||||
|
||||
- **Environment variable:** When a command is executed via `!` or in shell mode,
|
||||
the `GEMINI_CLI=1` environment variable is set in the subprocess's
|
||||
environment. This allows scripts or tools to detect if they are being run from
|
||||
within Gemini CLI.
|
||||
File diff suppressed because it is too large
Load Diff
@@ -0,0 +1,360 @@
|
||||
# Gemini CLI keyboard shortcuts
|
||||
|
||||
Gemini CLI ships with a set of default keyboard shortcuts for editing input,
|
||||
navigating history, and controlling the UI. Use this reference to learn the
|
||||
available combinations.
|
||||
|
||||
<!-- KEYBINDINGS-AUTOGEN:START -->
|
||||
|
||||
#### Basic Controls
|
||||
|
||||
| Command | Action | Keys |
|
||||
| --------------- | --------------------------------------------------------------- | ------------------- |
|
||||
| `basic.confirm` | Confirm the current selection or choice. | `Enter` |
|
||||
| `basic.cancel` | Dismiss dialogs or cancel the current focus. | `Esc`<br />`Ctrl+[` |
|
||||
| `basic.quit` | Cancel the current request or quit the CLI when input is empty. | `Ctrl+C` |
|
||||
| `basic.exit` | Exit the CLI when the input buffer is empty. | `Ctrl+D` |
|
||||
|
||||
#### Cursor Movement
|
||||
|
||||
| Command | Action | Keys |
|
||||
| ------------------ | ------------------------------------------- | ------------------------------------------ |
|
||||
| `cursor.home` | Move the cursor to the start of the line. | `Ctrl+A`<br />`Home` |
|
||||
| `cursor.end` | Move the cursor to the end of the line. | `Ctrl+E`<br />`End` |
|
||||
| `cursor.up` | Move the cursor up one line. | `Up` |
|
||||
| `cursor.down` | Move the cursor down one line. | `Down` |
|
||||
| `cursor.left` | Move the cursor one character to the left. | `Left` |
|
||||
| `cursor.right` | Move the cursor one character to the right. | `Right`<br />`Ctrl+F` |
|
||||
| `cursor.wordLeft` | Move the cursor one word to the left. | `Ctrl+Left`<br />`Alt+Left`<br />`Alt+B` |
|
||||
| `cursor.wordRight` | Move the cursor one word to the right. | `Ctrl+Right`<br />`Alt+Right`<br />`Alt+F` |
|
||||
|
||||
#### Editing
|
||||
|
||||
| Command | Action | Keys |
|
||||
| ---------------------- | ------------------------------------------------ | -------------------------------------------------------- |
|
||||
| `edit.deleteRightAll` | Delete from the cursor to the end of the line. | `Ctrl+K` |
|
||||
| `edit.deleteLeftAll` | Delete from the cursor to the start of the line. | `Ctrl+U` |
|
||||
| `edit.clear` | Clear all text in the input field. | `Ctrl+C` |
|
||||
| `edit.deleteWordLeft` | Delete the previous word. | `Ctrl+Backspace`<br />`Alt+Backspace`<br />`Ctrl+W` |
|
||||
| `edit.deleteWordRight` | Delete the next word. | `Ctrl+Delete`<br />`Alt+Delete`<br />`Alt+D` |
|
||||
| `edit.deleteLeft` | Delete the character to the left. | `Backspace`<br />`Ctrl+H` |
|
||||
| `edit.deleteRight` | Delete the character to the right. | `Delete`<br />`Ctrl+D` |
|
||||
| `edit.undo` | Undo the most recent text edit. | `Ctrl+Z`<br />`Alt+Z`<br />`Cmd/Win+Z` |
|
||||
| `edit.redo` | Redo the most recent undone text edit. | `Ctrl+Shift+Z`<br />`Shift+Cmd/Win+Z`<br />`Alt+Shift+Z` |
|
||||
|
||||
#### Scrolling
|
||||
|
||||
| Command | Action | Keys |
|
||||
| ----------------- | ------------------------ | ----------------------------- |
|
||||
| `scroll.up` | Scroll content up. | `Shift+Up` |
|
||||
| `scroll.down` | Scroll content down. | `Shift+Down` |
|
||||
| `scroll.home` | Scroll to the top. | `Ctrl+Home`<br />`Shift+Home` |
|
||||
| `scroll.end` | Scroll to the bottom. | `Ctrl+End`<br />`Shift+End` |
|
||||
| `scroll.pageUp` | Scroll up by one page. | `Page Up` |
|
||||
| `scroll.pageDown` | Scroll down by one page. | `Page Down` |
|
||||
|
||||
#### History & Search
|
||||
|
||||
| Command | Action | Keys |
|
||||
| ----------------------- | -------------------------------------------- | -------- |
|
||||
| `history.previous` | Show the previous entry in history. | `Ctrl+P` |
|
||||
| `history.next` | Show the next entry in history. | `Ctrl+N` |
|
||||
| `history.search.start` | Start reverse search through history. | `Ctrl+R` |
|
||||
| `history.search.submit` | Submit the selected reverse-search match. | `Enter` |
|
||||
| `history.search.accept` | Accept a suggestion while reverse searching. | `Tab` |
|
||||
|
||||
#### Navigation
|
||||
|
||||
| Command | Action | Keys |
|
||||
| --------------------- | -------------------------------------------------- | --------------- |
|
||||
| `nav.up` | Move selection up in lists. | `Up` |
|
||||
| `nav.down` | Move selection down in lists. | `Down` |
|
||||
| `nav.dialog.up` | Move up within dialog options. | `Up`<br />`K` |
|
||||
| `nav.dialog.down` | Move down within dialog options. | `Down`<br />`J` |
|
||||
| `nav.dialog.next` | Move to the next item or question in a dialog. | `Tab` |
|
||||
| `nav.dialog.previous` | Move to the previous item or question in a dialog. | `Shift+Tab` |
|
||||
|
||||
#### Suggestions & Completions
|
||||
|
||||
| Command | Action | Keys |
|
||||
| ----------------------- | --------------------------------------- | -------------------- |
|
||||
| `suggest.accept` | Accept the inline suggestion. | `Tab`<br />`Enter` |
|
||||
| `suggest.focusPrevious` | Move to the previous completion option. | `Up`<br />`Ctrl+P` |
|
||||
| `suggest.focusNext` | Move to the next completion option. | `Down`<br />`Ctrl+N` |
|
||||
| `suggest.expand` | Expand an inline suggestion. | `Right` |
|
||||
| `suggest.collapse` | Collapse an inline suggestion. | `Left` |
|
||||
|
||||
#### Text Input
|
||||
|
||||
| Command | Action | Keys |
|
||||
| ------------------------------------ | ------------------------------------------------------------------------- | ----------------------------------------------------------------------------------- |
|
||||
| `input.submit` | Submit the current prompt. | `Enter` |
|
||||
| `input.queueMessage` | Queue the current prompt to be processed after the current task finishes. | `Tab` |
|
||||
| `input.newline` | Insert a newline without submitting. | `Ctrl+Enter`<br />`Cmd/Win+Enter`<br />`Alt+Enter`<br />`Shift+Enter`<br />`Ctrl+J` |
|
||||
| `input.openExternalEditor` | Open the current prompt or the plan in an external editor. | `Ctrl+G`<br />`Ctrl+Shift+G` |
|
||||
| `input.deprecatedOpenExternalEditor` | Deprecated command to open external editor. | `Ctrl+X` |
|
||||
| `input.paste` | Paste from the clipboard. | `Ctrl+V`<br />`Cmd/Win+V`<br />`Alt+V` |
|
||||
|
||||
#### App Controls
|
||||
|
||||
| Command | Action | Keys |
|
||||
| ----------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------ |
|
||||
| `app.showErrorDetails` | Toggle the debug console for detailed error information. | `F12` |
|
||||
| `app.showFullTodos` | Toggle the full TODO list. | `Ctrl+T` |
|
||||
| `app.showIdeContextDetail` | Show IDE context details. | `F4` |
|
||||
| `app.toggleMarkdown` | Toggle Markdown rendering. | `Alt+M` |
|
||||
| `app.toggleCopyMode` | Toggle copy mode when in alternate buffer mode. | `F9` |
|
||||
| `app.toggleMouseMode` | Toggle mouse mode (scrolling and clicking). | `Ctrl+S` |
|
||||
| `app.toggleYolo` | Toggle YOLO (auto-approval) mode for tool calls. | `Ctrl+Y` |
|
||||
| `app.cycleApprovalMode` | Cycle through approval modes: default (prompt), auto_edit (auto-approve edits), and plan (read-only). Plan mode is skipped when the agent is busy. | `Shift+Tab` |
|
||||
| `app.showMoreLines` | Expand and collapse blocks of content when not in alternate buffer mode. | `Ctrl+O` |
|
||||
| `app.expandPaste` | Expand or collapse a paste placeholder when cursor is over placeholder. | `Ctrl+O` |
|
||||
| `app.focusShellInput` | Move focus from Gemini to the active shell. | `Tab` |
|
||||
| `app.unfocusShellInput` | Move focus from the shell back to Gemini. | `Shift+Tab` |
|
||||
| `app.clearScreen` | Clear the terminal screen and redraw the UI. | `Ctrl+L` |
|
||||
| `app.restart` | Restart the application. | `R`<br />`Shift+R` |
|
||||
| `app.suspend` | Suspend the CLI and move it to the background. | `Ctrl+Z` |
|
||||
| `app.showShellUnfocusWarning` | Show warning when trying to move focus away from shell input. | `Tab` |
|
||||
| `app.voiceModePTT` | Hold to speak in Voice Mode. | `Space` |
|
||||
|
||||
#### Background Shell Controls
|
||||
|
||||
| Command | Action | Keys |
|
||||
| --------------------------- | ------------------------------------------------------------------ | ----------- |
|
||||
| `background.escape` | Dismiss background shell list. | `Esc` |
|
||||
| `background.select` | Confirm selection in background shell list. | `Enter` |
|
||||
| `background.toggle` | Toggle current background shell visibility. | `Ctrl+B` |
|
||||
| `background.toggleList` | Toggle background shell list. | `Ctrl+L` |
|
||||
| `background.kill` | Kill the active background shell. | `Ctrl+K` |
|
||||
| `background.unfocus` | Move focus from background shell to Gemini. | `Shift+Tab` |
|
||||
| `background.unfocusList` | Move focus from background shell list to Gemini. | `Tab` |
|
||||
| `background.unfocusWarning` | Show warning when trying to move focus away from background shell. | `Tab` |
|
||||
| `app.dumpFrame` | Dump the current frame as a snapshot. | `F8` |
|
||||
| `app.startRecording` | Start recording the session. | `F6` |
|
||||
| `app.stopRecording` | Stop recording the session. | `F7` |
|
||||
|
||||
#### Extension Controls
|
||||
|
||||
| Command | Action | Keys |
|
||||
| ------------------ | ------------------------------------------- | ---- |
|
||||
| `extension.update` | Update the current extension if available. | `I` |
|
||||
| `extension.link` | Link the current extension to a local path. | `L` |
|
||||
|
||||
<!-- KEYBINDINGS-AUTOGEN:END -->
|
||||
|
||||
## Customizing Keybindings
|
||||
|
||||
You can add alternative keybindings or remove default keybindings by creating a
|
||||
`keybindings.json` file in your home gemini directory (typically
|
||||
`~/.gemini/keybindings.json`).
|
||||
|
||||
### Configuration Format
|
||||
|
||||
The configuration uses a JSON array of objects, similar to VS Code's keybinding
|
||||
schema. Each object must specify a `command` from the reference tables above and
|
||||
a `key` combination.
|
||||
|
||||
```json
|
||||
[
|
||||
{
|
||||
"command": "edit.clear",
|
||||
"key": "cmd+l"
|
||||
},
|
||||
{
|
||||
// prefix "-" to unbind a key
|
||||
"command": "-app.toggleYolo",
|
||||
"key": "ctrl+y"
|
||||
},
|
||||
{
|
||||
"command": "input.submit",
|
||||
"key": "ctrl+y"
|
||||
},
|
||||
{
|
||||
// multiple modifiers
|
||||
"command": "cursor.right",
|
||||
"key": "shift+alt+a"
|
||||
},
|
||||
{
|
||||
// Some mac keyboards send "Å" instead of "shift+option+a"
|
||||
"command": "cursor.right",
|
||||
"key": "Å"
|
||||
},
|
||||
{
|
||||
// some base keys have special multi-char names
|
||||
"command": "cursor.right",
|
||||
"key": "shift+pageup"
|
||||
}
|
||||
]
|
||||
```
|
||||
|
||||
- **Unbinding** To remove an existing or default keybinding, prefix a minus sign
|
||||
(`-`) to the `command` name.
|
||||
- **No Auto-unbinding** The same key can be bound to multiple commands in
|
||||
different contexts at the same time. Therefore, creating a binding does not
|
||||
automatically unbind the key from other commands.
|
||||
- **Explicit Modifiers**: Key matching is explicit. For example, a binding for
|
||||
`ctrl+f` will only trigger on exactly `ctrl+f`, not `ctrl+shift+f` or
|
||||
`alt+ctrl+f`.
|
||||
- **Literal Characters**: Terminals often translate complex key combinations
|
||||
(especially on macOS with the `Option` key) into special characters, losing
|
||||
modifier and keystroke information along the way. For example,`shift+5` might
|
||||
be sent as `%`. In these cases, you must bind to the literal character `%` as
|
||||
bindings to `shift+5` will never fire. To see precisely what is being sent,
|
||||
enable `Debug Keystroke Logging` and hit f12 to open the debug log console.
|
||||
- **Key Modifiers**: The supported key modifiers are:
|
||||
- `ctrl`
|
||||
- `shift`,
|
||||
- `alt` (synonyms: `opt`, `option`)
|
||||
- `cmd` (synonym: `meta`)
|
||||
- **Base Key**: The base key can be any single unicode code point or any of the
|
||||
following special keys:
|
||||
- **Navigation**: `up`, `down`, `left`, `right`, `home`, `end`, `pageup`,
|
||||
`pagedown`
|
||||
- **Actions**: `enter`, `escape`, `tab`, `space`, `backspace`, `delete`,
|
||||
`clear`, `insert`, `printscreen`
|
||||
- **Toggles**: `capslock`, `numlock`, `scrolllock`, `pausebreak`
|
||||
- **Function Keys**: `f1` through `f35`
|
||||
- **Numpad**: `numpad0` through `numpad9`, `numpad_add`, `numpad_subtract`,
|
||||
`numpad_multiply`, `numpad_divide`, `numpad_decimal`, `numpad_separator`
|
||||
|
||||
## Additional context-specific shortcuts
|
||||
|
||||
- `Option+B/F/M` (macOS only): Are interpreted as `Cmd+B/F/M` even if your
|
||||
terminal isn't configured to send Meta with Option.
|
||||
- `!` on an empty prompt: Enter or exit shell mode.
|
||||
- `?` on an empty prompt: Toggle the shortcuts panel above the input. Press
|
||||
`Esc`, `Backspace`, any printable key, or a registered app hotkey to close it.
|
||||
The panel also auto-hides while the agent is running/streaming or when
|
||||
action-required dialogs are shown. Press `?` again to close the panel and
|
||||
insert a `?` into the prompt.
|
||||
- `Tab` + `Tab` (while typing in the prompt): Toggle between minimal and full UI
|
||||
details when no completion/search interaction is active. The selected mode is
|
||||
remembered for future sessions. Full UI remains the default on first run, and
|
||||
single `Tab` keeps its existing completion/focus behavior.
|
||||
- `Shift + Tab` (while typing in the prompt): Cycle approval modes: default,
|
||||
auto-edit, and plan (skipped when agent is busy).
|
||||
- `\` (at end of a line) + `Enter`: Insert a newline without leaving single-line
|
||||
mode.
|
||||
- `Esc` pressed twice quickly: Clear the input prompt if it is not empty,
|
||||
otherwise browse and rewind previous interactions.
|
||||
- `Up Arrow` / `Down Arrow`: When the cursor is at the top or bottom of a
|
||||
single-line input, navigate backward or forward through prompt history.
|
||||
- `Number keys (1-9, multi-digit)` inside selection dialogs: Jump directly to
|
||||
the numbered radio option and confirm when the full number is entered.
|
||||
- `Ctrl + O`: Expand or collapse paste placeholders (`[Pasted Text: X lines]`)
|
||||
inline when the cursor is over the placeholder.
|
||||
- `Ctrl + X` (while a plan is presented): Open the plan in an external editor to
|
||||
[collaboratively edit or comment](../cli/plan-mode.md#collaborative-plan-editing)
|
||||
on the implementation strategy.
|
||||
- `Double-click` on a paste placeholder (alternate buffer mode only): Expand to
|
||||
view full content inline. Double-click again to collapse.
|
||||
|
||||
## Vi mode shortcuts
|
||||
|
||||
When vim mode is enabled with `/vim` or `general.vimMode: true`, Gemini CLI
|
||||
supports NORMAL and INSERT modes.
|
||||
|
||||
### Mode switching
|
||||
|
||||
| Action | Keys |
|
||||
| -------------------------------------------- | --------- |
|
||||
| Enter NORMAL mode from INSERT mode | `Esc` |
|
||||
| Enter INSERT mode at the cursor | `i` |
|
||||
| Enter INSERT mode after the cursor | `a` |
|
||||
| Enter INSERT mode at the start of the line | `I` |
|
||||
| Enter INSERT mode at the end of the line | `A` |
|
||||
| Insert a new line below and switch to INSERT | `o` |
|
||||
| Insert a new line above and switch to INSERT | `O` |
|
||||
| Clear input in NORMAL mode | `Esc Esc` |
|
||||
|
||||
### Navigation in NORMAL mode
|
||||
|
||||
| Action | Keys |
|
||||
| --------------------------------- | --------------- |
|
||||
| Move left | `h` |
|
||||
| Move down | `j` |
|
||||
| Move up | `k` |
|
||||
| Move right | `l` |
|
||||
| Move to start of line | `0` |
|
||||
| Move to first non-whitespace char | `^` |
|
||||
| Move to end of line | `$` |
|
||||
| Move forward by word | `w` |
|
||||
| Move backward by word | `b` |
|
||||
| Move to end of word | `e` |
|
||||
| Move forward by WORD | `W` |
|
||||
| Move backward by WORD | `B` |
|
||||
| Move to end of WORD | `E` |
|
||||
| Go to first line | `gg` |
|
||||
| Go to last line | `G` |
|
||||
| Go to line N | `N G` or `N gg` |
|
||||
|
||||
Counts are supported for navigation commands. For example, `5j` moves down five
|
||||
lines and `3w` moves forward three words.
|
||||
|
||||
### Editing in NORMAL mode
|
||||
|
||||
| Action | Keys |
|
||||
| ------------------------------ | ----- |
|
||||
| Delete character under cursor | `x` |
|
||||
| Delete to end of line | `D` |
|
||||
| Delete line | `dd` |
|
||||
| Change to end of line | `C` |
|
||||
| Change line | `cc` |
|
||||
| Delete forward word | `dw` |
|
||||
| Delete backward word | `db` |
|
||||
| Delete to end of word | `de` |
|
||||
| Delete forward WORD | `dW` |
|
||||
| Delete backward WORD | `dB` |
|
||||
| Delete to end of WORD | `dE` |
|
||||
| Change forward word | `cw` |
|
||||
| Change backward word | `cb` |
|
||||
| Change to end of word | `ce` |
|
||||
| Change forward WORD | `cW` |
|
||||
| Change backward WORD | `cB` |
|
||||
| Change to end of WORD | `cE` |
|
||||
| Delete to start of line | `d0` |
|
||||
| Delete to first non-whitespace | `d^` |
|
||||
| Change to start of line | `c0` |
|
||||
| Change to first non-whitespace | `c^` |
|
||||
| Delete from first line to here | `dgg` |
|
||||
| Delete from here to last line | `dG` |
|
||||
| Change from first line to here | `cgg` |
|
||||
| Change from here to last line | `cG` |
|
||||
| Undo last change | `u` |
|
||||
| Repeat last command | `.` |
|
||||
|
||||
Counts are also supported for editing commands. For example, `3dd` deletes three
|
||||
lines and `2cw` changes two words.
|
||||
|
||||
### Find, replace, yank, and paste in NORMAL mode
|
||||
|
||||
| Action | Keys |
|
||||
| ----------------------------------------- | ----------- |
|
||||
| Find next matching character | `f{char}` |
|
||||
| Find previous matching character | `F{char}` |
|
||||
| Move until before next matching character | `t{char}` |
|
||||
| Move until after previous matching char | `T{char}` |
|
||||
| Repeat latest character find | `;` |
|
||||
| Repeat latest character find in reverse | `,` |
|
||||
| Delete character before cursor | `X` |
|
||||
| Toggle case under cursor | `~` |
|
||||
| Replace character under cursor | `r{char}` |
|
||||
| Yank line | `yy` |
|
||||
| Yank to end of line | `Y` or `y$` |
|
||||
| Yank word / WORD | `yw`, `yW` |
|
||||
| Yank to end of word / WORD | `ye`, `yE` |
|
||||
| Paste after cursor | `p` |
|
||||
| Paste before cursor | `P` |
|
||||
|
||||
Delete and change operators also compose with character-find motions, so
|
||||
commands such as `dfx`, `dtx`, `cFx`, and `cTx` are supported.
|
||||
|
||||
## Limitations
|
||||
|
||||
- On [Windows Terminal](https://en.wikipedia.org/wiki/Windows_Terminal):
|
||||
- `shift+enter` is only supported in version 1.25 and higher.
|
||||
- `shift+tab`
|
||||
[is not supported](https://github.com/google-gemini/gemini-cli/issues/20314)
|
||||
on Node 20 and earlier versions of Node 22.
|
||||
- On macOS's [Terminal](<https://en.wikipedia.org/wiki/Terminal_(macOS)>):
|
||||
- `shift+enter` is not supported.
|
||||
Some files were not shown because too many files have changed in this diff Show More
Reference in New Issue
Block a user