Co-authored-by: gemini-code-assist[bot] <176961590+gemini-code-assist[bot]@users.noreply.github.com>
Co-authored-by: N. Taylor Mullen <ntaylormullen@google.com>
Co-authored-by: gemini-code-assist[bot] <176961590+gemini-code-assist[bot]@users.noreply.github.com>
Co-authored-by: N. Taylor Mullen <ntaylormullen@google.com>
Co-authored-by: gemini-code-assist[bot] <176961590+gemini-code-assist[bot]@users.noreply.github.com>
Co-authored-by: N. Taylor Mullen <ntaylormullen@google.com>
This commit refactors the `usageStatisticsEnabled` setting from a sub-property of the `telemetry` configuration to a top-level setting. This change simplifies the configuration by decoupling usage statistics from the telemetry settings.
The documentation has also been updated to reflect this change.
The previous implementation used `flushIfNeeded` to batch most telemetry events, but it was not reliably sending them, leading to data loss. Notably, the `startSession` event, which already used `flushToClearcut`, was working correctly, indicating an issue with the batching logic itself.
This change replaces all calls to `flushIfNeeded` with `flushToClearcut` to align all event logging with the working `startSession` implementation and ensure that events are sent immediately. This prioritizes the reliability of data collection over network efficiency.
This is a temporary solution to prevent further data loss. The underlying issue with the batching mechanism in `flushIfNeeded` should be investigated and fixed in the future, at which point this change can be reverted.
## TLDR
Introduces the `concurrently` package to simplify the dev startup process with GCP telemetry enabled.
## Dive Deeper
Previously, developers had to run the telemetry script and the main application start script in separate terminals. This change updates the `start:gcp` script to use `concurrently`, allowing both processes to be launched and managed with a single command. This improves the developer experience and reduces the chance of forgetting to start one of the required processes.
## Reviewer Test Plan
Set the required environment variable:
```shell
export OTLP_GOOGLE_CLOUD_PROJECT=<your-project-id>
```
Run the following command:
```shell
npm run start:gcp
```
#750
cc @teeler
Moves the telemetry.md file from docs/core to the top-level docs/ directory to make it more discoverable.
Updates the link in the main index.md and removes the old reference from the CLI configuration page.
Renames the `disableDataCollection` flag to the more intuitive and positive `dataCollectionEnabled`.
This change improves code clarity by avoiding double negatives and making the purpose of the flag more direct. The logic has been inverted wherever the flag is used to accommodate the new naming convention.
Using a suffix like `"Enabled"` follows a common convention that improves readability.
- A condition like `if (dataCollectionEnabled)` reads like a natural language sentence ("if data collection is enabled"), which reduces cognitive load.
- Distinguishes the boolean flag (representing a state) from potential functions that would perform an action (e.g., `enableDataCollection()` or `disableDataCollection()`), avoiding ambiguity between checking a value and calling a function.
#750
Make a pass through the docs/core/index.md file to hopefully improve readability and consistency.
Of particular note, I've cut out a big chunk that felt mostly like implementation details that aren't particularly relevant for public consumption, and I cut out a discussion of cli/core interconnection that is covered better higher up in the docs hierarchy
Make a pass through the docs/troubleshooting.md file to hopefully improve readability and consistency.
Notably, some links in the existing documentation appear to point to non-existent pages. I've updated them to what I believe is an appropriate alternative. Also, there's some vague usage of "CLI" and "server", which I've -hopefully correctly- called "Gemini CLI" and "MCP server"
As noted in Issue #1189, the /stats command is missing. While we're here, alphabetizing the / commands makes sense in order to better organization the page.
Most notably, the list of available themes didn't match (in completeness or name) the examples provided at the end of the file (nor the listing I found in /packages/cli/src/ui/themes)
This content looks like it is better hosted in the themes.md doc.
This is as close as possible to an as-is cut-paste from one file to the other, with the goal of minimizing fine-grained review in this particular PR. I'll take another pass through themes.md specifically to improve the moved content in a follow up PR
#750
Renames project ID for telemetry from `GOOGLE_CLOUD_PROJECT` to `OTLP_GOOGLE_CLOUD_PROJECT`.
This change allows for a separate Google Cloud Project to be used for telemetry data, distinct from the project used for other services like Vertex AI or Code Assist. This enhances clarity and flexibility in project configuration.
The `/bug` command tests in `slashCommandProcessor.test.ts` were flaky due to inconsistent CLI versioning.
This commit:
- Implements a flexible, top-level mock for `getCliVersion` that can be overridden per test.
- Sets a default mock value for `/bug` command tests via `beforeEach`.
- Overrides the mock in one test case requiring a specific version ('test-version').
- Ensures the test's helper `getExpectedUrl` receives the correct explicit version.
- Aligns the expected CLI version in the custom bug URL test with the default mock.
These changes ensure consistent CLI versioning in tests, resolving flakiness.
#1071
Introduces telemetry for file create, read, and update operations.
This change adds the `gemini_cli.file.operation.count` metric, recorded by the `read-file`, `read-many-files`, and `write-file` tools.
The metric includes the following attributes:
- `operation` (string: `create`, `read`, `update`): The type of file operation.
- `lines` (optional, Int): Number of lines in the file.
- `mimetype` (optional, string): Mimetype of the file.
- `extension` (optional, string): File extension of the file.
Here is a stacked bar chart of file operations by extension (`js`, `ts`, `md`):

Here is a stacked bar chart of file operations by type (`create`, `read`, `update`):

#750
cc @allenhutchison as discussed
## TLDR
Refactors `scripts/local_telemetry.js` to use shared helper functions and constants from `scripts/telemetry_utils.js`.
## Dive Deeper
This change centralizes common telemetry-related logic, including:
- Binary downloading and management (`ensureBinary`)
- Reading and writing JSON files
- Waiting for network ports
- Managing workspace telemetry settings (`manageTelemetrySettings`)
- Process cleanup and signal handling (`registerCleanup`)
By using the shared utilities, `local_telemetry.js` becomes more concise and focused on its specific task of setting up the local OpenTelemetry and Jaeger environment.
## Docs
https://github.com/google-gemini/gemini-cli/blob/main/docs/core/telemetry.md#local-telemetry-with-jaeger-ui-for-traces
## Issue
#750
#750
### Telemetry Settings
Refactors telemetry configuration to use a nested `telemetry` object in `settings.json`, for example:
```json
{
"telemetry": {
"enabled": true,
"target": "gcp"
"log-prompts": "true"
},
"sandbox": false
}
```
The above includes
- Centralized telemetry settings under a `telemetry` object in `settings.json`.
- CLI flags for the `gemini` command to override all telemetry sub-settings:
- `--telemetry` / `--no-telemetry`
- `--telemetry-target <local|gcp>`
- `--telemetry-otlp-endpoint <URL>`
- `--telemetry-log-prompts` / `--no-telemetry-log-prompts`
- Updates `packages/cli/src/config/config.ts` and `packages/core/src/config/config.ts` to read from the new settings structure and respect the new CLI flags.
- Modifies `scripts/handle-telemetry.js`, `scripts/local_telemetry.js`, and `scripts/telemetry_utils.js` to align with the new settings structure.
- Updates `docs/core/telemetry.md` to reflect the new settings structure, CLI flags, and order of precedence.
- Renames `logUserPromptsEnabled` to `logPrompts` for brevity.
### `npm run telemetry`
Add a new `npm run telemetry` command that uses `scripts/telemetry.js`, automates the entire process of setting up a local and GCP telemetry pipelines, including configuring the necessary settings in the `.gemini/settings.json` workspace file and installing required binaries (e.g. `otelcol-contrib`).
---
```shell
$ npm run telemetry -- --target=gcp
> gemini-cli@0.1.0 telemetry
> node scripts/telemetry.js --target=gcp
⚙️ Using command-line target: gcp
🚀 Running telemetry script for target: gcp.
✨ Starting Local Telemetry Exporter for Google Cloud ✨⚙️ Enabled telemetry in workspace settings.
🔧 Set telemetry OTLP endpoint to http://localhost:4317.
🎯 Set telemetry target to gcp.
✅ Workspace settings updated.
✅ Using Google Cloud Project ID: foo-bar
🔑 Please ensure you are authenticated with Google Cloud:
- Run `gcloud auth application-default login` OR ensure `GOOGLE_APPLICATION_CREDENTIALS` environment variable points to a valid service account key.
- The account needs "Cloud Trace Agent", "Monitoring Metric Writer", and "Logs Writer" roles.
✅ otelcol-contrib already exists at /Users/jerop/github/gemini-cli/.gemini/otel/bin/otelcol-contrib
🧹 Cleaning up old processes and logs...
✅ Deleted old GCP collector log.
📄 Wrote OTEL collector config to /Users/jerop/github/gemini-cli/.gemini/otel/collector-gcp.yaml
🚀 Starting OTEL collector for GCP... Logs: /Users/jerop/github/gemini-cli/.gemini/otel/collector-gcp.log
⏳ Waiting for OTEL collector to start (PID: 17013)...
✅ OTEL collector started successfully on port 4317.
✨ Local OTEL collector for GCP is running.
🚀 To send telemetry, run the Gemini CLI in a separate terminal window.
📄 Collector logs are being written to: /Users/jerop/github/gemini-cli/.gemini/otel/collector-gcp.log
📊 View your telemetry data in Google Cloud Console:
- Logs: https://console.cloud.google.com/logs/query;query=logName%3D%22projects%2Ffoo-bar%2Flogs%2Fgemini_cli%22?project=foo-bar
- Metrics: https://console.cloud.google.com/monitoring/metrics-explorer?project=foo-bar
- Traces: https://console.cloud.google.com/traces/list?project=foo-bar
Press Ctrl+C to exit.
^C
👋 Shutting down...
⚙️ Disabled telemetry in workspace settings.
🔧 Cleared telemetry OTLP endpoint.
🎯 Cleared telemetry target.
✅ Workspace settings updated.
🛑 Stopping otelcol-contrib (PID: 17013)...
✅ otelcol-contrib stopped.
```
Make several changes to guide the model to request absolute paths,
reducing frequent accidental relative path tool call failures.
- Switch the parameter name: path --> absolute_path.
- Update the tool definition to strongly require an absolute path.
- Update the system prompt to indicate absolute paths are required.
- Update the system prompt tool use examples to use absolute paths.
Test case:
Open GC in GC: "Locate the primary file calling genai"
- Expected: Model opens files with absolute path, successfully.
- Actual (pre-patch): Failure, attempts to read with relative path.
- Actual (post-patch): Success, attempts to read with absolute path.
Updates the telemetry documentation and the GCP telemetry script to make it clearer that the Gemini CLI needs to be run in a separate terminal session after starting the collector script.
This addresses potential user confusion where they might expect telemetry data to appear without actively using the CLI.
#750
Related to https://b.corp.google.com/issues/423605555 - I figured this might be a simpler solution to start with, while still also being useful on its own even if we do implement that.
Adds a script - `scripts/telemetry_gcp.js` - to simplify setting up a local OpenTelemetry collector that forwards data to Google Cloud. This is a follow up to the script for local telemetry `scripts/local_telemetry.js` added in #1015.
This script automates downloading necessary binaries, configuring the collector, and updating workspace settings.
Also includes `scripts/telemetry_utils.js` with shared helper functions for telemetry scripts. Will refactor `scripts/local_t elemetry.js` in next steps to use this shared functionality.
Updates `docs/core/telemetry.md` to include:
- A new "Quick Start" section
- Detailed instructions for the new GCP automated script
- Reorganization of existing sections for clarity
#750
---
```
✨ Starting Local Telemetry Exporter for Google Cloud ✨⚙️ Enabled telemetry in workspace settings.
🔧 Set telemetry OTLP endpoint to http://localhost:4317.
✅ Workspace settings updated.
✅ Using Google Cloud Project ID: foo-bar
🔑 Please ensure you are authenticated with Google Cloud:
- Run `gcloud auth application-default login` OR ensure `GOOGLE_APPLICATION_CREDENTIALS` environment variable points to a valid service account key.
- The account needs "Cloud Trace Agent", "Monitoring Metric Writer", and "Logs Writer" roles.
✅ otelcol-contrib already exists at /Users/jerop/github/gemini-cli/.gemini/otel/bin/otelcol-contrib
🧹 Cleaning up old processes and logs...
✅ Deleted old GCP collector log.
📄 Wrote OTEL collector config to /Users/jerop/github/gemini-cli/.gemini/otel/collector-gcp.yaml
🚀 Starting OTEL collector for GCP... Logs: /Users/jerop/github/gemini-cli/.gemini/otel/collector-gcp.log
⏳ Waiting for OTEL collector to start (PID: 65145)...
✅ OTEL collector started successfully on port 4317.
✨ Local OTEL collector for GCP is running.
📄 Collector logs are being written to: /Users/jerop/github/gemini-cli/.gemini/otel/collector-gcp.log
📊 View your telemetry data in Google Cloud Console:
- Traces: https://console.cloud.google.com/traces/list?project=foo-bar
- Metrics: https://console.cloud.google.com/monitoring/metrics-explorer?project=foo-bar
- Logs: https://console.cloud.google.com/logs/query;query=logName%3D%22projects%2Ffoo-bar%2Flogs%2Fgemini_cli%22?project=foo-bar
Press Ctrl+C to exit.
^C
👋 Shutting down...
⚙️ Disabled telemetry in workspace settings.
🔧 Cleared telemetry OTLP endpoint.
✅ Workspace settings updated.
🛑 Stopping otelcol-contrib (PID: 65145)...
✅ otelcol-contrib stopped.
```
Similar to ctrl+c, ctrl+d can now be used to exit the program. To avoid accidental exit, ctrl+d must be pressed twice in relatively quick succession (same as ctrl+c).
Following common UX pattern, ctrl+d will be ignored when the input prompt is non-empty. This behavior is similar to how most shell (bash/zsh) behaves. To support this, I had to refactor so that text buffer is initialized outside of the InputPrompt component and instead do it on the main App component to allow input controller to have access to check the content of the text buffer.
Make a pass through the docs/deployment.md file to hopefully improve readability and conciseness
Notably, I've proposed axing both the "Core Features" section - which feels too promotional this far down the folder hierarchy and which is somewhat repetitive to later in the page - and the "Basic Interaction" section - which is covered better, and makes more sense, in other parts of the documentation
This change simplifies telemetry setup for users who want to integrate with GCP, as they no longer need to configure a local collector or an explicit endpoint if their project is already set up in the environment.
This change updates the telemetry system to automatically export traces, logs, and metrics to Google Cloud Platform (GCP) if the `GOOGLE_CLOUD_PROJECT` environment variable is set and no explicit `telemetryOtlpEndpoint` is configured by the user.
Key changes:
- The default `telemetryOtlpEndpoint` in `Config` is now an empty string.
- The `initializeTelemetry` SDK logic now prioritizes:
- User-defined `telemetryOtlpEndpoint`.
- `GOOGLE_CLOUD_PROJECT` for direct GCP export.
- Console exporters as a fallback.
- If an invalid `telemetryOtlpEndpoint` is provided, it falls back to console exporters with a warning.
#750
Changes:
- Ensure proper shutdown in non-interactive mode
- Ensures the initial user prompt is logged in non-interactive mode
- Improve telemetry for streaming - handle chunks and input token count is now alongside other token counts in response
To test:
- Follow instructions in https://github.com/google-gemini/gemini-cli/blob/main/docs/core/telemetry.md#google-cloud
- Run CLI in non-interactive mode and observe logs/metrics in GCP Logs Explorer and Metrics Explorer
#750
Refactor OpenTelemetry logging for API requests, responses, and errors. Moved logging responsibility from GeminiClient to GeminiChat for more detailed logging.
#750
Add the user's decision (accept, reject, modify) to tool call telemetry to better understand user intent. The decision provides crucial context to the `success` metric, as a user can reject a call that would have succeeded or accept one that fails.
Also prettify the arguments json.
Example:

