mirror of
https://github.com/google-gemini/gemini-cli.git
synced 2026-04-21 18:44:30 -07:00
Automated documentation audit results (#22755)
This commit is contained in:
Sam Roberts
@@ -44,8 +44,8 @@ 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 (e.g.,
|
||||
prompts) and handling responses and notifications from Gemini CLI.
|
||||
- **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.
|
||||
|
||||
@@ -72,8 +72,8 @@ leverage the IDE's capabilities to perform tasks. The MCP client logic is in
|
||||
|
||||
## Capabilities and supported methods
|
||||
|
||||
The ACP protocol exposes a number of methods for ACP clients (e.g. IDEs) to
|
||||
control Gemini CLI.
|
||||
The ACP protocol exposes a number of methods for ACP clients (for example IDEs)
|
||||
to control Gemini CLI.
|
||||
|
||||
### Core methods
|
||||
|
||||
@@ -87,8 +87,8 @@ control Gemini CLI.
|
||||
|
||||
### Session control
|
||||
|
||||
- `setSessionMode`: Allows changing the approval level for tool calls (e.g., to
|
||||
`auto-approve`).
|
||||
- `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
|
||||
|
||||
@@ -1,9 +1,9 @@
|
||||
# Checkpointing
|
||||
|
||||
The 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.
|
||||
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
|
||||
|
||||
@@ -72,7 +72,7 @@ To see a list of all saved checkpoints for the current project, simply run:
|
||||
|
||||
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 (e.g.,
|
||||
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
|
||||
|
||||
+11
-11
@@ -29,16 +29,16 @@ and parameters.
|
||||
|
||||
These commands are available within the interactive REPL.
|
||||
|
||||
| Command | Description |
|
||||
| -------------------- | ---------------------------------------- |
|
||||
| `/skills reload` | Reload discovered skills from disk |
|
||||
| `/agents reload` | Reload the agent registry |
|
||||
| `/commands reload` | Reload custom slash commands |
|
||||
| `/memory reload` | Reload context files (e.g., `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 |
|
||||
| Command | Description |
|
||||
| -------------------- | ----------------------------------------------- |
|
||||
| `/skills reload` | Reload discovered skills from disk |
|
||||
| `/agents reload` | Reload the agent registry |
|
||||
| `/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
|
||||
|
||||
@@ -60,7 +60,7 @@ These commands are available within the interactive REPL.
|
||||
| `--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 (e.g. `--resume 5`) |
|
||||
| `--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) |
|
||||
|
||||
@@ -14,7 +14,7 @@ skill. To use it, ask Gemini CLI to create a new skill for you.
|
||||
|
||||
Gemini CLI will then use the `skill-creator` to generate the skill:
|
||||
|
||||
1. Generate a new directory for your skill (e.g., `my-new-skill/`).
|
||||
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
|
||||
@@ -24,7 +24,7 @@ Gemini CLI will then use the `skill-creator` to generate the skill:
|
||||
|
||||
If you prefer to create skills manually:
|
||||
|
||||
1. **Create a directory** for your skill (e.g., `my-new-skill/`).
|
||||
1. **Create a directory** for your skill (for example, `my-new-skill/`).
|
||||
2. **Create a `SKILL.md` file** inside the new directory.
|
||||
|
||||
To add additional resources that support the skill, refer to the skill
|
||||
|
||||
+15
-14
@@ -85,8 +85,8 @@ The model receives:
|
||||
**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 allows you to
|
||||
safely pass arguments to shell commands, ensuring the resulting command is
|
||||
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.
|
||||
|
||||
@@ -105,8 +105,8 @@ 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 (e.g., on
|
||||
Linux: `"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.
|
||||
@@ -116,13 +116,13 @@ When you run `/grep-code It's complicated`:
|
||||
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 (e.g., `/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 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 (e.g., `/mycommand`), the prompt is sent
|
||||
to the model exactly as it is, with nothing appended.
|
||||
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`):**
|
||||
|
||||
@@ -188,7 +188,7 @@ ensure that only intended commands can be run.
|
||||
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, e.g.,
|
||||
(stderr) followed by a status line, for example,
|
||||
`[Shell command exited with code 1]`. This helps the model understand the
|
||||
context of the failure.
|
||||
|
||||
@@ -229,9 +229,10 @@ operate on specific files.
|
||||
|
||||
- **File injection**: `@{path/to/file.txt}` is replaced by the content of
|
||||
`file.txt`.
|
||||
- **Multimodal support**: If the path points to a supported image (e.g., 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.
|
||||
- **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.
|
||||
|
||||
+9
-10
@@ -175,8 +175,8 @@ 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
|
||||
(e.g., `/usr/local/bin/gemini`).
|
||||
that appears earlier in the user's `PATH` than the actual Gemini CLI binary (for
|
||||
example, `/usr/local/bin/gemini`).
|
||||
|
||||
```bash
|
||||
#!/bin/bash
|
||||
@@ -325,9 +325,9 @@ User. When it comes to the `mcpServers` object, these configurations are
|
||||
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 (e.g., 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**.
|
||||
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
|
||||
@@ -343,8 +343,8 @@ canonical servers and adding their names to an allowlist.
|
||||
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 allows you to use a subset of tools from a server
|
||||
without allowing potentially dangerous ones.
|
||||
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.
|
||||
@@ -481,9 +481,8 @@ an environment variable, but it can also be enforced for custom tools via the
|
||||
## Telemetry and auditing
|
||||
|
||||
For auditing and monitoring purposes, you can configure Gemini CLI to send
|
||||
telemetry data to a central location. This allows you to track tool usage and
|
||||
other events. For more information, see the
|
||||
[telemetry documentation](./telemetry.md).
|
||||
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`.
|
||||
|
||||
@@ -1,9 +1,9 @@
|
||||
# Ignoring files
|
||||
|
||||
This document provides an overview of the Gemini Ignore (`.geminiignore`)
|
||||
feature of the Gemini CLI.
|
||||
feature of Gemini CLI.
|
||||
|
||||
The Gemini CLI includes the ability to automatically ignore files, similar to
|
||||
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
|
||||
|
||||
@@ -1,26 +1,28 @@
|
||||
# Advanced Model Configuration
|
||||
|
||||
This guide details the Model Configuration system within the Gemini CLI.
|
||||
Designed for researchers, AI quality engineers, and advanced users, this system
|
||||
provides a rigorous framework for managing generative model hyperparameters and
|
||||
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.
|
||||
|
||||
> **Warning**: This is a power-user feature. Configuration values are passed
|
||||
<!-- prettier-ignore -->
|
||||
> [!WARNING]
|
||||
> This is a power-user feature. Configuration values are passed
|
||||
> directly to the model provider with minimal validation. Incorrect settings
|
||||
> (e.g., incompatible parameter combinations) may result in runtime errors from
|
||||
> the API.
|
||||
> (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
|
||||
(e.g., a CLI flag or agent request) from the underlying API configuration. This
|
||||
allows for:
|
||||
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 (e.g., testing vs. production).
|
||||
operating contexts (for example, testing vs. production).
|
||||
- **Agent-Scoped Customization**: Applying specific settings only when a
|
||||
particular agent is active.
|
||||
|
||||
@@ -71,7 +73,7 @@ context. They are evaluated dynamically for each model request.
|
||||
specified `match` properties.
|
||||
- `model`: Matches the requested model name or alias.
|
||||
- `overrideScope`: Matches the distinct scope of the request (typically the
|
||||
agent name, e.g., `codebaseInvestigator`).
|
||||
agent name, for example, `codebaseInvestigator`).
|
||||
|
||||
**Example Override**:
|
||||
|
||||
@@ -113,8 +115,8 @@ 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 (e.g., `model` + `overrideScope`) override broad matches
|
||||
(e.g., `model` only).
|
||||
- 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
|
||||
@@ -128,10 +130,10 @@ The configuration follows the `ModelConfigServiceConfig` interface.
|
||||
|
||||
Defines the actual parameters for the model.
|
||||
|
||||
| Property | Type | Description |
|
||||
| :---------------------- | :------- | :----------------------------------------------------------------- |
|
||||
| `model` | `string` | The identifier of the model to be called (e.g., `gemini-2.5-pro`). |
|
||||
| `generateContentConfig` | `object` | The configuration object passed to the `@google/genai` SDK. |
|
||||
| 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)
|
||||
|
||||
@@ -142,7 +144,7 @@ Directly maps to the SDK's `GenerateContentConfig`. Common parameters include:
|
||||
- **`topP`**: (`number`) Nucleus sampling probability.
|
||||
- **`maxOutputTokens`**: (`number`) Limit on generated response length.
|
||||
- **`thinkingConfig`**: (`object`) Configuration for models with reasoning
|
||||
capabilities (e.g., `thinkingBudget`, `includeThoughts`).
|
||||
capabilities (for example, `thinkingBudget`, `includeThoughts`).
|
||||
|
||||
## 5. Practical Examples
|
||||
|
||||
@@ -170,7 +172,7 @@ configuration but enforcing zero temperature.
|
||||
### Agent-Specific Parameter Injection
|
||||
|
||||
Enforce extended thinking budgets for a specific agent without altering the
|
||||
global default, e.g. for the `codebaseInvestigator`.
|
||||
global default, for example for the `codebaseInvestigator`.
|
||||
|
||||
```json
|
||||
"modelConfigs": {
|
||||
|
||||
@@ -10,8 +10,8 @@ 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 (e.g., due to quota
|
||||
or server errors), the CLI will initiate the fallback process.
|
||||
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
|
||||
|
||||
@@ -19,7 +19,7 @@ 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 the Gemini CLI.
|
||||
1. Type `/settings` in Gemini CLI.
|
||||
2. Search for **Model Steering**.
|
||||
3. Set the value to **true**.
|
||||
|
||||
|
||||
@@ -314,8 +314,8 @@ Hooks such as `BeforeTool` or `AfterTool` can be configured to intercept the
|
||||
> [!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 (e.g., by asking "start a plan
|
||||
> for...").
|
||||
> ensure the transition is initiated by the agent (for example, by asking "start
|
||||
> a plan for...").
|
||||
|
||||
#### Example: Archive approved plans to GCS (`AfterTool`)
|
||||
|
||||
|
||||
+4
-4
@@ -1,11 +1,11 @@
|
||||
# Sandboxing in the Gemini CLI
|
||||
# Sandboxing in Gemini CLI
|
||||
|
||||
This document provides a guide to sandboxing in the Gemini CLI, including
|
||||
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 the Gemini CLI:
|
||||
Before using sandboxing, you need to install and set up Gemini CLI:
|
||||
|
||||
```bash
|
||||
npm install -g @google/gemini-cli
|
||||
@@ -229,7 +229,7 @@ gemini -p "run the test suite"
|
||||
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 (e.g., `{"tools": {"sandbox": true}}`).
|
||||
`settings.json` file (for example, `{"tools": {"sandbox": true}}`).
|
||||
|
||||
### macOS Seatbelt profiles
|
||||
|
||||
|
||||
@@ -35,7 +35,7 @@ via a `.gemini/.env` file. See
|
||||
- `GEMINI_SYSTEM_MD=/absolute/path/to/my-system.md`
|
||||
- Relative paths are supported and resolved from the current working
|
||||
directory.
|
||||
- Tilde expansion is supported (e.g., `~/my-system.md`).
|
||||
- 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.
|
||||
@@ -70,7 +70,7 @@ dynamically include built-in content:
|
||||
- `${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` (e.g., `${write_file_ToolName}`,
|
||||
`${toolName}_ToolName` (for example, `${write_file_ToolName}`,
|
||||
`${run_shell_command_ToolName}`).
|
||||
|
||||
This pattern is generated dynamically for all available tools.
|
||||
|
||||
+2
-2
@@ -117,8 +117,8 @@ 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 (e.g., `#FF0000`) **or** standard CSS color names
|
||||
(e.g., `coral`, `teal`, `blue`) for any color value. See
|
||||
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.
|
||||
|
||||
|
||||
+14
-14
@@ -1,7 +1,7 @@
|
||||
# Trusted Folders
|
||||
|
||||
The Trusted Folders feature is a security setting that gives you control over
|
||||
which projects can use the full capabilities of the Gemini CLI. It prevents
|
||||
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.
|
||||
|
||||
@@ -24,12 +24,12 @@ Add the following to your user `settings.json` file:
|
||||
|
||||
## How it works: The trust dialog
|
||||
|
||||
Once the feature is enabled, the first time you run the Gemini CLI from a
|
||||
folder, a dialog will automatically appear, prompting you to make a choice:
|
||||
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 (e.g.,
|
||||
- **Trust folder**: Grants full trust to the current folder (for example,
|
||||
`my-project`).
|
||||
- **Trust parent folder**: Grants trust to the parent directory (e.g.,
|
||||
- **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
|
||||
@@ -40,9 +40,9 @@ will only be asked once per folder.
|
||||
|
||||
## Understanding folder contents: The discovery phase
|
||||
|
||||
Before you make a choice, the 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.
|
||||
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:
|
||||
|
||||
@@ -63,16 +63,16 @@ attention:
|
||||
settings, such as auto-approving certain tools or disabling the security
|
||||
sandbox.
|
||||
- **Discovery Errors**: If the CLI encounters issues while scanning the folder
|
||||
(e.g., a malformed `settings.json` file), these errors will be displayed
|
||||
prominently.
|
||||
(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**, the Gemini CLI runs in a restricted "safe mode"
|
||||
to protect you. In this mode, the following features are disabled:
|
||||
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
|
||||
@@ -97,8 +97,8 @@ to protect you. In this mode, the following features are disabled:
|
||||
commands from .toml files, including both project-specific and global user
|
||||
commands.
|
||||
|
||||
Granting trust to a folder unlocks the full functionality of the Gemini CLI for
|
||||
that workspace.
|
||||
Granting trust to a folder unlocks the full functionality of Gemini CLI for that
|
||||
workspace.
|
||||
|
||||
## Managing your trust settings
|
||||
|
||||
|
||||
@@ -102,7 +102,7 @@ The agent will:
|
||||
## Troubleshooting
|
||||
|
||||
- **Server won't start?** Try running the docker command manually in your
|
||||
terminal to see if it prints an error (e.g., "image not found").
|
||||
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.
|
||||
|
||||
|
||||
@@ -50,7 +50,7 @@ loaded into every conversation.
|
||||
|
||||
### Scenario: Using the hierarchy
|
||||
|
||||
Context is loaded hierarchically. This allows you to have general rules for
|
||||
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).
|
||||
|
||||
@@ -79,8 +79,8 @@ each step with higher confidence and fewer errors.
|
||||
- **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 (e.g., "We are planning to deprecate this
|
||||
module next month").
|
||||
not be obvious from reading the code (for example, "We are planning to
|
||||
deprecate this module next month").
|
||||
|
||||
## Next steps
|
||||
|
||||
|
||||
@@ -35,7 +35,7 @@ browser.
|
||||
|
||||
This opens a searchable list of all your past sessions. You'll see:
|
||||
|
||||
- A timestamp (e.g., "2 hours ago").
|
||||
- A timestamp (for example, "2 hours ago").
|
||||
- The first user message (helping you identify the topic).
|
||||
- The number of turns in the conversation.
|
||||
|
||||
|
||||
@@ -58,7 +58,7 @@ watchers.
|
||||
|
||||
**Prompt:** `Start the React dev server in the background.`
|
||||
|
||||
Gemini will run the command (e.g., `npm run dev`) and detach it.
|
||||
Gemini will run the command (for example, `npm run dev`) and detach it.
|
||||
|
||||
### Scenario: Viewing active shells
|
||||
|
||||
|
||||
@@ -7,7 +7,7 @@ progress with the todo list.
|
||||
## Prerequisites
|
||||
|
||||
- Gemini CLI installed and authenticated.
|
||||
- A complex task in mind (e.g., a multi-file refactor or new feature).
|
||||
- A complex task in mind (for example, a multi-file refactor or new feature).
|
||||
|
||||
## Why use task planning?
|
||||
|
||||
@@ -58,7 +58,7 @@ Tell the agent to proceed.
|
||||
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 (e.g.,
|
||||
- **Current focus:** The active task is highlighted (for example,
|
||||
`[IN_PROGRESS] Create tsconfig.json`).
|
||||
- **Progress:** Completed tasks are marked as done.
|
||||
|
||||
@@ -90,4 +90,4 @@ living document, not a static text block.
|
||||
- See the [Todo tool reference](../../tools/todos.md) for technical schema
|
||||
details.
|
||||
- Learn about [Memory management](memory-management.md) to persist planning
|
||||
preferences (e.g., "Always create a test plan first").
|
||||
preferences (for example, "Always create a test plan first").
|
||||
|
||||
Reference in New Issue
Block a user