feat(ide): Check for IDE diffing capabilities before opening diffs#8266
Merged
feat(ide): Check for IDE diffing capabilities before opening diffs#8266
Conversation
![gemini-code-assist[bot]](https://avatars.githubusercontent.com/in/956858?s=60&v=4){kind=small}
Contributor
There was a problem hiding this comment.
Summary of Changes
Hello @skeshive, I'm Gemini Code Assist1! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed!
This pull request significantly enhances the CLI's integration with IDEs by implementing a proactive capability discovery system. Instead of assuming diffing support, the CLI now intelligently queries the connected IDE for its openDiff and closeDiff capabilities. This ensures that users are only presented with relevant options and prevents attempts at unsupported operations, leading to a more robust and intuitive user experience.
Highlights
- IDE Capability Discovery: Introduces a mechanism for the CLI to discover the capabilities of a connected IDE, specifically checking for
openDiffandcloseDiffsupport. - Smarter Diffing Confirmation: The CLI will now only present the diffing confirmation flow to the user if the connected IDE explicitly supports diffing operations, preventing unsupported actions.
- Dynamic UI Options: The 'Modify with external editor' option in the tool confirmation message is now dynamically displayed based on whether the IDE supports diffing or if IDE mode is not active.
- Refactored IDE Client Logic: The
IdeClientnow maintains a list ofavailableToolsand provides a newisDiffingEnabled()method for checking diffing capabilities, which is used by various tools. - Comprehensive Unit Tests: New unit tests have been added for the
isDiffingEnabledmethod inide-client.test.tsto cover various connection and tool discovery scenarios.
Using Gemini Code Assist
The full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips.
Invoking Gemini
You can request assistance from Gemini at any point in your pull request via creating an issue comment (i.e. comment on the pull request page) using either /gemini <command> or @gemini-code-assist <command>. Below is a summary of the supported commands.
| Feature | Command | Description |
|---|---|---|
| Code Review | /gemini review |
Performs a code review for the current pull request in its current state. |
| Pull Request Summary | /gemini summary |
Provides a summary of the current pull request in its current state. |
| Comment | @gemini-code-assist | Responds in comments when explicitly tagged, both in issue comments and review comments. |
| Help | /gemini help |
Displays a list of available commands. |
Customization
To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a .gemini/ folder in the base of the repository. Detailed instructions can be found here.
Limitations & Feedback
Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for Github and other Google products, sign up here.
You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension.
Footnotes
-
Review the Privacy Notices, Generative AI Prohibited Use Policy, Terms of Service, and learn how to configure Gemini Code Assist in GitHub here. Gemini can make mistakes, so double check it and use code with caution. ↩
Contributor
There was a problem hiding this comment.
Code Review
This pull request introduces a valuable feature to check for IDE diffing capabilities before attempting to open a diff view. This prevents errors and improves the user experience when the connected IDE does not support this functionality. The implementation is well-structured, but I've identified a critical race condition in the new tool discovery logic. The asynchronous discoverTools function is not awaited upon connection, which could lead to the feature failing intermittently. I've provided specific suggestions to address this. The other changes across the codebase correctly adopt the new capability-checking mechanism.
|
Size Change: +1.77 kB (+0.01%) Total Size: 13.2 MB
ℹ️ View Unchanged
|
Code Coverage Summary
CLI Package - Full Text ReportCore Package - Full Text ReportFor detailed HTML reports, please see the 'coverage-reports-22.x-ubuntu-latest' artifact from the main CI run. |
Contributor
Author
|
/gemini review |
Contributor
There was a problem hiding this comment.
Code Review
This pull request introduces a mechanism to check for IDE diffing capabilities before attempting to open a diff view. The changes are generally well-implemented, but I've found a couple of high-severity issues. One is a potential race condition in the UI component where it doesn't react to IDE connection status changes. The other is a robustness issue in the error handling logic for tool discovery, which could lead to incorrect behavior with certain types of exceptions. I've provided suggestions to address both of these issues.
cornmander
approved these changes
Sep 11, 2025
| @@ -664,6 +714,7 @@ export class IdeClient { | |||
| }); | |||
| await this.client.connect(transport); | |||
| this.registerClientHandlers(); | |||
Contributor
There was a problem hiding this comment.
It feels bad that we're duplicating so much code between establishStdioConnection() and establishHttpConnection() when they only differ in the transport. Can we merge these?
giraffe-tree
pushed a commit
to giraffe-tree/gemini-cli
that referenced
this pull request
Oct 10, 2025
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
TLDR
This PR introduces a tool discovery mechanism to the IDE client. Previously, the CLI would attempt to open a diff view in the IDE for any file modification tool (
edit,write-file, etc.) simply if it was in "IDE mode" and connected. This change makes the CLI smarter by first checking if the connected IDE actually supports theopenDiffandcloseDiffcapabilities. This prevents the CLI from attempting an unsupported operation and only presents the diffing confirmation flow to the user when the connected IDE can handle it.Linked issues / bugs
#4800