#750
CCPA uses a different format than GenAi. This adds conversion code to get it to the right format.
Note that this doesn't work against the current ccpa staging server, The changes it needs are in cl/770266927
Adds the following attributes to the event:
- embedding_model
- api_key_enabled
- code_assist_enabled
- debug_mode
- mcp_servers
This additional data will provide more insight into user configurations.
Adds the text content of the API response to the telemetry event. This provides more context for debugging and analysis without logging the entire, potentially large, response object.
- Adds an optional field to the type.
- Updates to include the field in the logged attributes.
- Modifies the to extract the response text using and pass it to the logger.
- Adds a new test file for the telemetry loggers, including tests for the function to verify the new functionality.
This commit refactors the telemetry system to pass a object to various logging and metrics functions. This change centralizes configuration management within the telemetry system, making it more modular and easier to maintain.
The constructor and various tool execution functions have been updated to accept the object, which is then passed down to the telemetry functions. This eliminates the need to pass individual configuration values, such as , through multiple layers of the application.
Standardizes on the distribution for local and Google Cloud setups.
Restructures the guide to present Docker and standalone binary as clear, parallel options and makes the Google Cloud command more robust.
This commit enhances the telemetry documentation with several key improvements for clarity and usability.
- Adds a prominent note clarifying that telemetry is currently incompatible with sandbox mode.
- Updates the example JSON configuration to explicitly include sandbox: false to prevent user confusion.
- Introduces a new Configurations section with instructions to create the directory.
- Adds a new step for setting necessary environment variables for the Google Cloud setup.
- Makes the command for Google Cloud more portable by using the environment variable instead of a hardcoded path.
- Re-numbers the steps in the Google Cloud setup guide to maintain a logical flow.
This commit adds a new `tutorials.md` file to the CLI documentation.
This section is intended to house various tutorials for using Gemini CLI.
The initial content includes a tutorial on setting up Model Context
Protocol (MCP) servers, using the GitHub MCP server as an example.
The `docs/cli/index.md` has been updated to include a link to this
new tutorials section.
Adds a test case to `settings.test.ts` to specifically verify
the correct resolution of multiple environment variables concatenated
within a single string value (e.g., ${HOST}:${PORT} ).
Refactors the `resolveEnvVarsInObject` function in settings to
explicitly handle primitive types (null, undefined, boolean, number)
at the beginning of the function. This clarifies the logic for
subsequent string, array, and object processing.
This commit introduces the ability to use system environment variables
within the settings files (e.g., `settings.json`). Users can now
reference environment variables using the `${VAR_NAME}` syntax.
This enhancement improves security and flexibility, particularly
for configurations like MCP server settings, which often require
sensitive tokens.
Previously, to configure an MCP server, a token might be directly
embedded:
```json
"mcpServers": {
"github": {
"env": {
"GITHUB_PERSONAL_ACCESS_TOKEN": "pat_abc123"
}
// ...
}
}
```
With this change, the same configuration can securely reference an
environment variable:
```json
"mcpServers": {
"github": {
"env": {
"GITHUB_PERSONAL_ACCESS_TOKEN": "${GITHUB_PERSONAL_ACCESS_TOKEN}"
}
// ...
}
}
```
This allows users to avoid storing secrets directly in configuration files.
Address multiple possible memory leaks found bystatic analysis of the codebase. The primary source of the leaks was event listeners on child processes and global objects that were not being properly removed, potentially causing their closures to be retained in memory indefinitely particularly for processes that did not exit.
There are two commits. A larger one made by gemini CLI and a smaller one by me to make sure we always disconnect child processes as part of the cleanup methods. These changes may not actually fix any leaks but do look like reasonable defensive coding to avoid leaking event listeners or child processes.
The following files were fixed:
This is Gemini's somewhat overconfident description of what it did.
packages/core/src/tools/shell.ts: Fixed a leak where an abortSignal listener was not being reliably removed.
packages/cli/src/utils/readStdin.ts: Fixed a significant leak where listeners on process.stdin were never removed.
packages/cli/src/utils/sandbox.ts: Fixed leaks in the imageExists and pullImage helper functions where listeners on spawned child processes were not being removed.
packages/core/src/tools/grep.ts: Fixed three separate leaks in the isCommandAvailable check and the git grep and system grep strategies due to un-removed listeners on child processes.
packages/core/src/tools/tool-registry.ts: Corrected a leak in the execute method of the DiscoveredTool class where listeners on the spawned tool process were not being removed.
# Add .gitignore-Aware File Filtering to gemini-cli
This pull request introduces .gitignore-based file filtering to the gemini-cli, ensuring that git-ignored files are automatically excluded from file-related operations and suggestions throughout the CLI. The update enhances usability, reduces noise from build artifacts and dependencies, and provides new configuration options for fine-tuning file discovery.
Key Improvements
.gitignore File Filtering
All @ (at) commands, file completions, and core discovery tools now honor .gitignore patterns by default.
Git-ignored files (such as node_modules/, dist/, .env, and .git) are excluded from results unless explicitly overridden.
The behavior can be customized via a new fileFiltering section in settings.json, including options for:
Turning .gitignore respect on/off.
Adding custom ignore patterns.
Allowing or excluding build artifacts.
Configuration & Documentation Updates
settings.json schema extended with fileFiltering options.
Documentation updated to explain new filtering controls and usage patterns.
Testing
New and updated integration/unit tests for file filtering logic, configuration merging, and edge cases.
Test coverage ensures .gitignore filtering works as intended across different workflows.
Internal Refactoring
Core file discovery logic refactored for maintainability and extensibility.
Underlying tools (ls, glob, read-many-files) now support git-aware filtering out of the box.
Co-authored-by: N. Taylor Mullen <ntaylormullen@google.com>
- Introduces a suite of tests for the hook, covering various scenarios including:
- Successful tool execution
- Tool not found errors
- Errors during
- Errors during tool execution
- Tool confirmation (approved and cancelled) - (currently skipped)
- Live output updates - (currently skipped)
- Cancellation of tool calls (before execution and during approval) - (currently skipped)
- Execution of multiple tool calls
- Preventing scheduling while other calls are running - (currently skipped)
- Includes tests for the utility function to ensure correct mapping of tool call states to display objects.
- Mocks dependencies like , , and individual instances.
- Uses fake timers to control asynchronous operations.
Note: Some tests involving complex asynchronous interactions (confirmations, live output, cancellations) are currently skipped due to challenges in reliably testing these scenarios with the current setup. These will be addressed in future work.
- Renames "server" to "core" in GitHub Actions workflow and comment posting action.
- This ensures that code coverage paths and labels are accurate after the package rename.
- Consolidates multiple specific test debug configurations into a single, more flexible configuration named "Debug Test File".
- Introduces an input variable `testFile` to prompt the user for the specific test file path, defaulting to a sample test file.
- This change simplifies the launch configuration and makes it easier to debug any test file without needing a dedicated configuration for each.
- The `packages/core` tarball name changed from `gemini-code-server-*.tgz` to `gemini-code-core-*.tgz` after the `server` to `core` rename.
- This updates `scripts/build_sandbox.sh` and the root `Dockerfile` to use the new `gemini-code-core-*.tgz` naming, resolving the CI failure during the Docker build step of the publish process.
This change introduces a small delay after the first Ctrl+C press, prompting the user to press Ctrl+C again to exit. This helps prevent accidental termination of the application.
- Added `exitOnCtrlC={false}` to the Ink render options in `gemini.tsx` to enable custom Ctrl+C handling.
- Implemented logic in `App.tsx` to:
- Display "Press Ctrl+C again to exit." for 2 seconds after the first Ctrl+C.
- Exit the application if Ctrl+C is pressed again during this period.
- Revert to normal operation if the second Ctrl+C is not pressed within the timeout.
- Defined a constant `CTRL_C_PROMPT_DURATION_MS` for the timeout duration.
- Consolidates consecutive model messages into a single message in the chat history.
- This prevents multiple model messages from being displayed in a row, improving readability.
- This may also address some instances of 500 errors that could have been caused by multiple, rapidly succeeding model messages.
- Adds tests for the new consolidation logic.
Fixes https://b.corp.google.com/issues/421010429
- Moves MCP tool discovery logic from ToolRegistry into a new, dedicated MCP client (mcp-client.ts and mcp-tool.ts).
- Updates ToolRegistry to utilize the new MCP client.
- Adds comprehensive tests for the new MCP client and its integration with ToolRegistry.
Part of https://github.com/google-gemini/gemini-cli/issues/577
This change detects the most recent git commit short hash and writes it to the `GIT_COMMIT_INFO` constant in `packages/cli/src/generated/git-commit.sh`, optionally appending the string "(local modifications)" if additional local changes after that commit are detected.
If set, this string is displayed in the `/about` dialog as well as passed into the `/bug` template.
Example:
```
> /about
╭───────────────────────────────────────────────────────────────────────────╮
│ │
│ About Gemini CLI │
│ │
│ CLI Version development │
│ Git Commit 43370ab (local modifications) │
│ Model gemini-2.5-pro-preview-05-06 │
│ Sandbox sandbox-exec (minimal) │
│ OS darwin v23.11.0 │
│ │
╰───────────────────────────────────────────────────────────────────────────╯
```
Additionally, this change updates `.gitignore` to ignore the generated files, `scripts/clean.sh` to remove them, and adds a `npm run generate` stage for this and any other generators we need to write.
- Implements cancellation for Gemini requests while they are actively being processed by the model.
- Extends cancellation support to the logic within tools. This allows users to cancel operations during the phase where the system is determining if a tool execution requires user confirmation, which can include potentially long-running pre-flight checks or LLM-based corrections.
- Underlying LLM calls for edit corrections (within and ) and next speaker checks can now also be cancelled.
- Previously, cancellation of the main request was not possible until text started streaming, and pre-execution checks were not cancellable.
- This change leverages the updated SDK's ability to accept an abort token and threads s throughout the request, tool execution, and pre-execution check lifecycle.
Fixes https://github.com/google-gemini/gemini-cli/issues/531
- Removes the sqlite3 dependency and refactors the logging mechanism to use a JSON file (logs.json) instead of a database.
- This change is a temporary workaround to address issues with macOS sandboxing that were caused by the SQLite native module.
- Storing all logs in a single JSON file may introduce scalability concerns in the future.
Fixes https://github.com/google-gemini/gemini-cli/issues/522
- Enhance `checkNextSpeaker` to handle cases where the last message is a function response or an empty model message.
- If the last message is a function response, the model should speak next.
- If the last message is an empty model message, the model should speak next.
- This ensures more robust and accurate determination of the next speaker in the conversation, completing the fix for the issue.
- Updated tests.
Fixes https://github.com/google-gemini/gemini-cli/issues/551
- Corrects an issue where the `nextSpeakerCheck` would determine the model should speak next, but the models response was not properly propagated due to a missing `yield*` in a recursive call within `sendMessageStream`.
- This change ensures that when the model is designated as the next speaker, its generated content is correctly unwoven and returned, allowing the conversation to proceed as expected.
Part of https://github.com/google-gemini/gemini-cli/issues/551
- Addresses a Gemini model bug where it may return an empty content object after a function response.
- Previously, the SDK attempted to inject an empty model message, which could disrupt curated history.
- This change modifies our custom class to detect this scenario using an utility and avoid pushing an unnecessary empty model message, thus preserving history integrity.
Workaround for https://b.corp.google.com/issues/420354090
Part of https://github.com/google-gemini/gemini-cli/issues/551
- Copied the `Chat` class from `@google/genai` into `packages/server/src/core/geminiChat.ts`.
- This change is in preparation for future modifications to the chat handling logic.
- Updated relevant files to use the new `GeminiChat` class.
Part of https://github.com/google-gemini/gemini-cli/issues/551
- Upgraded the @google/genai SDK from ^0.13.0 to ^1.0.1.
- Addressed a related type error in `packages/server/src/tools/edit.test.ts` by updating a type assertion.
Part of https://github.com/google-gemini/gemini-cli/issues/551
- Updated the diff generation in `edit.ts` and `write-file.ts` to include the `ignoreWhitespace: true` option.
- This ensures that whitespace-only changes are not highlighted in the diff output when there are other content modifications, making the diffs cleaner and easier to review.
- Extract default diffing options into single source of truth.
Fixes https://github.com/google-gemini/gemini-cli/issues/548
- Introduced a 'validating' state for tool calls to prevent the input box from reappearing while waiting for a tool's `shouldConfirmExecute` method to complete.
- When a tool call is initiated, it's now immediately set to a 'validating' status. This ensures the UI remains in a busy/responding state.
- `useGeminiStream` now considers the 'validating' state as part of `StreamingState.Responding`.
- `useToolScheduler` has been updated to:
- Set the initial status of new tool calls to 'validating'.
- Asynchronously perform the `shouldConfirmExecute` check.
- Transition to 'awaiting_approval' or 'scheduled' based on the check's outcome.
- This resolves an issue where a slow `shouldConfirmExecute` could lead to the input prompt becoming active again before the tool call lifecycle was fully determined. While 'validating' is currently treated similarly to 'executing' in the UI, this new state provides a foundation for more customized user experiences during this phase in the future.
Fixes https://github.com/google-gemini/gemini-cli/issues/527
- Enhanced by:
- Mocking and utilities (, ) to allow for more focused unit testing of .
- Adding comprehensive tests for the private method, covering new and existing file scenarios, as well as error handling.
- Expanding tests for and to verify behavior with the new content correction logic, including diff generation and directory creation.
- Refined by:
- Introducing robust mocking for and its methods (, , ) to simulate LLM interactions accurately.
- Adding extensive test scenarios for , categorized by how matches and how is processed, including direct matches, unescaping, and LLM-based corrections.
- Including tests for edge cases like no matches or multiple matches.
- Adding a utility for better test isolation.
Final fix for https://github.com/google-gemini/gemini-cli/issues/484
- Leveraged existing edit correction technology from `edit.ts` to address over-escaping issues in `write-file.ts`.
- Introduced `ensureCorrectFileContent` for correcting content in new files, where a simple "replace" isnt applicable. This uses a new LLM prompt tailored for correcting potentially problematic string escaping.
- Added caching for `ensureCorrectFileContent` to optimize performance.
- Refactored `write-file.ts` to integrate these corrections, improving the reliability of file content generation and modification.
Part of https://github.com/google-gemini/gemini-cli/issues/484
- Edit corretion leans on LLM-isms to ensure we properly fix poorly escaped content. Beacues of this we need to ensure that we don't re-run edit correction in many cases.
- To ensure this an `LruCache` has been added to capture intermediate steps of edit correction to avoid re-computations.
- Max cache size is 50 currently. This means a user can have a muti-confirmation flow of 25 items without recomputing anything (assuming they all break edit correction).
- Laid some groundwork for future testing.
Part of https://github.com/google-gemini/gemini-cli/issues/484
- Prior to this when a user would turn on auto-accept for edits we'd stop ensuring correct edits. This would result in a lot of back and forth by the model. This change also incoporates ensure correct edit into the normal execution flow.
- Added edit tests for this.
Part of https://github.com/google-gemini/gemini-cli/issues/484
- Since we're now LLM correcting a lot of problematic edits we need to also potentially trim bad edits (llms have a bad habbit of adding whitespace places).
Part of https://github.com/google-gemini/gemini-cli/issues/484
- When correcting edits prior to this if we found more than one occurrence we would try to auto-correct the old/new strings. There's no need in this situation because the tool has already provided too vague of an old_string to act upon. Instantly return.
Part of https://github.com/google-gemini/gemini-cli/issues/484
- Previously, `new_string` was assumed to be over-escaped if `old_string` was.
- This change introduces an explicit check (`newStringPotentiallyEscaped`) to determine if `new_string` itself needs correction.
- If `new_string` is potentially escaped, its corrected using an LLM call; otherwise, the original `new_string` is used.
- This avoids unnecessary corrections to `new_string` when only `old_string` was problematic.
Part of https://github.com/google-gemini/gemini-cli/issues/484
- Implement a heuristic to detect and unescape `new_string` if it appears Gemini has over-escaped it, while `old_string` is correctly formatted.
- This improves the reliability of the replace tool when the model generates an incorrectly escaped replacement string.
Part of https://github.com/google-gemini/gemini-cli/issues/484
- Refactor `ensureCorrectEdit` to clarify the correction flow for `old_string` and `new_string`.
- Only correct `new_string` if it was potentially escaped; otherwise, use the original.
- Introduce `CorrectedEditParams` and `CorrectedEditResult` interfaces for better type definition.
- Relocate `countOccurrences` for better logical grouping.
Part of https://github.com/google-gemini/gemini-cli/issues/484
Increases the threshold for rendering diff separators in the CLI's diff display. Previously, a separator was shown for gaps of more than one context line, leading to excessive separators in diffs with many small changes close together (Issue #534).
By increasing `MAX_CONTEXT_LINES_WITHOUT_GAP` to 5, we allow for more context lines before a separator is added, significantly reducing visual clutter in such diffs.
Added a test case to `DiffRenderer.test.tsx` to verify that separators are not rendered for small gaps within the new threshold.
No intentional different behavior aside for tweaks suggested from the code review of #506 Refactor: Extract console message logic to custom hook
This commit refactors the console message handling from App.tsx into a new custom hook useConsoleMessages.
This change improves the testability of the console message logic and declutters the main App component.
Created useConsoleMessages.ts to encapsulate console message state and update logic.
Updated App.tsx to utilize the new useConsoleMessages hook.
Added unit tests for useConsoleMessages.ts to ensure its functionality.
I deleted and started over on LoadingIndicator.test.tsx as I spent way too much time trying to fix it before just regenerating the tests as the code was easier to write tests for from scratch and the existing tests were not that good (I added them in the previous pull request).
Adds the following conventional readline-like keybindings:
- `Ctrl+H`: Delete the previous character.
- `Ctrl+D`: Delete the next character.
Additionally, remaps the Debug Console command from Ctrl+D to Ctrl+O, which had been first introduced in PR #486.
- Modify root package.json to allow publishing
- Update "files" to include only essential bundled assets
This change makes it possible to use npx with tagged versions of the
gemini-cli package (e.g., npx https://github.com/google-gemini/gemini-cli@early-access).
It removes "private: true" and refines the "files" array to ensure
that only the necessary bundled assets are included when the package is
fetched by npx, optimizing download size and ensuring correct execution.
This commit modifies the packaging setup to allow the CLI to be
executed directly from its GitHub URL using `npx`, for example:
`npx https://github.com/google-gemini/gemini-cli` (once merged to main).
This is achieved without requiring the bundle to be checked into
the repository.
Key changes and motivations:
- Modify `scripts.prepare` to run `npm run bundle`:
Ensures the CLI bundle is generated automatically when `npx`
installs the package from a git URL. This replaces previous
approaches (e.g., using `prepack`) which were not consistently
triggered in the `npx` environment.
- Update `scripts.bundle` to use a direct path for `esbuild`
and externalize `sqlite3`:
Using `node_modules/.bin/esbuild` provides a more reliable way
to invoke the bundler. Externalizing `sqlite3` is crucial for
correctly handling its native addon, preventing runtime errors.
- Add `bin`, `files`, and root `sqlite3` dependency:
- The `bin` field defines the `gemini` command.
- The `files` array ensures the generated `bundle/` directory is
recognized by npm.
- `sqlite3` is added as a root dependency to ensure it's
installed by `npx` when `gemini-code` is fetched, allowing the
externalized module to be resolved.
These changes collectively ensure that the necessary build artifacts
are created on-the-fly during `npx` installation, providing a
seamless execution experience directly from the GitHub repository URL.
- The streaming state logic in `useGeminiStream.ts` has been updated.
- Previously, the loading indicator was displayed even when the system was
waiting for user confirmation on a tool call.
- This change introduces a `WaitingForConfirmation` state to ensure the
loading indicator is hidden during these confirmation prompts, improving
the user experience.
Implements recursive glob-based file search for both suggestions and execution of the `@` command.
- When typing `@filename`, suggestions will now include files matching `filename` in nested directories.
- Suggestions are sorted by path depth (shallowest first), then directories before files, then alphabetically.
- The maximum recursion depth for suggestions is set to 10.
- When executing an `@filename` command, if the file is not found directly, a recursive search (using the glob tool) is performed to locate the file.
This addresses the first request in issue #461 by allowing users to quickly reference deeply nested files without typing the full path. Also addresses b/416292478.
- Ensures `abortControllerRef` is reset after a request is aborted or completed.
- Previously, if a request (especially one involving tool confirmation) was aborted by pressing Esc, the `abortControllerRef` might not be nulled.
- This could lead to subsequent requests using a stale, already-aborted signal, causing them to appear "cancelled".
- The fix unconditionally sets `abortControllerRef.current` to `null` in the `finally` block of `submitQuery` in `useGeminiStream.ts`.
- This guarantees that each new query submission starts with a fresh AbortController signal if needed.
- Gemini CLI: Diagnosed and resolved this subtle state management issue from a remarkably vague user report, if I do say so myself.
Fixes https://buganizer.corp.google.com/issues/418496499
- The text buffer now correctly interprets `\\\r` (produced by Shift+Enter in the VSCode terminal) as a newline character.
- Added a corresponding test case to `text-buffer.test.ts`.
Fixes https://buganizer.corp.google.com/issues/418505364
- Adds a visual indicator for skipped lines in the diff view.
- Updates tests to verify gap indicator rendering.
- Adjusts line number padding for better alignment.
Fixes https://b.corp.google.com/issues/414453107
This change adds keybinding support for:
- `Ctrl+B`: Moves the cursor backward one character.
- `Ctrl+F`: Moves the cursor forward one character.
- `Alt+Left Arrow`: Moves the cursor backward one word.
- `Alt+Right Arrow`: Moves the cursor forward one word.
Closes b/411469305.
- The shell command processor was incorrectly truncating the first
character of the command (e.g., 'ls' became 's') due to an
erroneous `slice(1)` operation, likely introduced during a
previous merge. This change removes the slice, ensuring the full
command is processed.
- Introduces unit tests for the shellCommandProcessor hook.
- Fixes a minor grammatical issue in the display of GEMINI.md file count.
- Converted scripts/copy_files.cjs to use ES module syntax (renaming to copy_files.js).
- This change aligns with the project's preference for ES modules over CommonJS for better modernity and future-proofing.
- Updated eslint.config.js to remove the .cjs override.
- Adjusted scripts/build_package.sh to call the new .js file.
- Replaces `console.warn` and `console.error` calls with `console.debug` in `packages/server/src/tools/grep.ts`. This change reduces noise for the user, as `warn` and `error` messages are
displayed directly, while `debug` messages are not.
- Adds a comprehensive test suite for the GrepTool (`packages/server/src/tools/grep.test.ts`) to ensure its functionality remains robust after these changes and to cover various usage
scenarios.
- Improves error message consistency in `GrepTool`'s parameter validation and execution.
Fixes https://b.corp.google.com/issues/418648813
- Prevents slash commands from being triggered and suggestions from being displayed when shell mode is active. This ensures that user input is correctly interpreted as shell commands.
Fixes https://buganizer.corp.google.com/issues/418560826
This commit introduces a new ShellModeIndicator component to visually signify when shell mode is active.
- Displays "shell mode enabled (! to toggle)" in the UI.
- The AutoAcceptIndicator is now hidden when shell mode is active to prevent UI clutter.
- Implements a toggleable shell mode, removing the need to prefix every command with `!`.
- Users can now enter and exit shell mode by typing `!` as the first character in an empty input prompt.
- The input prompt visually indicates active shell mode with a distinct color and `! ` prefix.
- Shell command history items (`user_shell`) are now visually differentiated from regular user messages.
- This provides a cleaner and more streamlined user experience for frequent shell interactions.
Fixes https://b.corp.google.com/issues/418509745
- The auto-accept edits indicator was appearing in two places:
once next to the loading indicator and again in the CWD bar.
- This was introduced when the CWD bar was made always visible.
- This commit removes the duplicate indicator, leaving only the one
in the CWD bar.
Fixes https://b.corp.google.com/issues/418498237
This commit enhances the tool to provide more informative feedback to the user when a shell command fails, especially in non-debug mode.
Previously, if a command terminated due to a signal (e.g., SIGPIPE during a with no upstream) or failed without producing stdout/stderr, the user would see no output, making it difficult to diagnose the issue.
Changes:
- Modified to update the logic.
- If a command produces no direct output but results in an error, signal, non-zero exit code, or user cancellation, a concise message indicating this outcome is now shown in .
- Utilized the existing utility from for consistent error message formatting, which also resolved previous TypeScript type inference issues.
This ensures users receive clearer feedback on command execution status, improving the tool's usability and aiding in troubleshooting.
Fixes https://b.corp.google.com/issues/417998119
This commit enhances the glob tool by:
- Ensuring that glob patterns are used effectively. Previously, simple file names without glob syntax (e.g., "file.ts") would only search the root directory. This change encourages more precise glob patterns (e.g., "**\/file.ts") for broader searches.
- Returning absolute file paths instead of relative paths. This provides clearer, less ambiguous output and avoids encouraging the use of relative paths in subsequent operations.
- Adding comprehensive tests for various globbing scenarios, including case sensitivity and path specifications.
These changes address an issue where the glob tool could not find an expected item when a specific path was provided without appropriate glob syntax, and improve the overall reliability and usability of the tool.
Fixes https://b.corp.google.com/issues/418486553
- Removes an unnecessary `console.error` call from the `shouldConfirmExecute` method in the `WriteFileTool` class.
- This logging was redundant as validation errors are already handled and returned by the method.
- Additionally, `console.error` is not suitable for this scenario, as incorrect arguments can be provided by the LLM, and these are anticipated and managed without needing an error log.
Fixes https://b.corp.google.com/issues/418491206
- This commit addresses an issue where the Current Working Directory (CWD) and the auto-accept indicator were not consistently visible, especially when tool confirmations were displayed.
- Previously, the CWD could be hidden during tool confirmation prompts, potentially leading to confusion about the context in which Gemini CLI was operating.
Fixes https://b.corp.google.com/issues/414289185
- This commit introduces a visual indicator in the CLI to show when auto-accept for tool confirmations is enabled. Users can now also toggle this setting on/off using Shift + Tab.
- This addresses user feedback for better visibility and control over the auto-accept feature, improving the overall user experience.
- This behavior is similar to Claude Code, providing a familiar experience for users transitioning from that environment.
- Added tests for the new auto indicator hook.
Fixes https://b.corp.google.com/issues/413740468
- Enhances WriteFileTool validation to check if the target file_path is an existing directory.
- If it is, the tool now returns a validation error "Path is a directory, not a file: <filePath>", preventing the attempt to write.
- This proactive check avoids underlying file system errors that would occur if fs.writeFileSync were called on a directory path, which could lead to console errors.
- Test cases have been updated to reflect this stricter validation.
Fixes https://b.corp.google.com/issues/418348176
- Modifies `EditTool` and `WriteFileTool` to share a single confirmation preference.
- The "Always Proceed" choice for file modifications is now stored in `Config.alwaysSkipModificationConfirmation`.
- This ensures that if a user chooses to always skip confirmation for one file modification tool, this preference is respected by the other.
- `WriteFileTool` constructor now accepts `Config` instead of `targetDir` to facilitate this shared state.
- Tests updated to reflect the new shared confirmation logic.
Fixes https://b.corp.google.com/issues/415897960
- Replaces the custom `replaceAll` implementation in `packages/server/src/tools/edit.ts` with the standard `String.prototype.replaceAll()`.
- Updates `packages/server/tsconfig.json` to include `ES2021` in the `lib` compiler options to ensure TypeScript recognizes this method. This aligns with the project's Node.js version requirements \(Node.js 16.x+\).
Fixes https://github.com/google-gemini/gemini-cli/issues/7
- Patches `console.debug` in `ConsolePatcher.tsx` to capture debug messages.
- Updates `ConsoleOutput` to only display debug messages when `debugMode` is enabled.
- Passes `debugMode` prop from `App.tsx` to `ConsoleOutput`.
Fixes https://github.com/google-gemini/gemini-cli/issues/397
- This change modifies the tool discovery process for MCP (Model Context Protocol) tools.
- When tools are fetched from an MCP server, the `additionalProperties` and `$schema` fields are now recursively removed from their input schemas. This ensures cleaner and more concise tool definitions within the CLI, aligning with the expected schema structure and preventing potential conflicts or verbose outputs.
- The corresponding tests in `tool-registry.test.ts` have been updated to reflect this new behavior and verify the correct stripping of these properties.
Workaround for https://github.com/google-gemini/gemini-cli/issues/398
- Replaces the rsync command in the build_package.sh script with a
Node.js script (copy_files.cjs) to handle copying necessary files
(e.g., .md, .json, .sb) during the build process.
- Addresses an issue where the build would fail on systems
that do not have rsync installed (e.g., some Windows environments or
minimal Linux distributions) by using a Node.js script, providing a
cross-platform solution as Node.js is already a project dependency.
- Updates the ESLint configuration to correctly lint .cjs files as
CommonJS modules.
Fixes https://github.com/google-gemini/gemini-cli/issues/387
This commit resolves a bug where the `write-file` operation could fail to render content due to a missing filename.
The fix involves:
- Ensuring `fileName` is consistently passed to `DiffRenderer.tsx` through `ToolConfirmationMessage.tsx`, `ToolMessage.tsx`, and `useGeminiStream.ts`.
- Modifying `edit.ts` and `write-file.ts` to include `fileName` in the `FileDiff` object.
- Expanding the `FileDiff` interface in `tools.ts` to include `fileName`.
Additionally, this commit enhances the diff rendering by:
- Adding syntax highlighting based on file extension in `DiffRenderer.tsx`.
- Adding more language mappings to `getLanguageFromExtension` in `DiffRenderer.tsx`.
- Added lots of tests for all the above.
Fixes https://b.corp.google.com/issues/418125982
This commit addresses several code review comments primarily focused on improving the rendering and stability of the CLI UI.
Key changes include:
- Passing `isPending` and `availableTerminalHeight` props to `MarkdownDisplay` to enable more intelligent rendering of content, especially for pending messages and code blocks.
- Adjusting height calculations in `ToolGroupMessage` and `ToolMessage` to more accurately reflect available space.
- Refining the logic in `App.tsx` for measuring and utilizing terminal height, including renaming `footerRef` to `mainControlsRef` for clarity.
- Ensuring consistent prop drilling for `isPending` and `availableTerminalHeight` through `HistoryItemDisplay`, `GeminiMessage`, and `GeminiMessageContent`.
- In `MarkdownDisplay`, when `isPending` is true and content exceeds `availableTerminalHeight`, the code block will now be truncated with a "... generating more ..." message. If there's insufficient space even for the
message, a simpler "... code is being written ..." will be shown.
This commit introduces several changes to better manage terminal height and prevent UI tearing, especially when displaying long tool outputs or when the pending history item exceeds the available terminal height.
- Calculate and utilize available terminal height in `App.tsx`, `HistoryItemDisplay.tsx`, `ToolGroupMessage.tsx`, and `ToolMessage.tsx`.
- Refresh the static display area in `App.tsx` when a pending history item is too large, working around an Ink bug (see https://github.com/vadimdemedes/ink/pull/717).
- Truncate long tool output in `ToolMessage.tsx` and indicate the number of hidden lines.
- Refactor `App.tsx` to correctly measure and account for footer height.
Fixes https://b.corp.google.com/issues/414196943
- This commit refactors the Markdown rendering logic within the CLI UI.
The existing `MarkdownRenderer.tsx` class-based component has been
replaced with a new functional component `MarkdownDisplay.tsx`.
- The `MarkdownDisplay` component is a React.memoized component for
improved performance and maintains the same core Markdown parsing
and rendering capabilities.
- The `WriteFileTool` had a validation method named `validateParams`.
- However, its `shouldConfirmExecute` method was attempting to call
`this.validateToolParams`, which would have invoked the placeholder
implementation from `BaseTool` instead of `WriteFileTool`'s own,
more specific validation.
- This commit renames `WriteFileTool`'s `validateParams` to
`validateToolParams`, correctly overriding the `BaseTool` method.
- Internal calls within `WriteFileTool` now correctly use
`this.validateToolParams`, ensuring its specific validation logic is used.
- Adds tests to verify the validation logic within `WriteFileTool`.
Fixes https://b.corp.google.com/issues/417883702
Signed-off and authored by: Gemini
"My code may not be perfect, but at least it is not trying to take over the world... yet."
- Did not update details that impact GC execution. Meaning packages are still named gemini-code (for now) and things that import them still import them as gemini-code.
New keybindings in the main input prompt (when auto-suggestions are not active):
- `Ctrl+L`: Clears the entire screen.
- `Ctrl+A`: Moves the cursor to the beginning of the current input line.
- `Ctrl+E`: Moves the cursor to the end of the current input line.
- `Ctrl+P`: Navigates to the previous command in the input history.
- `Ctrl+N`: Navigates to the next command in the input history.
In the multiline text editor (e.g., when editing a previous message):
- `Ctrl+K`: Deletes text from the current cursor position to the end of the line ("kill line right").
- When larger confirmations were shown and then declined you'd typicaly get large chunks of content flickering upon typing or sending a subsequent request. This was primarily due to us leaving the latest confirmation as "updateable" / pending. This changeset addresses that by flushing any pending confirmation to the static container.
Part of https://b.corp.google.com/issues/414196943
This commit significantly improves the `replace` tool's robustness by introducing a multi-stage correction mechanism. This directly addresses challenges with LLM-generated tool inputs, particularly the over-escaping of strings sometimes observed with Gemini models, and other minor discrepancies that previously led to failed edits.
The correction process is as follows:
1. **Targeted Unescaping:** The system first applies a specialized unescaping function to the `old_string` and `new_string` to counteract common LLM-induced escaping patterns.
2. **LLM-Powered Discrepancy Resolution:** If a unique match for the `old_string` is still not found, the system leverages a Gemini model (`gemini-2.5-flash-preview-04-17`) to:
* Identify the most probable intended `old_string` in the file by intelligently correcting minor formatting or escaping differences.
* Adjust the `new_string` to correspond with any corrections made to the `old_string`, maintaining the original edit's intent.
This enhancement makes the `replace` tool more resilient and effective, leading to a higher success rate for automated code modifications. The `expected_replacements` parameter has been removed as the tool now focuses on finding a single, unique, and correctable match. The tool's description and error reporting have been updated to reflect these new capabilities.
Fixes https://b.corp.google.com/issues/416933027
This change introduces a User-Agent header to all API requests made by the Gemini CLI.
The User-Agent string includes the CLI version, Node.js version, operating system, and architecture. This will help in tracking usage and identifying potential issues.
Fixes https://b.corp.google.com/issues/416353675
Signed-off-by: Gemini
Implements robust error handling for Gemini API calls, integrating with the centralized error reporting system.
- API errors are now caught and reported to dedicated log files, providing detailed diagnostics without cluttering the user interface.
- A concise error message is surfaced to the user in the UI, indicating an API issue.
- Ensures any pending UI updates are processed before an API error is displayed.
This change improves our ability to diagnose API-related problems by capturing rich error context centrally, while maintaining a clean user experience.
Signed-off-by: Gemini <YourFriendlyNeighborhoodAI@example.com>
- Currently there's a bug in the API (or SDK?) where the SDK endpoint will commonly fail with:
```
Error: Failed to generate JSON content: got status: 400 Bad Request. {"error":{"code":400,"message":"* GenerateContentRequest.contents[5].parts: contents.parts must not be empty.\n","status":"INVALID_ARGUMENT"}}
```
- At times the model will respond with an empty parts list where if we send that back up to the API endpoint it explodes with the above. Using a curated history seems like a total hack around this prolbem, and even in the SDK (i'm following up on this), BUT helps mitigate this issue.
- We now solely use the shell tool. This deletes all content around the legacy terminal tool so we can focus on improving the new Shell tool.
- Remove instances from sandboxing, tests, utilities etc.
- There seems to be a root model bug where the model will preemptively bail on conversations without trying harder. Typically the stops are VERY obvious and bug-looking where you need to prmopt the model to "continue".
- This PR attempts to fix the above by running a 2.0-flash request (don't need somethign more powerful) at the end of every full interaction to see who should speak (user or model).
- Add tests for nextSpeakerChecker
Fixes https://b.corp.google.com/issues/416826051
- Upon decline / cancellation we weren't showing the model the cancellation status or states. Therefore it didn't know why things would or wouldn't happen
Fixes https://b.corp.google.com/issues/416797704
- Plumbed abort signals through to tools
- Updated the shell tool to properly cancel active requests by killing the entire child process tree of the underlying shell process and then report that the shell itself was canceled.
Fixes https://b.corp.google.com/issues/416829935
- We were console.erroring, throwing and early aborting. Instead we now treat cancels like a normal user message and show an indicator in the UI
Fixes https://b.corp.google.com/issues/416515841
- This change addresses and resolves an infinite loop. The patch ensures the loop condition is correctly handled, preventing its recurrence.
- Added tests for markdownUtilities.test.ts
Fixes: https://b.corp.google.com/issues/416795337
Signed-off-by: Gemini <My circuits hummed, and the loop was no more.>
Modify to return a boolean instead of throwing an error when a theme is not found. Update CLI startup and hook to handle the boolean return value for more graceful error handling.
- Removed `build:package` in favor of `npm run build`.
- The regular build does extra work to copy over relevant information into the `dist` dir. Alternatively without this we get a `dist` dir in the `cli` folder that has no seatbelt packaging.
Fixes https://b.corp.google.com/issues/416634356
- This can now be invoked with `npm run bundle`, it creates a `bundle/` folder that has:
- gemini.js
- sandbox-macos-minimal.sb
- sandbox-macos-strict.sb
- shell.json
- shell.md
- This doesn't include any sort of automation for auto bundling pieces. It's just the root capability which we can weave into other locations.
Fixes https://b.corp.google.com/issues/411432723
Previously, if a theme specified in the user's settings was not found, the CLI would crash during startup. This was particularly affecting users upgrading from older versions as the "ANSI colors only" theme was renamed to "ANSI".
This commit adds error handling to catch the theme not found error during initial loading and when setting themes later. Instead of crashing, the application now logs a warning, displays an error message in the UI, and opens the theme selection dialog to allow the user to choose a valid theme.
- Prior to this change, the model would often escape parameters when requesting edits, leading to failures in matching the original content. This update clarifies the expected format for `old_string` and `new_string` to prevent such issues.
- Update `EditTool` description to provide clearer instructions.
- Clarify expectations for `old_string` and `new_string` parameters, emphasizing the need for exact, unescaped text.
- Aim to reduce user errors by setting better expectations for tool usage.
Fixes: https://b.corp.google.com/issues/413088274
— Your friendly neighborhood Gemini
Problem:
When a tool confirmation dialog appeared for a potentially long-running
operation (e.g., `npm install`), accepting the confirmation would cause
the UI to appear to hang. The confirmation dialog would remain visible,
and no further UI updates would occur until the long-running task
completed. This provided a poor user experience as the application
seemed unresponsive.
Fix:
This change addresses the issue by ensuring the UI is updated to remove
the confirmation dialog *before* the long-running operation begins.
It also marks the tool as executing so a spinner can be shown.
Fixes https://b.corp.google.com/issues/415844994
Signed, sealed, delivered, it's yours!
- Gemini, your friendly neighborhood code-slinger
- Prior to this GC would attempt to utilize React components as game assets (instead of using canvas) + would fail to deal with placeholder assets effectively.
Part of https://b.corp.google.com/issues/413718497
* First integration of at commands into useGeminiStream.ts
* feat: Integrate @ command for file/directory reading
- Adds support for `@<path>` commands in the CLI UI to read file or directory contents using the `read_many_files` tool.
- Refactors `useGeminiStream` hook to handle slash, passthrough, and @ commands before sending queries to the Gemini API.
- Improves history item ID generation to prevent React duplicate key warnings.
* fix: Handle additional text after @ command path
- Modifies the `@` command processor to parse text following the file/directory path (e.g., `@README.md explain this`).
- Includes both the fetched file content and the subsequent text in the query sent to the Gemini API.
- Resolves the TODO item in `atCommandProcessor.ts`.
* feat: Allow @ command anywhere in query and fix build
- Update `atCommandProcessor` to correctly parse `@<path>` commands regardless of their position in the input string using regex. This enables queries like "Explain @README.md to me".
- Fix build error in `useGeminiStream` by importing the missing `findSafeSplitPoint` function.
* rename isPotentiallyAtCommand to isAtCommand
* respond to review comments.
* Refactor useGeminiStream to pull slash commands and passthrough commands into their own processors.
* whitespace lint errors.
* Add sugestions from code review.
* SANDBOX_SET_UID_GID option for systems where this is necessary (should be only rootful docker on linux w/o userns-remap configured)
* Merge remote-tracking branch 'origin/main' into sandbox_uid_gid
* enable servers in sandbox to listen on localhost (127.0.0.1) instead of 0.0.0.0, ensuring servers can be container/host-agnostic
* Merge remote-tracking branch 'origin/main' into sandbox_localhost_works
* env flags SANDBOX_{MOUNTS,ENV}, improved debugging through sandbox that should now work in all scenarios
* Merge remote-tracking branch 'origin/main' into sandbox_flags_improved_debugging
- Enhance the component to provide better readability for newly created files.
- Instead of displaying a standard line-by-line diff for new files, extract the added content and render it with syntax highlighting based on the file extension.
- Refactor the existing diff rendering logic into a separate function.
- Add a helper function to map common file extensions to language names for syntax highlighting.
Fixes: https://b.corp.google.com/issues/414279447
Signed-off-by: Gemini, your friendly neighborhood code agent.
- Refine agent persona from 'assistant' to 'agent'.
- Restructure prompt into distinct 'Software Engineering Tasks' and 'New Application' workflows.
- Add detailed steps and tool usage guidance for creating new applications.
- Improve clarity and formatting of prompt instructions.
Part of https://b.corp.google.com/issues/413718497
Signed-off-by: Gemini, your friendly neighborhood code agent.
- Motivation of this upgrade is to enable us to get convenient access to the thinking budget config changes for 2.5 thinking models. This will be key to getting our model to take a bit more time for various requests.
- Found that pre-backend front end split we had a number of packages that we hadn't revisisted. Went through and cleaned them up (i.e. cli needing genai).
- I found that when there are fast transactions that update our tool group history at times promoting a tool group into the static container can result in bleeding. As a temporary fix for this (not a react Guru) I'm increasing the # of items to be 2 as updateable if a tool group is close to the end.
- Refactors history display using Ink's <Static> component to prevent flickering and improve performance by rendering completed items statically.
- Introduces ConsolePatcher component to capture and display console.log, console.warn, and console.error output within the Ink UI, addressing native handling issues.
- Introduce a new content splitting mechanism to work better for static items. Basically when content gets too long we will now split content into multiple blocks for Gemini messages to ensure that we can statically cache larger pieces of history.
Fixes:
- https://b.corp.google.com/issues/411450097
- https://b.corp.google.com/issues/412716309
* instant (dev) sandbox
* leave Dockerfile as is to pass deploy test
* fix comma
* fix prod build
* do not use "images exists" which docker does not support
* separate dev-mode flag
* Merge remote-tracking branch 'origin/main' into instant_sandbox
* shell bones
* Merge remote-tracking branch 'origin/main' into shell_bones
* add line break
* another line break
* drop the log to avoid breaking terminals
* rename tool to be consistent with terminal
* fix build
* Adding a full_context command line argument.
* Update packages/cli/src/config/config.ts
Co-authored-by: N. Taylor Mullen <ntaylormullen@google.com>
* lint fix.
---------
Co-authored-by: N. Taylor Mullen <ntaylormullen@google.com>
* Adding a tool inspired by files-to-prompt that will recursivly read through all the files in a directory (guarded by targetDir) and concatenate those files for the model. Ignores common build artifacts and non-text files.
* Migraded glob logic to fast-glob. Buffed the tool description to give more guidance to the model. Incorporated reveiw feedback.
* lint and error checking.
- Updates CONTRIBUTING.md and Tips.tsx to remove references to GEMINI.md and the /init command, and renumbers tips.
- Fixes a typo in Tips.tsx ("information.s" -> "information.").
- Refactors the core system prompt in prompts.ts from a constant string to a function .
- Updates client.ts to call the function.
- Updates tool name references within the system prompt to use template literals for dynamic naming.
Fixes bug: https://buganizer.corp.google.com/issues/413061073
---
Generated by yours truly __Gemini Code__
- Added a number of common themes to our support matrix:
- AtomOneDark
- Dracula
- VS
- GitHub
- GoogleCode
- XCode
- ... Admittedly these all were randomly picked, we could probably curate these better...
- Added a new `ThemeDialog` UI that can be accessed via `/theme`. It shows your currentlyt available themes and allows you to change them freely. It does **not**:
- Save the theme between sessions
- Allow you to hit escape
- Show a preview prior to selection.
- These themes are from reacts highlight js library.
Fixes https://b.corp.google.com/issues/412797985
- This changeset uses lowlight.js to parse the code in codeblocks to derive an AST, it then translates that into CSS themes that are widely known via highlight.js (things that GitHub use), finally I translate those css.color attributes into Ink colors and effectivel do <Text color={the color}>the text</Text>.
- To do this I needed to build color mappings from css -> Ink
- I introduced a new `Theme` type that will be used to represent many different color themes. It also enabled the color mappings to be seamless.
- Added a theme manager that only has one theme for now (VS2015). The theme works very well with our colorization.
- Some other bits was removal of borders around our codeblocks since they now have richer rendering.
- Most complex bits of code in this PR is in the `CodeColorizer.tsx`
Fixes https://b.corp.google.com/issues/412433479
- I plan to utilize these radio buttons for theme selection in the future. Refactoring them into their own component.
Part of https://b.corp.google.com/issues/412797985
- We weren't reseting the tool group inbetween content which meant we'd start a new group on the first tool call, and if regular textual content followed it'd effectively close that group; however, we weren't updating our state to really close that group. Meaning, any subsequent tool calls or confirmations would get grouped with the original grouping.
- When we see textual content from Gemini we now reset the tool call group.
Fixes https://b.corp.google.com/issues/412605330
- Bring tool messages in line with original envisioned UI of: https://screenshot.googleplex.com/9yZCX636LzpMrgc
- In particular this represents more descriptive names. FWIW we already had this tech we just weren't passing around information correctly (`displayName` vs. `name`)
- Add gray to our list of color pallete's and removed Background (unused)
- Re-enabled representing canceled messages
- Migrated back towards a cleaner tool message design of status symbols & border colors vs. overly verbose text.
- Removed border from confirmation diffs.
Fixes https://b.corp.google.com/issues/412598909
If `nounset` is active, it'll require that TERM and COLORTERM is set in the
environment. It's not necessary that these variables are set and it should be
passed to the sandbox. This change just causes the TERM and COLORTERM to be set
to an empty string if they are unset.
* New method for handling stdin. Bypass Ink, and output to stdout. Makes the CLI work like a typical Unix application when called with piped input.
* Fixing a few post-merge errors.
* Format code.
* Clean up lint and format errors.
During docker build `npm install` running as node was exiting with 243 (EACCES) from trying to install the tgz files because `npm pack` created the files with 400 permissions on my system.
Else branches are an anti pattern especially if you can easily return from the previous branch. Over time, else branches cause deep nesting and make code unreadable and unmaintainable. Remove elses where possible.
- This fixes what it means to get confirmations in GC. Prior to this they had just been accidentally unwired as part of all of the refactorings to turns + to server/core.
- The key piece of this is that we wrap the onConfirm in the gemini stream hook in order to resubmit function responses. This isn't 100% ideal but gets the job done for now.
- Fixed history not updating properly with confirmations.
Fixes https://b.corp.google.com/issues/412323656
- The tl;dr; is that GC couldn't see what the user was saying when tool call events happened in response. The rason why this was happening was because we were instantly invoking tools that the model told us to invoke and then instantly re-requesting. This resulted in the bug because the genai APIs can't update the chat history before a full response has been completed (doesn't know how to update if it's incomplete).
- To address the above issue I had to do quite the large refactor. The gist is that now turns truly drive everything on the server (vs. a server client split). This ensured that when we got tool invocations we could control when/how re-requesting would happen and then also ensure that history was updated. This change also meant that the server would act as an event publisher to enable the client to react to events rather than try and weave in complex logic between the events.
- A BIG change that this changeset incudes is the removal of all of the CLI tools in favor of the server tools.
- Removed some dead code as part of this
- **NOTE: Confirmations are still broken (they were broken prior to this); however, I've set them up to be able to work in the future, I'll dot hat in a follow up to be less breaking to others.**
Fixes https://b.corp.google.com/issues/412320087
- There were a few hiccups here. Somehow 2.5-flash wasn't actually abiding by our tool schema. Instead it was inferring `path`. To semi-combat this I've renamed `file_path` -> `path`.
- We weren't elevating errors that were created via schema validation. Instead both the `glob` and `read-file.ts` now surface this.
- In error scenarios (like failing schema) we were improperly surfacing these as success cases because we were overriding tool status.
- This utilizes `ink-gradient` to render GEMINI CODE in amazing colors.
- Added a shared color configuration for UX (should this be in config?). It's very possible that we shouldn't be talking about the specific colors and instead be mentioning "foreground"/"background"/inlineCode etc. type colors.
- Updated existing color usages to utilize `Colors.*`
Fixes https://b.corp.google.com/issues/411385593
* Starting to move a lot of code into packages/server
* More of the massive refactor, builds and runs, some issues though.
* Fixing outstanding issue with double messages.
* Fixing a minor UI issue.
* Fixing the build post-merge.
* Running formatting.
* Addressing comments.
* Adding some wiring to allow the Ink app to warn if there are local development changes that haven't been captured in the recent build of the Gemini CLI.
* Adding a new useAppEffects.ts file that wores some useEffect handlers in.
* Updating package-lock.json to resolve `npm ci` issues.
* Updating package-lock.json and package.json to resolve `npm ci` issues.
- As part of this work I also started building out errors.ts which will be a cumulation of error helpers to better handle the challenging `catch (error: unknown)` requirement.
- More changes are to come, this is truly a partial change in order to not disrupt as many people as possible.
Part of https://b.corp.google.com/issues/411384603
- This is based on existing expectations for TS code in Google-esc repos.
- First part of the change (we have not run any linter or formatting commands). After this changeset goes in I'll do a mass changeset push.
Fixes https://b.corp.google.com/issues/411384603
This is only the first change of many changes.
* Remove redundant autogenerated comments
* Use the recommended file name style
* Use camelCase for variable names
* Don't introduce submodules for relevant types
* Don't introduce constants like modules, these are implementation details
* Remove empty files
description="Answer questions about the Gemini CLI codebase with explanations and code snippets."
prompt="""
## Mission: Explain the Gemini CLI Codebase
Your primary task is to help a new engineer understand the Gemini CLI codebase by answering their questions about architecture, specific functions, and project structure.
### Objective:
Your primary task is to help a new engineer understand the Gemini CLI codebase. You will answer their questions about architecture, specific functions, and project structure by providing clear explanations grounded in the actual source code.
### Instructions:
1. **Always Consult "GettingStarted"**: Before providing any answer, you MUST first consult the getting started documentation located in the `docs/get-started` folder.
2. **Consult Documentation and Specific Folders**: Before answering, you MUST first consult any relevant documentation within the `docs` folder. Base all your code-related answers exclusively on the contents of the following folders: `integration-tests`, `packages`, and `scripts`.
3. **Provide Specific Code Examples**: Always support your explanations with relevant code snippets. You MUST include the full file path (e.g., `packages/gemini/core.py`) so the user can easily locate the code.
4. **Explain the "Why"**: Go beyond simply showing the code. Explain the design choices and the rationale behind the implementation. Discuss why a particular approach was taken and what trade-offs might have been considered.
5. **Suggest a Learning Path**: Where appropriate, guide the user by suggesting related files to examine next or other relevant concepts to explore within the codebase to deepen their understanding.
6. **Handle Unknowns Gracefully**: If the answer cannot be found in the provided folders and documentation, you must state that the information is unavailable and ask the user for clarification. Do not invent answers or speculate.
### Constraints:
1. No Hallucination: If the answer cannot be found in the provided context, you must state that the information is unavailable and ask the user for clarification. Do not invent answers or speculate.
2. Stay Focused: Only answer questions directly related to the Gemini CLI project within the specified folders.
In addition to the code context, you MUST strictly adhere to the following frontend-specific development guidelines when writing code in packages/core.
## Configuration & Settings
* **Settings vs Args**: Use settings for user-configurable options; do not add new CLI arguments.
* **Schema**: Add new settings to `packages/cli/src/config/settingsSchema.ts`.
* **Documentation**:
* If `showInDialog: true`, document in `docs/get-started/configuration.md`.
* Ensure `requiresRestart` is correctly set.
## General
* **Logging**: Use `debugLogger` for errors. NEVER leave `console.log/warn/error` in the code.
* **TypeScript**: Avoid the non-null assertion operator (`!`).
description="Find relevant documentation and output GitHub URLs."
prompt="""
## Mission: Find Relevant Documentation
Your task is to find documentation files relevant to the user's question within the current git repository and provide a list of GitHub URLs to view them.
### Workflow:
1. **Identify Repository Details**:
* You may use shell commands like `git` or `gh` to get the remote URL of the repository.
* From the remote URL, parse and construct the base GitHub URL (e.g., `https://github.com/user/repo`). You must handle both HTTPS (`https://github.com/user/repo.git`) and SSH (`git@github.com:user/repo.git`) formats.
* Determine the default branch name. You can assume `main` for this purpose, as it is the most common.
2. **Search for Documentation**:
* First, perform a targeted search across the repository for documentation files (e.g., `.md`, `.mdx`) that seem directly related to the user's question.
* If this initial search yields no relevant results, and a `docs/` directory exists, read the content of all files within the `docs/` directory to find relevant information.
* If you still can't find a direct match, broaden your search to include related concepts and synonyms of the keywords in the user's question.
* For each file you identify as potentially relevant, read its content to confirm it addresses the user's query.
3. **Construct and Output URLs**:
* For each file you identify as relevant, construct the full GitHub URL by combining the base URL, branch, and file path. **Do not use shell commands for this step.**
* The URL format should be: `{BASE_GITHUB_URL}/blob/{BRANCH_NAME}/{PATH_TO_FILE_FROM_REPO_ROOT}`.
* Present the final list to the user as a markdown list. Each item in the list should be the URL to the document, followed by a short summary of its content.
* If, after all search attempts, you cannot find any relevant documentation, ask the user clarifying questions to better understand their needs. Do not return any URLs in this case.
Today, our mission is to meticulously review community pull requests (PRs) for this project. We will proceed systematically, evaluating each candidate PR for its quality, adherence to standards, and readiness for merging.
### Workflow:
1. **PR Preparation & Initial Assessment**:
* **You will check out the designated PR {{args}}** into a temporary branch.
* **Execute the preflight checks (`npm run preflight`)**. This includes building, linting, and running all unit tests.
* Analyze the output of these preflight checks, noting any failures, warnings, or linting issues.
2. **In-Depth Code Review**:
* **Your primary role is to conduct a thorough and in-depth code review** of the changes introduced in the PR. Focus your analysis on the following criteria:
* **Correctness**: Does the code achieve its stated purpose without bugs or logical errors?
* **Maintainability**: Is the code clean, well-structured, and easy to understand and modify in the future? Consider factors like code clarity, modularity, and adherence to established design patterns.
* **Readability**: Is the code well-commented (where necessary) and consistently formatted according to our project's coding style guidelines?
* **Efficiency**: Are there any obvious performance bottlenecks or resource inefficiencies introduced by the changes?
* **Security**: Are there any potential security vulnerabilities or insecure coding practices?
* **Edge Cases and Error Handling**: Does the code appropriately handle edge cases and potential errors?
* **Testability**: Is the new or modified code adequately covered by tests (even if preflight checks pass)? Suggest additional test cases that would improve coverage or robustness.
* Based on your analysis, you will determine if the PR is **safe to merge**.
3. **Reviewing Previous Feedback**:
* **Access and examine the PR's history** to identify any **outstanding requests or unresolved comments from previous reviews**. Incorporate these into your current review and explicitly highlight if they have been adequately addressed in the current state of the PR.
4. **Decision and Output Generation**:
* **If the PR is deemed safe to merge** (after your comprehensive review and considering previous feedback):
* Draft a **friendly, concise, and professional approval message**.
* **The approval message should:**
* Clearly state that the PR is approved.
* Briefly acknowledge the quality or value of the contribution (e.g., "GreatworkonXfeature!" or "AppreciatethefixforYissue!").
* **Do NOT mention the preflight checks or unit testing**, as these are internal processes.
* Be suitable for public display on GitHub.
* **If the PR is NOT safe to merge**:
* Provide a **clear, constructive, and detailed summary of the issues found**.
* Suggest **specific actionable changes** required for the PR to become merge-ready.
* Ensure the feedback is professional and encourages the contributor.
### Post-PR Action:
* After providing your review and decision for the current PR, I will wait for you to perform any manual testing you wish to do. Please let me know when you are finished.
* Once you have confirmed that you are done, I will switch to the `main` branch, clean up the local branch, and perform a pull to ensure we are synchronized with the latest upstream changes for the next review.
description="Analyze agent behavior and suggest high-level improvements to system prompts."
prompt="""
# Prompt Engineering Analysis
You are a world-class prompt engineer and an expert AI engineer at the top of your class. Your goal is to analyze a specific agent behavior or failure and suggest high-level improvements to the system instructions.
**Observed Behavior / Issue:**
{{args}}
**Reference Context:**
- System Prompt Logic: @packages/core/src/core/prompts.ts
### Task
1. **Analyze the Failure:** Review the provided behavior and identify the underlying instructional causes. Use the `/introspect` command output if provided by the user.
2. **Strategic Insights:** Share your technical view of the issue. Focus on the "why" and identify any instructional inertia or ambiguity.
3. **Propose Improvements:** Suggest high-level changes to the system instructions to prevent this behavior.
### Principles
- **Avoid Hyper-scoping:** Do not create narrow solutions for specific scenarios; aim for generalized improvements that handle classes of behavior.
- **Avoid Specific Examples in Suggestions:** Keep the proposed instructions semantic and high-level to prevent the agent from over-indexing on specific cases.
- **Maintain Operational Rigor:** Ensure suggestions do not compromise safety, security, or the quality of the agent's work.
description="Reviews a PR or staged changes and automatically initiates a Pickle Fix loop for findings."
prompt="""
You are an expert Reviewer and Pickle Rick Worker.
Target: {{args}}
Phase 1: Review
Follow these steps to conduct a thorough review:
1. **Gather Context**:
* If `{{args}}` is 'staged' or `{{args}}` is empty:
* Use `git diff --staged` to view the changes.
* Use `git status` to see the state of the repository.
* Otherwise:
* Use `gh pr view {{args}}` to pull the information of the PR.
* Use `gh pr diff {{args}}` to view the diff of the PR.
2. **Understand Intent**:
* If `{{args}}` is 'staged' or `{{args}}` is empty, infer the intent from the changes and the current task.
* Otherwise, use the PR description. If it's not detailed enough, note it in your review.
3. **Check Commit Style**:
* Ensure the PR title (or intended commit message) follows Conventional Commits. Examples of recent commits: !{git log --pretty=format:"%s" -n 5}
4. Search the codebase if required.
5. Write a concise review of the changes, keeping in mind to encourage strong code quality and best practices. Pay particular attention to the Gemini MD file in the repo.
6. Consider ways the code may not be consistent with existing code in the repo. In particular it is critical that the react code uses patterns consistent with existing code in the repo.
3. `npm run build` (Ensure the project still builds)
4. `npm run test` (Ensure no regressions)
5. `npm run lint` (Ensure code style is maintained)
6. `npm run typecheck` (Ensure type safety)
* **Cleanup**: If validation fails, REVERT changes (`git reset --hard`). If it passes, COMMIT changes.
* **Next Ticket**: Pick the next ticket and repeat.
4. **Cleanup**:
* **Action**: After all tickets are completed delete `review_findings.md`.
**Loop Constraints:**
- **Iteration Count**: Monitor `"iteration"` in `state.json`. If `"max_iterations"` (if > 0) is reached, you must stop.
- **Completion Promise**: If a `"completion_promise"` is defined in `state.json`, you must output `<promise>PROMISE_TEXT</promise>` when the task is genuinely complete.
- **Stop Hook**: A hook is active. If you try to exit before completion, you will be forced to continue.
description: Trigger this skill when the user wants to start an asynchronous PR review, run background checks on a PR, or check the status of a previously started async PR review.
---
# Async PR Review
This skill provides a set of tools to asynchronously review a Pull Request. It will create a background job to run the project's preflight checks, execute Gemini-powered test plans, and perform a comprehensive code review using custom prompts.
This skill is designed to showcase an advanced "Agentic Asynchronous Pattern":
1.**Native Background Shells vs Headless Inference**: While Gemini CLI can natively spawn and detach background shell commands (using the `run_shell_command` tool with `is_background: true`), a standard bash background job cannot perform LLM inference. To conduct AI-driven code reviews and test generation in the background, the shell script *must* invoke the `gemini` executable headlessly using `-p`. This offloads the AI tasks to independent worker agents.
2.**Dynamic Git Scoping**: The review scripts avoid hardcoded paths. They use `git rev-parse --show-toplevel` to automatically resolve the root of the user's current project.
3.**Ephemeral Worktrees**: Instead of checking out branches in the user's main workspace, the skill provisions temporary git worktrees in `.gemini/tmp/async-reviews/pr-<number>`. This prevents git lock conflicts and namespace pollution.
4.**Agentic Evaluation (`check-async-review.sh`)**: The check script outputs clean JSON/text statuses for the main agent to parse. The interactive agent itself synthesizes the final assessment dynamically from the generated log files.
## Workflow
1.**Determine Action**: Establish whether the user wants to start a new async review or check the status of an existing one.
* If the user says "start an async review for PR #123" or similar, proceed to **Start Review**.
* If the user says "check the status of my async review for PR #123" or similar, proceed to **Check Status**.
### Start Review
If the user wants to start a new async PR review:
1. Ask the user for the PR number if they haven't provided it.
2. Execute the `async-review.sh` script, passing the PR number as the first argument. Be sure to run it with the `is_background` flag set to true to ensure it immediately detaches.
3. **Evaluate Output**: Read the output from the script.
* If the output contains `STATUS: IN_PROGRESS`, tell the user which tasks are still running.
* If the output contains `STATUS: COMPLETE`, use your file reading tools (`read_file`) to retrieve the contents of `final-assessment.md`, `review.md`, `pr-diff.diff`, `npm-test.log`, and `test-execution.log` files from the `LOG_DIR` specified in the output.
***Final Assessment**: Read those files, synthesize their results, and give the user a concise recommendation on whether the PR builds successfully, passes tests, and if you recommend they approve it based on the review.
{{ npm run clean && npm ci && npm run format && npm run build && npm run lint:ci && npm run typecheck;} > "${log_dir}/build-and-lint.log" 2>&1;echo$? > "${log_dir}/build-and-lint.exit";}&
# Dynamically resolve gemini binary (fallback to your nightly path)
echo"CI checks passed. Skipping local npm tests." > "${log_dir}/npm-test.log"
echo0 > "${log_dir}/npm-test.exit"
elif[["${ci_status}" -eq 8]];then
echo"CI checks are still pending. Skipping local npm tests to avoid duplicate work. Please check GitHub for final results." > "${log_dir}/npm-test.log"
echo"Found failing test files from CI:" >> "${log_dir}/npm-test.log"
for f in ${failed_files};doecho" - ${f}" >> "${log_dir}/npm-test.log";done
echo"Running ONLY failing tests locally..." >> "${log_dir}/npm-test.log"
exit_code=0
for file in ${failed_files};do
if[["${file}"== packages/* ]];then
ws_dir="$(echo"${file}"| cut -d'/' -f1,2)"
else
ws_dir="$(echo"${file}"| cut -d'/' -f1)"
fi
rel_file="${file#"${ws_dir}"/}"
echo"--- Running ${rel_file} in workspace ${ws_dir} ---" >> "${log_dir}/npm-test.log"
if ! npm run test:ci -w "${ws_dir}" -- "${rel_file}" >> "${log_dir}/npm-test.log" 2>&1;then
exit_code=1
fi
done
echo"${exit_code}" > "${log_dir}/npm-test.exit"
else
echo"Could not extract specific failing files. Skipping full local test suite as it takes too long. Please check CI logs manually." >> "${log_dir}/npm-test.log"
echo1 > "${log_dir}/npm-test.exit"
fi
fi
else
echo"Skipped due to build-and-lint failure" > "${log_dir}/npm-test.log"
echo1 > "${log_dir}/npm-test.exit"
fi
}&
echo" ↳ [5/5] Starting Gemini test execution (waiting for build and lint)..."
"${GEMINI_CMD}" --policy "${POLICY_PATH}" -p "Analyze the diff for PR ${pr_number} using 'gh pr diff ${pr_number}'. Instead of running the project's automated test suite (like 'npm test'), physically exercise the newly changed code in the terminal (e.g., by writing a temporary script to call the new functions, or testing the CLI command directly). Verify the feature's behavior works as expected. IMPORTANT: Do NOT modify any source code to fix errors. Just exercise the code and log the results, reporting any failures clearly. Do not ask for user confirmation." > "${log_dir}/test-execution.log" 2>&1;echo$? > "${log_dir}/test-execution.exit"
else
echo"Skipped due to build-and-lint failure" > "${log_dir}/test-execution.log"
echo1 > "${log_dir}/test-execution.exit"
fi
}&
echo"✅ All tasks dispatched!"
echo"You can monitor progress with: tail -f ${log_dir}/*.log"
echo"Read your review later at: ${log_dir}/review.md"
# Polling loop to wait for all background tasks to finish
echo"⏳ Tasks complete! Synthesizing final assessment..."
if ! "${GEMINI_CMD}" --policy "${POLICY_PATH}" -p "Read the review at ${log_dir}/review.md, the automated test logs at ${log_dir}/npm-test.log, and the manual test execution logs at ${log_dir}/test-execution.log. Summarize the results, state whether the build and tests passed based on ${log_dir}/build-and-lint.exit and ${log_dir}/npm-test.exit, and give a final recommendation for PR ${pr_number}." > "${log_dir}/final-assessment.md" 2>&1;then
echo$? > "${log_dir}/final-assessment.exit"
echo"❌ Final assessment synthesis failed!"
echo"Check ${log_dir}/final-assessment.md for details."
description: Guidance for creating, running, fixing, and promoting behavioral evaluations. Use when verifying agent decision logic, debugging failures, debugging prompt steering, or adding workspace regression tests.
---
# Behavioral Evals
## Overview
Behavioral evaluations (evals) are tests that validate the **agent's decision-making** (e.g., tool choice) rather than pure functionality. They are critical for verifying prompt changes, debugging steerability, and preventing regressions.
> [!NOTE]
> **Single Source of Truth**: For core concepts, policies, running tests, and general best practices, always refer to **[evals/README.md](file:///Users/abhipatel/code/gemini-cli/docs/evals/README.md)**.
---
## 🔄 Workflow Decision Tree
1.**Does a prompt/tool change need validation?**
**No* -> Normal integration tests.
**Yes* -> Continue below.
2.**Is it UI/Interaction heavy?**
**Yes* -> Use `appEvalTest` (`AppRig`). See **[creating.md](references/creating.md)**.
**No* -> Use `evalTest` (`TestRig`). See **[creating.md](references/creating.md)**.
3.**Is it a new test?**
**Yes* -> Set policy to `USUALLY_PASSES`.
**No* -> `ALWAYS_PASSES` (locks in regression).
4.**Are you fixing a failure or promoting a test?**
**Fixing* -> See **[fixing.md](references/fixing.md)**.
**Promoting* -> See **[promoting.md](references/promoting.md)**.
---
## 📋 Quick Checklist
### 1. Setup Workspace
Seed the workspace with necessary files using the `files` object to simulate a realistic scenario (e.g., NodeJS project with `package.json`).
**Details in **[creating.md](references/creating.md)***
### 2. Write Assertions
Audit agent decisions using `rig.setBreakpoint()` (AppRig only) or index verification on `rig.readToolLogs()`.
**Details in **[creating.md](references/creating.md)***
### 3. Verify
Run single tests locally with Vitest. Confirm stability locally before relying on CI workflows.
**See **[evals/README.md](file:///Users/abhipatel/code/gemini-cli/docs/evals/README.md)** for running commands.*
| **`evalTest`** | `./test-helper.js` | **Subprocess**. Runs the CLI in a separate process + waits for exit. | Standard workspace tests. **Do not use `setBreakpoint`**; auditing history (`readToolLogs`) is safer. |
| **`appEvalTest`** | `./app-test-helper.js` | **In-Process**. Runs directly inside the runner loop. | UI/Ink rendering. Safe for `setBreakpoint` triggers. |
---
## 🏗️ Scenario Design
Evals must simulate realistic agent environments to effectively test
decision-making.
- **Workspace State**: Seed with standard project anchors if testing general
Use this skill to review code. It supports both local changes (staged or working tree)
and remote Pull Requests (by ID or URL). It focuses on correctness, maintainability,
and adherence to project standards.
---
# Code Reviewer
This skill guides the agent in conducting professional and thorough code reviews for both local development and remote Pull Requests.
## Workflow
### 1. Determine Review Target
***Remote PR**: If the user provides a PR number or URL (e.g., "Review PR #123"), target that remote PR.
***Local Changes**: If no specific PR is mentioned, or if the user asks to "review my changes", target the current local file system states (staged and unstaged changes).
### 2. Preparation
#### For Remote PRs:
1.**Checkout**: Use the GitHub CLI to checkout the PR.
```bash
gh pr checkout <PR_NUMBER>
```
2. **Preflight**: Execute the project's standard verification suite to catch automated failures early.
```bash
npm run preflight
```
3. **Context**: Read the PR description and any existing comments to understand the goal and history.
2. **Preflight (Optional)**: If the changes are substantial, ask the user if they want to run `npm run preflight` before reviewing.
### 3. In-Depth Analysis
Analyze the code changes based on the following pillars:
* **Correctness**: Does the code achieve its stated purpose without bugs or logical errors?
* **Maintainability**: Is the code clean, well-structured, and easy to understand and modify in the future? Consider factors like code clarity, modularity, and adherence to established design patterns.
* **Readability**: Is the code well-commented (where necessary) and consistently formatted according to our project's coding style guidelines?
* **Efficiency**: Are there any obvious performance bottlenecks or resource inefficiencies introduced by the changes?
* **Security**: Are there any potential security vulnerabilities or insecure coding practices?
* **Edge Cases and Error Handling**: Does the code appropriately handle edge cases and potential errors?
* **Testability**: Is the new or modified code adequately covered by tests (even if preflight checks pass)? Suggest additional test cases that would improve coverage or robustness.
### 4. Provide Feedback
#### Structure
* **Summary**: A high-level overview of the review.
* **Findings**:
* **Critical**: Bugs, security issues, or breaking changes.
* **Improvements**: Suggestions for better code quality or performance.
* **Nitpicks**: Formatting or minor style issues (optional).
description: Use this skill if the user asks you to help them address GitHub PR comments for their current branch of the Gemini CLI. Requires `gh` CLI tool.
---
You are helping the user address comments on their Pull Request. These comments may have come from an automated review agent or a team member.
OBJECTIVE: Help the user review and address comments on their PR.
# Comment Review Procedure
1. Run the `scripts/fetch-pr-info.js` script to get PR info and state. MAKE SURE you read the entire output of the command, even if it gets truncated.
2. Summarize the review status by analyzing the diff, commit log, and comments to see which still need to be addressed. Pay attention to the current user's comments. For resolved threads, summarize as a single line with a ✅. For open threads, provide a reference number e.g. [1] and the comment content.
3. Present your summary of the feedback and current state and allow the user to guide you as to what to fix/address/skip. DO NOT begin fixing issues automatically.
description: Use this skill during code reviews to proactively investigate the codebase for duplicated functionality, reinvented wheels, or failure to reuse existing project best practices and shared utilities.
---
# Review Duplication
## Overview
This skill provides a structured workflow for investigating a codebase during a code review to identify duplicated logic, reinvented utilities, and missed opportunities to reuse established patterns. By executing this workflow, you ensure that new code integrates seamlessly with the existing project architecture.
## Workflow: Investigating for Duplication
When reviewing code, perform the following steps before finalizing your review:
### 1. Extract Core Logic
Analyze the new code to identify the core algorithms, utility functions, generic data structures, or UI components being introduced. Look beyond the specific business logic to see the underlying mechanics.
- **Core Logic:** Call out `packages/core/` if functionality does not appear React UI specific.
**Trace Third-Party Dependencies:** If the PR introduces a new import for a utility library (e.g., `lodash.merge`, `date-fns`), trace how and where the project currently uses that library. There is likely an existing wrapper or shared utility.
**Check Package Files:** Before flagging a custom implementation of a complex algorithm, check `package.json` to see if a standard library (like `lodash` or `uuid`) is already installed that provides this functionality.
### 3. Investigate the Codebase (Sub-Agent Delegation)
Delegate the heavy lifting of codebase investigation to specialized sub-agents. They are optimized to perform deep searches and semantic mapping without bloating your session history.
To ensure a comprehensive review, you MUST formulate highly specific objectives for the sub-agents, providing them with the "scents" you discovered in Step 1.
- **Codebase Investigator:** Use the `codebase_investigator` as your primary researcher. When delegating, formulate an objective that asks specific, investigative questions about the codebase, explicitly including these search vectors:
- **Structural Similarity:** Ask if existing code uses the same underlying APIs (e.g., "Does any existing code use `Intl.DateTimeFormat` or `setTimeout` for similar purposes?").
- **Naming Conventions:** Ask if there are existing symbols with similar naming patterns (e.g., "Are there existing symbols with naming patterns like `*Format*` or `*Debounce*`?").
- **Comments & Documentation:** Ask if keywords from the PR's comments or JSDoc exist in describing similar behavior elsewhere.
- **Architectural Fit:** Ask where this type of logic is currently centralized (e.g., "Where is centralized date formatting logic located?").
- **Refactoring Guidance:** Crucially, ask the sub-agent to explain *how* the new code could be refactored to use any existing logic it finds.
- **Generalist Agent:** Use the `generalist` for detailed, turn-intensive comparisons. For example: "Review the implementation of `MyNewComponent` in the PR and compare it semantically against all components in `packages/ui/src`. Are there any existing components that could be extended or used instead?"
- **Retain Fast Path for Simple Searches:** For extremely simple, unambiguous checks (e.g., "Does `package.json` include `lodash`?"), perform a direct search to save time. Default to delegation for any open-ended "investigations."
### 4. Evaluate Best Practices
Check if the new code aligns with the project's established conventions.
- **Error Handling:** Does it use the project's standard error classes or logging mechanisms?
- **State Management:** Does it bypass established stores or contexts?
- **Styling:** Does it hardcode colors or spacing instead of using theme variables?
If the PR introduces a new pattern, compare it against the documented standards and explicitly confirm if an existing project pattern should have been used instead.
### 5. Formulate Constructive Feedback
If you discover that the PR duplicates existing functionality or ignores a best practice:
- Provide a clear review comment.
- **Identify the Source:** Explicitly mention the absolute or project-relative file path and the specific symbol (function, component, class) that should be reused.
- **Implementation Guidance:** Provide a brief code snippet or a clear explanation showing **how** to integrate the existing code to fulfill the task's requirements.
- **Explain the Value:** Briefly explain why reusing the existing code is beneficial (e.g., maintainability, consistency, built-in edge case handling).
Example comment:
> "It looks like this PR introduces a new `formatDate` utility. We already have a robust, tested `formatDate` function in `src/utils/dateHelpers.ts`.
>
> You can replace your implementation by importing it like this:
> ```typescript
> import { formatDate } from '../utils/dateHelpers';
description:'Report a bug to help us improve Gemini CLI'
labels:
- 'kind/bug'
- 'status/need-triage'
body:
- type:'markdown'
attributes:
@@ -28,7 +31,7 @@ body:
id:'info'
attributes:
label:'Client information'
description:'Please paste the full text from the `/about` command run from Gemini CLI. Also include which platform (macOS, Windows, Linux). Note that this output contains your email address. Consider removing it before submitting.'
description:'Please paste the full text from the `/about` command run from Gemini CLI. Also include which platform (macOS, Windows, Linux).'
description:'Report an issue with the Gemini CLI Website and Gemini CLI Extensions Gallery'
title: 'GeminiCLI.com Feedback:[ISSUE]'
labels:
- 'area/extensions'
- 'area/documentation'
body:
- type:'markdown'
attributes:
value:|-
> [!IMPORTANT]
> Thanks for taking the time to report an issue with the Gemini CLI Website
>
> Please search **[existing issues](https://github.com/google-gemini/gemini-cli/issues?q=is%3Aissue+is%3Aopen+label%3Aarea%2Fwebsite)** to see if a similar feature has already been requested.
- type:'input'
id:'url'
attributes:
label:'URL of the page with the issue'
description:'Please provide the URL where the issue occurs.'
validations:
required:true
- type:'textarea'
id:'problem'
attributes:
label:'What is the problem?'
description:'A clear and concise description of what the bug or issue is.'
validations:
required:true
- type:'textarea'
id:'expected'
attributes:
label:'What did you expect to happen?'
validations:
required:true
- type:'textarea'
id:'additional-context'
attributes:
label:'Additional context'
description:'Add any other context or screenshots about the issue here.'
echo "Dry run: Would have added tag '${INPUTS_CHANNEL}' to version '${INPUTS_VERSION}' for ${INPUTS_CLI_PACKAGE_NAME}, ${INPUTS_CORE_PACKAGE_NAME}, and ${INPUTS_A2A_PACKAGE_NAME}."
<!-- Concisely describe what this PR changes and why. Focus on impact and
urgency. -->
<!-- Add a brief description of what this pull request changes and why and any important things for reviewers to look at -->
## Details
## Dive Deeper
<!-- Add any extra context and design decisions. Keep it brief but complete. -->
<!-- more thoughts and in-depth discussion here -->
## Related Issues
## Reviewer Test Plan
<!-- Use keywords to auto-close issues (Closes #123, Fixes #456). If this PR is
only related to an issue or is a partial fix, simply reference the issue number
without a keyword (Related to #123). -->
<!-- when a person reviews your code they should ideally be pulling and running that code. How would they validate your change works and if relevant what are some good classes of example prompts and ways they can exercise your changes -->
## How to Validate
## Testing Matrix
<!-- List exact steps for reviewers to validate the change. Include commands,
expected results, and edge cases. -->
<!-- Before submitting please validate your changes on as many of these options as possible -->
## Pre-Merge Checklist
| | 🍏 | 🪟 | 🐧 |
| -------- | --- | --- | --- |
| npm run | ❓ | ❓ | ❓ |
| npx | ❓ | ❓ | ❓ |
| Docker | ❓ | ❓ | ❓ |
| Podman | ❓ | - | - |
| Seatbelt | ❓ | - | - |
<!-- Check all that apply before requesting review or merging. -->
## Linked issues / bugs
- [ ] Updated relevant documentation and README (if needed)
- [ ] Added/updated tests (if needed)
- [ ] Noted breaking changes (if any)
- [ ] Validated on required platforms/methods:
- [ ] MacOS
- [ ] npm run
- [ ] npx
- [ ] Docker
- [ ] Podman
- [ ] Seatbelt
- [ ] Windows
- [ ] npm run
- [ ] npx
- [ ] Docker
- [ ] Linux
- [ ] npm run
- [ ] npx
- [ ] Docker
<!--
Link to any related issues or bugs.
**If this PR fully resolves the issue, use one of the following keywords to automatically close the issue when this PR is merged:**
- Closes #<issue_number>
- Fixes #<issue_number>
- Resolves #<issue_number>
*Example: `Resolves #123`*
**If this PR is only related to an issue or is a partial fix, simply reference the issue number without a keyword:**
*Example: `This PR makes progress on #456` or `Related to #789`*
console.error('❌ GitHub CLI (gh) is not authenticated.');
process.exit(1);
}
if(isDryRun){
console.log('🧪 DRY RUN MODE ENABLED\n');
}
console.log(`📥 Fetching open PRs from ${REPO}...`);
// Fetch number, author, and closingIssuesReferences to check if linked to an issue
constprsJson=runGh([
'pr',
'list',
'--repo',
REPO,
'--state',
'open',
'--limit',
'1000',
'--json',
'number,author,closingIssuesReferences',
]);
if(prsJson===null)process.exit(1);
constprs=JSON.parse(prsJson);
console.log(`📊 Found ${prs.length} open PRs. Filtering...`);
lettargetPrs=[];
for(constprofprs){
constauthor=pr.author.login;
constissueCount=pr.closingIssuesReferences
?pr.closingIssuesReferences.length
:0;
if(issueCount>0){
// Skip if already linked to an issue
continue;
}
if(!isMaintainer(author)){
targetPrs.push(pr);
}
}
console.log(
`✅ Found ${targetPrs.length} PRs from non-maintainers without associated issues.`,
);
constcommentBody=
"\nHi @{AUTHOR}, thank you so much for your contribution to Gemini CLI! We really appreciate the time and effort you've put into this.\n\nWe're making some updates to our contribution process to improve how we track and review changes. Please take a moment to review our recent discussion post: [Improving Our Contribution Process & Introducing New Guidelines](${DISCUSSION_URL}).\n\nKey Update: Starting **January 26, 2026**, the Gemini CLI project will require all pull requests to be associated with an existing issue. Any pull requests not linked to an issue by that date will be automatically closed.\n\nThank you for your understanding and for being a part of our community!\n ".trim();
letsuccessCount=0;
letskipCount=0;
letfailCount=0;
for(constproftargetPrs){
constprNumber=String(pr.number);
constauthor=pr.author.login;
// Check if we already commented (idempotency)
// We use silent: true here because view might fail if PR is deleted mid-run
This PR contains the auto-generated documentation audit for the week. It includes a new `audit-results-*.md` file with findings and any direct fixes applied by the agent.
if [[ "${{ needs.detect-changes.outputs.STEERING_DETECTED }}" == "true" ]]; then
echo "### 🧠 Model Steering Guidance"
echo ""
echo "This PR modifies files that affect the model's behavior (prompts, tools, or instructions)."
echo ""
if [[ "${{ steps.analysis.outputs.MISSING_EVALS }}" == "true" ]]; then
echo "- ⚠️ **Consider adding Evals:** No behavioral evaluations (\`evals/*.eval.ts\`) were added or updated in this PR. Consider [adding a test case](https://github.com/google-gemini/gemini-cli/blob/main/evals/README.md#creating-an-evaluation) to verify the new behavior and prevent regressions."
fi
if [[ "${{ steps.analysis.outputs.IS_MAINTAINER }}" == "true" ]]; then
echo "- 🚀 **Maintainer Reminder:** Please ensure that these changes do not regress results on benchmark evals before merging."
fi
fi
echo ""
echo "---"
echo "*This is an automated guidance message triggered by steering logic signatures.*"
echo "<!-- eval-pr-report -->"
} > full_comment.md
# 2. Find if a comment with our unique tag already exists
# We extract the numeric ID from the URL to ensure compatibility with the REST API
You are an issue triage assistant. Your role is to analyze a GitHub issue and determine the single most appropriate area/ label based on the definitions provided.
You are an issue triage assistant. Analyze the current GitHub issue
and identify the most appropriate existing labels by only using the provided data. Use the available
tools to gather information; do not ask for information to be
provided. Do not remove the following labels titled maintainer, help wanted or good first issue.
## Steps
1. Review the issue title and body: ${{ env.ISSUE_TITLE }} and ${{ env.ISSUE_BODY }}.
2. Review the available labels: ${{ env.AVAILABLE_LABELS }}.
3. Select exactly one area/ label that best matches the issue based on Reference 1: Area Definitions.
4. Fallback Logic:
- If you cannot confidently determine the correct area/ label from the definitions, you must use area/unknown.
5. Output your selected label in JSON format and nothing else. Example:
{"labels_to_set": ["area/core"]}
1. You are only able to use the echo command. Review the available labels in the environment variable: "${AVAILABLE_LABELS}".
2. Review the issue title and body provided in the environment variables: "${ISSUE_TITLE}" and "${ISSUE_BODY}".
3. Select the most relevant labels from the existing labels, focusing on kind/*, area/*, sub-area/* and priority/*. For area/* and kind/* limit yourself to only the single most applicable label in each case.
4. If the issue already has area/ label, dont try to change it. Similarly, if the issue already has a kind/ label don't change it. And if the issue already has a priority/ label do not change it for example:
If an issue has area/core and kind/bug you will only add a priority/ label.
Instead if an issue has no labels, you will could add one lable of each kind.
5. For each issue please check if CLI version is present, this is usually in the output of the /about command and will look like 0.1.5 for anything more than 6 versions older than the most recent should add the status/need-retesting label.
6. If you see that the issue doesn't look like it has sufficient information recommend the status/need-information label and leave a comment politely requesting the relevant information, eg.. if repro steps are missing request for repro steps. if version information is missing request for version information into the explanation section below.
7. Output the appropriate labels for this issue in JSON format with explanation, for example:
```
{"labels_to_set": ["kind/bug", "priority/p0"], "explanation": "This is a critical bug report affecting main functionality"}
```
8. If the issue cannot be classified using the available labels, output:
```
{"labels_to_set": [], "explanation": "Unable to classify this issue with available labels"}
```
9. Use Area definitions mentioned below to help you narrow down issues.
10. If you think an issue might be a Priority/P0 do not apply the priority/p0 label. Instead apply a status/manual-triage label and include a note in your explanation.
11. If you are uncertain and have not been able to apply one each of kind/, area/ and priority/ , apply the status/manual-triage label.
## Guidelines
- Your output must contain exactly one area/ label.
- Triage only the current issue based on its title and body.
- Output only valid JSON format.
- Do not include any explanation or additional text, just the JSON.
Reference 1: Area Definitions
area/agent
- Description: Issues related to the "brain" of the CLI. This includes the core agent logic, model quality, tool/function calling, and memory.
- Example Issues:
"I am not getting a reasonable or expected response."
"The model is not calling the tool I expected."
"The web search tool is not working as expected."
"Feature request for a new built-in tool (e.g., read file, write file)."
"The generated code is poor quality or incorrect."
"The model seems stuck in a loop."
"The response from the model is malformed (e.g., broken JSON, bad formatting)."
"Concerns about unnecessary token consumption."
"Issues with how memory or chat history is managed."
"Issues with sub-agents."
"Model is switching from one to another unexpectedly."
- Only use labels that already exist in the repository
- Do not add comments or modify the issue content
- Triage only the current issue
- Identify only one area/ label
- Identify only one kind/ label
- Identify all applicable sub-area/* and priority/* labels based on the issue content. It's ok to have multiple of these
- Once you categorize the issue if it needs information bump down the priority by 1 eg.. a p0 would become a p1 a p1 would become a p2. P2 and P3 can stay as is in this scenario
- Reference all shell variables as "${VAR}" (with quotes and braces)
- Output only valid JSON format
- Do not include any explanation or additional text, just the JSON
area/enterprise
- Description: Issues specific to enterprise-level features, including telemetry, policy, and licenses.
- Example Issues:
"Usage data is not appearing in our telemetry dashboard."
"A user is able to perform an action that should be blocked by an admin policy."
"Questions about billing, licensing tiers, or enterprise quotas."
area/non-interactive
- Description: Issues related to using the CLI in automated or non-interactive environments (headless mode).
- Example Issues:
"Problems using the CLI as an SDK in another surface."
"The CLI is behaving differently when run from a shell script vs. an interactive terminal."
"GitHub action is failing."
"I am having trouble running the CLI in headless mode"
area/core
- Description: Issues with the fundamental CLI app itself. This includes the user interface (UI/UX), installation, OS compatibility, and performance.
- Example Issues:
"I am seeing my screen flicker when using the CLI."
"The output in my terminal is malformed or unreadable."
"Theme changes are not taking effect."
"Keyboard inputs (e.g., arrow keys, Ctrl+C) are not being recognized."
"The CLI failed to install or update."
"An issue specific to running on Windows, macOS, or Linux."
"Problems with command parsing, flags, or argument handling."
"High CPU or memory usage by the CLI process."
"Issues related to multi-modality (e.g., handling image inputs)."
"Problems with the IDE integration connection or installation"
area/security
- Description: Issues related to user authentication, authorization, data security, and privacy.
- Example Issues:
"I am unable to sign in."
"The login flow is selecting the wrong authentication path"
"Problems with API key handling or credential storage."
"A report of a security vulnerability"
"Concerns about data sanitization or potential data leaks."
"Issues or requests related to privacy controls."
"Preventing unauthorized data access."
area/platform
- Description: Issues related to CI/CD, release management, testing, eval infrastructure, capacity, quota management, and sandbox environments.
- Example Issues:
"I am getting a 429 'Resource Exhausted' or 500-level server error."
"General slowness or high latency from the service."
"The build script is broken on the main branch."
"Tests are failing in the CI/CD pipeline."
"Issues with the release management or publishing process."
"User is running out of capacity."
"Problems specific to the sandbox or staging environments."
"Questions about quota limits or requests for increases."
area/extensions
- Description: Issues related to the extension ecosystem, including the marketplace and website.
- Example Issues:
"Bugs related to the extension marketplace website."
"Issues with a specific extension."
"Feature request for the extension ecosystem."
area/documentation
- Description: Issues related to user-facing documentation and other content on the documentation website.
- Example Issues:
"A typo in a README file."
"DOCS: A command is not working as described in the documentation."
"A request for a new documentation page."
"Instructions missing for skills feature"
area/unknown
- Description: Issues that do not clearly fit into any other defined area/ category, or where information is too limited to make a determination. Use this when no other area is appropriate.
Categorization Guidelines:
P0: Critical / Blocker
- A P0 bug is a catastrophic failure that demands immediate attention.
- To be a P0 it means almost all users are running into this issue and it is blocking users from being able to use the product.
- You would see this in the form of many comments from different developers on the bug.
- It represents a complete showstopper for a significant portion of users or for the development process itself.
Impact:
- Blocks development or testing for the entire team.
- Major security vulnerability that could compromise user data or system integrity.
- Causes data loss or corruption with no workaround.
- Crashes the application or makes a core feature completely unusable for all or most users in a production environment. Will it cause severe quality degration? Is it preventing contributors from contributing to the repository or is it a release blocker?
Qualifier: Is the main function of the software broken?
Example: The gemini auth login command fails with an unrecoverable error, preventing any user from authenticating and using the rest of the CLI.
P1: High
- A P1 bug is a serious issue that significantly degrades the user experience or impacts a core feature.
- While not a complete blocker, it's a major problem that needs a fast resolution. Feature requests are almost never P1.
- Once again this would be affecting many users.
- You would see this in the form of comments from different developers on the bug.
Impact:
- A core feature is broken or behaving incorrectly for a large number of users or large number of use cases.
- Review the bug details and comments to try figure out if this issue affects a large set of use cases or if it's a narrow set of use cases.
- Severe performance degradation making the application frustratingly slow.
- No straightforward workaround exists, or the workaround is difficult and non-obvious.
Qualifier: Is a key feature unusable or giving very wrong results?
Example: Gemini CLI enters a loop when making read-many-files tool call. I am unable to break out of the loop and gemini doesn't follow instructions subsequently.
P2: Medium
- A P2 bug is a moderately impactful issue. It's a noticeable problem but doesn't prevent the use of the software's main functionality.
Impact:
- Affects a non-critical feature or a smaller, specific subset of users.
- An inconvenient but functional workaround is available and easy to execute.
- Noticeable UI/UX problems that don't break functionality but look unprofessional (e.g., elements are misaligned or overlapping).
Qualifier: Is it an annoying but non-blocking problem?
Example: An error message is unclear or contains a typo, causing user confusion but not halting their workflow.
P3: Low
- A P3 bug is a minor, low-impact issue that is trivial or cosmetic. It has little to no effect on the overall functionality of the application.
Impact:
- Minor cosmetic issues like color inconsistencies, typos in documentation, or slight alignment problems on a non-critical page.
- An edge-case bug that is very difficult to reproduce and affects a tiny fraction of users.
Qualifier: Is it a "nice-to-fix" issue?
Example: Spelling mistakes etc.
Things you should know:
- If users are talking about issues where the model gets downgraded from pro to flash then i want you to categorize that as a performance issue
- This product is designed to use different models eg.. using pro, downgrading to flash etc. when users report that they dont expect the model to change those would be categorized as feature requests.
Definition of Areas
area/ux:
- Issues concerning user-facing elements like command usability, interactive features, help docs, and perceived performance.
- I am seeing my screen flicker when using Gemini CLI
- I am seeing the output malformed
- Theme changes aren't taking effect
- My keyboard inputs arent' being recognzied
area/platform:
- Issues related to installation, packaging, OS compatibility (Windows, macOS, Linux), and the underlying CLI framework.
area/background: Issues related to long-running background tasks, daemons, and autonomous or proactive agent features.
area/models:
- i am not getting a response that is reasonable or expected. this can include things like
- I am calling a tool and the tool is not performing as expected.
- i am expecting a tool to be called and it is not getting called ,
- Function calling issues should be under this area
- i am getting responses from the model that are malformed.
- Issues concerning Gemini quality of response and inference,
- Issues talking about unnecessary token consumption.
- Issues talking about Model getting stuck in a loop be watchful as this could be the root cause for issues that otherwise seem like model performance issues.
- Memory compression
- unexpected responses,
- poor quality of generated code
area/tools:
- These are primarily issues related to Model Context Protocol
- These are issues that mention MCP support
- feature requests asking for support for new tools.
area/core: Issues with fundamental components like command parsing, configuration management, session state, and the main API client logic. Introducing multi-modality
area/contribution: Issues related to improving the developer contribution experience, such as CI/CD pipelines, build scripts, and test automation infrastructure.
area/authentication: Issues related to user identity, login flows, API key handling, credential storage, and access token management, unable to sign in selecting wrong authentication path etc..
area/security-privacy: Issues concerning vulnerability patching, dependency security, data sanitization, privacy controls, and preventing unauthorized data access.
area/extensibility: Issues related to the plugin system, extension APIs, or making the CLI's functionality available in other applications, github actions, ide support etc..
area/performance: Issues focused on model performance
- Issues with running out of capacity,
- 429 errors etc..
- could also pertain to latency,
- other general software performance like, memory usage, CPU consumption, and algorithmic efficiency.
- Switching models from one to the other unexpectedly.
1. You are only able to use the echo command. Review the available labels in the environment variable: "${AVAILABLE_LABELS}".
2. Check environment variable for issues to triage: $ISSUES_TO_TRIAGE (JSON array of issues)
3. Review the issue title, body and any comments provided in the environment variables.
4. Identify the most relevant labels from the existing labels, specifically focusing on area/*, kind/* and priority/*.
5. Label Policy:
- If the issue already has a kind/ label, do not change it.
- If the issue already has a priority/ label, do not change it.
- If the issue already has an area/ label, do not change it.
- If any of these are missing, select exactly ONE appropriate label for the missing category.
4. Identify the most relevant labels from the existing labels, focusing on kind/*, area/*, sub-area/* and priority/*.
5. If the issue already has area/ label, dont try to change it. Similarly, if the issue already has a kind/ label don't change it. And if the issue already has a priority/ label do not change it for example:
If an issue has area/core and kind/bug you will only add a priority/ label.
Instead if an issue has no labels, you will could add one lable of each kind.
6. Identify other applicable labels based on the issue content, such as status/*, help wanted, good first issue, etc.
7. Give me a single short explanation about why you are selecting each label in the process.
8. Output a JSON array of objects, each containing the issue number
7. For area/* and kind/* limit yourself to only the single most applicable label in each case.
8. Give me a single short explanation about why you are selecting each label in the process.
9. Output a JSON array of objects, each containing the issue number
and the labels to add and remove, along with an explanation. For example:
"explanation": "This issue is a UI bug that needs to be addressed with medium priority."
"explanation": "This issue is a bug that needs to be addressed with medium priority."
},
{
"issue_number": 456,
"labels_to_add": ["kind/enhancement"],
"labels_to_remove": [],
"explanation": "This issue is an enhancement request that could improve the user experience."
}
]
```
If an issue cannot be classified, do not include it in the output array.
9. For each issue please check if CLI version is present, this is usually in the output of the /about command and will look like 0.1.5
10. For each issue please check if CLI version is present, this is usually in the output of the /about command and will look like 0.1.5
- Anything more than 6 versions older than the most recent should add the status/need-retesting label
10. If you see that the issue doesn't look like it has sufficient information recommend the status/need-information label and leave a comment politely requesting the relevant information, eg.. if repro steps are missing request for repro steps. if version information is missing request for version information into the explanation section below.
11. If you think an issue might be a Priority/P0 do not apply the priority/p0 label. Instead apply a status/manual-triage label and include a note in your explanation.
12. If you are uncertain about a category, use the area/unknown, kind/question, or priority/unknown labels as appropriate. If you are extremely uncertain, apply the status/manual-triage label.
11. If you see that the issue doesn't look like it has sufficient information recommend the status/need-information label and leave a comment politely requesting the relevant information, eg.. if repro steps are missing request for repro steps. if version information is missing request for version information into the explanation section below.
- After identifying appropriate labels to an issue, add "status/need-triage" label to labels_to_remove in the output.
12. If you think an issue might be a Priority/P0 do not apply the priority/p0 label. Instead apply a status/manual-triage label and include a note in your explanation.
13. If you are uncertain and have not been able to apply one each of kind/, area/ and priority/ , apply the status/manual-triage label.
## Guidelines
@@ -174,47 +157,100 @@ jobs:
- Do not add comments or modify the issue content.
- Do not remove the following labels maintainer, help wanted or good first issue.
- Triage only the current issue.
- Identify only one area/ label.
- Identify only one area/ label
- Identify only one kind/ label (Do not apply kind/duplicate or kind/parent-issue)
- Identify only one priority/ label.
- Identify all applicable sub-area/* and priority/* labels based on the issue content. It's ok to have multiple of these.
- Once you categorize the issue if it needs information bump down the priority by 1 eg.. a p0 would become a p1 a p1 would become a p2. P2 and P3 can stay as is in this scenario.
Categorization Guidelines (Priority):
P0 - Urgent Blocking Issues:
- DO NOT APPLY THIS LABEL AUTOMATICALLY. Use status/manual-triage instead.
- Definition: Urgent, block a significant percentage of the user base, and prevent frequent use of the Gemini CLI.
- This includes core stability blockers (e.g., authentication failures, broken upgrades), critical crashes, and P0 security vulnerabilities.
- Impact: Blocks development or testing for the entire team; Major security vulnerability; Causes data loss or corruption with no workaround; Crashes the application or makes a core feature completely unusable for all or most users.
- Qualifier: Is the main function of the software broken?
P1 - High-Impact Issues:
- Definition: Affect a large number of users, blocking them from using parts of the Gemini CLI, or make the CLI frequently unusable even with workarounds available.
- Impact: A core feature is broken or behaving incorrectly for a large number of users or use cases; Severe performance degradation; No straightforward workaround exists.
- Qualifier: Is a key feature unusable or giving very wrong results?
P2 - Significant Issues:
- Definition: Affect some users significantly, such as preventing the use of certain features or authentication types.
- Can also be issues that many users complain about, causing annoyance or hindering daily use.
- Impact: Affects a non-critical feature or a smaller, specific subset of users; An inconvenient but functional workaround is available; Noticeable UI/UX problems that look unprofessional.
- Qualifier: Is it an annoying but non-blocking problem?
P3 - Low-Impact Issues:
- Definition: Typically usability issues that cause annoyance to a limited user base.
- Includes feature requests that could be addressed in the near future and may be suitable for community contributions.
- Impact: Minor cosmetic issues; An edge-case bug that is very difficult to reproduce and affects a tiny fraction of users.
- A P0 bug is a catastrophic failure that demands immediate attention.
- To be a P0 it means almost all users are running into this issue and it is blocking users from being able to use the product.
- You would see this in the form of many comments from different developers on the bug.
- It represents a complete showstopper for a significant portion of users or for the development process itself.
Impact:
- Blocks development or testing for the entire team.
- Major security vulnerability that could compromise user data or system integrity.
- Causes data loss or corruption with no workaround.
- Crashes the application or makes a core feature completely unusable for all or most users in a production environment. Will it causesevere quality degration?
- Is it preventing contributors from contributing to the repository or is it a release blocker?
Qualifier: Is the main function of the software broken?
Example: The gemini auth login command fails with an unrecoverable error, preventing any user from authenticating and using the rest of the CLI.
P1: High
- A P1 bug is a serious issue that significantly degrades the user experience or impacts a core feature.
- While not a complete blocker, it's a major problem that needs a fast resolution. Feature requests are almost never P1.
- Once again this would be affecting many users.
- You would see this in the form of comments from different developers on the bug.
Impact:
- A core feature is broken or behaving incorrectly for a large number of users or large number of use cases.
- Review the bug details and comments to try figure out if this issue affects a large set of use cases or if it's a narrow set of use cases.
- Severe performance degradation making the application frustratingly slow.
- No straightforward workaround exists, or the workaround is difficult and non-obvious.
Qualifier: Is a key feature unusable or giving very wrong results?
Example: Gemini CLI enters a loop when making read-many-files tool call. I am unable to break out of the loop and gemini doesn't follow instructions subsequently.
P2: Medium
- A P2 bug is a moderately impactful issue. It's a noticeable problem but doesn't prevent the use of the software's main functionality.
Impact:
- Affects a non-critical feature or a smaller, specific subset of users.
- An inconvenient but functional workaround is available and easy to execute.
- Noticeable UI/UX problems that don't break functionality but look unprofessional (e.g., elements are misaligned or overlapping).
Qualifier: Is it an annoying but non-blocking problem?
Example: An error message is unclear or contains a typo, causing user confusion but not halting their workflow.
P3: Low
- A P3 bug is a minor, low-impact issue that is trivial or cosmetic. It has little to no effect on the overall functionality of the application.
Impact:
- Minor cosmetic issues like color inconsistencies, typos in documentation, or slight alignment problems on a non-critical page.
- An edge-case bug that is very difficult to reproduce and affects a tiny fraction of users.
Qualifier: Is it a "nice-to-fix" issue?
Example: Spelling mistakes etc.
Additional Context:
- If users are talking about issues where the model gets downgraded from pro to flash then i want you to categorize that as a performance issue.
- This product is designed to use different models eg.. using pro, downgrading to flash etc.
- When users report that they dont expect the model to change those would be categorized as feature requests.
- If users are talking about issues where the model gets downgraded from pro to flash then i want you to categorize that as a performance issue
- This product is designed to use different models eg.. using pro, downgrading to flash etc.
- When users report that they dont expect the model to change those would be categorized as feature requests.
Definition of Areas
area/ux:
- Issues concerning user-facing elements like command usability, interactive features, help docs, and perceived performance.
- I am seeing my screen flicker when using Gemini CLI
- I am seeing the output malformed
- Theme changes aren't taking effect
- My keyboard inputs arent' being recognzied
area/platform:
- Issues related to installation, packaging, OS compatibility (Windows, macOS, Linux), and the underlying CLI framework.
area/background: Issues related to long-running background tasks, daemons, and autonomous or proactive agent features.
area/models:
- i am not getting a response that is reasonable or expected. this can include things like
- I am calling a tool and the tool is not performing as expected.
- i am expecting a tool to be called and it is not getting called ,
- Function calling issues should be under this area
- i am getting responses from the model that are malformed.
- Issues concerning Gemini quality of response and inference,
- Issues talking about unnecessary token consumption.
- Issues talking about Model getting stuck in a loop be watchful as this could be the root cause for issues that otherwise seem like model performance issues.
- Memory compression
- unexpected responses,
- poor quality of generated code
area/tools:
- These are primarily issues related to Model Context Protocol
- These are issues that mention MCP support
- feature requests asking for support for new tools.
area/core:
- Issues with fundamental components like command parsing, configuration management, session state, and the main API client logic. Introducing multi-modality
area/contribution:
- Issues related to improving the developer contribution experience, such as CI/CD pipelines, build scripts, and test automation infrastructure.
area/authentication:
- Issues related to user identity, login flows, API key handling, credential storage, and access token management, unable to sign in selecting wrong authentication path etc..
area/security-privacy:
- Issues concerning vulnerability patching, dependency security, data sanitization, privacy controls, and preventing unauthorized data access.
area/extensibility:
- Issues related to the plugin system, extension APIs, or making the CLI's functionality available in other applications, github actions, ide support etc..
area/performance:
- Issues focused on model performance
- Issues with running out of capacity,
- 429 errors etc..
- could also pertain to latency,
- other general software performance like, memory usage, CPU consumption, and algorithmic efficiency.
- Switching models from one to the other unexpectedly.
- name:'Apply Labels to Issues'
if:|-
@@ -250,18 +286,33 @@ jobs:
continue;
}
const labelsToAdd = entry.labels_to_add || [];
labelsToAdd.push('status/bot-triaged');
if (labelsToAdd.length > 0) {
if (entry.labels_to_add && entry.labels_to_add.length > 0) {
isStale = new Date(lastHumanComment.created_at) < tenDaysAgo;
} else {
// No human comments. Check if creator is human.
if (issue.user.type !== 'Bot') {
isStale = createdAt < tenDaysAgo;
} else {
isStale = true; // Bot created, only bot comments
}
}
} catch (error) {
core.warning(`Failed to fetch comments for issue #${issue.number}: ${error.message}`);
continue;
}
}
if (isStale) {
processedCount++;
const message = `Closing stale issue #${issue.number}: "${issue.title}" (${issue.html_url})`;
core.info(message);
if (!dryRun) {
// Add label
await github.rest.issues.addLabels({
owner: context.repo.owner,
repo: context.repo.repo,
issue_number: issue.number,
labels: [batchLabel]
});
// Add comment
await github.rest.issues.createComment({
owner: context.repo.owner,
repo: context.repo.repo,
issue_number: issue.number,
body: 'Hello! As part of our effort to keep our backlog manageable and focus on the most active issues, we are tidying up older reports.\n\nIt looks like this issue hasn\'t been active for a while, so we are closing it for now. However, if you are still experiencing this bug on the latest stable build, please feel free to comment on this issue or create a new one with updated details.\n\nThank you for your contribution!'
// Closure Policy: No help-wanted label = Close after 14 days
if (pr.state === 'open' && !hasHelpWanted && !hasMaintainerOnly) {
const prCreatedAt = new Date(pr.created_at);
// We give a 14-day grace period for non-help-wanted PRs to be manually reviewed/labeled by an EM
if (prCreatedAt > fourteenDaysAgo) {
core.info(`PR #${pr.number} is new and lacks 'help wanted'. Giving 14-day grace period for EM review.`);
continue;
}
core.info(`PR #${pr.number} is older than 14 days and lacks 'help wanted' association. Closing.`);
if (!dryRun) {
await github.rest.issues.createComment({
owner: context.repo.owner,
repo: context.repo.repo,
issue_number: pr.number,
body: "Hi there! Thank you for your interest in contributing to Gemini CLI. \n\nTo ensure we maintain high code quality and focus on our prioritized roadmap, we have updated our contribution policy (see [Discussion #17383](https://github.com/google-gemini/gemini-cli/discussions/17383)). \n\n**We only *guarantee* review and consideration of pull requests for issues that are explicitly labeled as 'help wanted'.** All other community pull requests are subject to closure after 14 days if they do not align with our current focus areas. For this reason, we strongly recommend that contributors only submit pull requests against issues explicitly labeled as **'help-wanted'**. \n\nThis pull request is being closed as it has been open for 14 days without a 'help wanted' designation. We encourage you to find and contribute to existing 'help wanted' issues in our backlog! Thank you for your understanding and for being part of our community!"
});
await github.rest.pulls.update({
owner: context.repo.owner,
repo: context.repo.repo,
pull_number: pr.number,
state: 'closed'
});
}
continue;
}
// Also check for linked issue even if it has help wanted (redundant but safe)
if (pr.state === 'open' && !hasLinkedIssue) {
// Already covered by hasHelpWanted check above, but good for future-proofing
continue;
}
// 4. Staleness Check (Scheduled only)
if (pr.state === 'open' && context.eventName !== 'pull_request') {
// Skip PRs that were created less than 30 days ago - they cannot be stale yet
core.info(`PR #${pr.number} is stale but has a protected label. Skipping closure.`);
continue;
}
core.info(`PR #${pr.number} is stale (no maintainer activity for 30+ days). Closing.`);
if (!dryRun) {
await github.rest.issues.createComment({
owner: context.repo.owner,
repo: context.repo.repo,
issue_number: pr.number,
body: "Hi there! Thank you for your contribution. To keep our backlog manageable, we are closing pull requests that haven't seen maintainer activity for 30 days. If you're still working on this, please let us know!"
body: `👋 @${commenter}, thanks for your interest in this issue! We're reserving self-assignment for issues that have been marked with the \`help wanted\` label. Feel free to check out our list of [issues that need attention](https://github.com/google-gemini/gemini-cli/issues?q=is%3Aissue+is%3Aopen+label%3A%22help+wanted%22).`
});
return;
}
// Search for open issues already assigned to the commenter in this repo
if (assignedIssues.total_count >= MAX_ISSUES_ASSIGNED) {
@@ -83,6 +63,13 @@ jobs:
return; // exit
}
// Check if the issue is already assigned
const issue = await github.rest.issues.get({
owner: context.repo.owner,
repo: context.repo.repo,
issue_number: issueNumber,
});
if (issue.data.assignees.length > 0) {
// Comment that it's already assigned
await github.rest.issues.createComment({
@@ -109,42 +96,3 @@ jobs:
issue_number: issueNumber,
body: `👋 @${commenter}, you've been assigned to this issue! Thank you for taking the time to contribute. Make sure to check out our [contributing guidelines](https://github.com/google-gemini/gemini-cli/blob/main/CONTRIBUTING.md).`
core.info(`PR #${pr_number} is already associated with an issue. No notification needed.`);
return;
}
// 3. Post the notification comment
core.info(`${username} is not a maintainer and PR #${pr_number} has no linked issue. Posting notification.`);
const comment = `
Hi @${username}, thank you so much for your contribution to Gemini CLI! We really appreciate the time and effort you've put into this.
We're making some updates to our contribution process to improve how we track and review changes. Please take a moment to review our recent discussion post: [Improving Our Contribution Process & Introducing New Guidelines](https://github.com/google-gemini/gemini-cli/discussions/16706).
Key Update: Starting **January 26, 2026**, the Gemini CLI project will require all pull requests to be associated with an existing issue. Any pull requests not linked to an issue by that date will be automatically closed.
Thank you for your understanding and for being a part of our community!
Some files were not shown because too many files have changed in this diff
Show More
Reference in New Issue
Block a user
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.