Fix Windows compatibility and deprecated -p flag #43
Conversation
- Set shell: true in spawn() to support Windows .cmd executables - Replace deprecated -p/--prompt flag with positional prompt - Add -y flag for non-interactive YOLO mode On Windows, gemini is installed as gemini.cmd which requires shell: true to execute properly. The -p flag is deprecated and causes conflicts when used with positional prompts in newer Gemini CLI versions. Tested on Windows 11 with Gemini CLI v0.18.4
Summary of ChangesHello @cj-elevate, 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 improves the robustness and cross-platform compatibility of the Gemini CLI integration. It addresses critical issues for Windows users by enabling proper execution of Highlights
Using Gemini Code AssistThe 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 by creating a comment using either
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 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
|
![gemini-code-assist[bot]](https://avatars.githubusercontent.com/in/956858?s=60&v=4){kind=small}
There was a problem hiding this comment.
Code Review
This pull request correctly addresses Windows compatibility issues by enabling a shell for command execution and updates the code to use a positional prompt instead of the deprecated -p flag, which is a good improvement. My review includes a critical security suggestion to limit the use of shell: true to Windows only, reducing the risk of command injection on other platforms. I've also pointed out an opportunity to refactor some duplicated code to improve the long-term maintainability of the geminiExecutor.
| const childProcess = spawn(command, args, { | ||
| env: process.env, | ||
| shell: false, | ||
| shell: true, |
There was a problem hiding this comment.
Enabling shell: true unconditionally can introduce security vulnerabilities if the command or arguments are not properly sanitized, especially on non-Windows platforms where it might not be necessary. Since this change is intended for Windows compatibility, it's safer to enable the shell only when running on Windows. This minimizes the potential attack surface of command injection.
| shell: true, | |
| shell: process.platform === "win32", |
| const args = ['-y']; // YOLO mode for non-interactive | ||
| if (model) { args.push(CLI.FLAGS.MODEL, model); } | ||
| if (sandbox) { args.push(CLI.FLAGS.SANDBOX); } | ||
|
|
||
| // Ensure @ symbols work cross-platform by wrapping in quotes if needed | ||
| const finalPrompt = prompt_processed.includes('@') && !prompt_processed.startsWith('"') | ||
| ? `"${prompt_processed}"` | ||
| : prompt_processed; | ||
|
|
||
| args.push(CLI.FLAGS.PROMPT, finalPrompt); | ||
|
|
||
| // Use positional prompt (not -p flag which is deprecated) | ||
| args.push(prompt_processed); |
There was a problem hiding this comment.
The logic for constructing the arguments array is nearly identical here and in the catch block (lines 104-111). This duplication can lead to maintenance issues, where a change in one place might not be reflected in the other. To improve maintainability and reduce redundancy, consider extracting this logic into a single helper function.
- Add workingDirectory parameter to ask-gemini tool - Pass cwd to spawn() to control Gemini's workspace directory - Enables accessing files on any Windows drive (C:/, D:/, E:/, etc.) This solves the Windows multi-drive limitation where Gemini workspace is locked to the launch directory. Users can now specify which drive root to use as the working directory, giving full read access to that drive. Example: workingDirectory: "C:/" → access C: drive files workingDirectory: "D:/" → access D: drive files
2 participants
Summary
shell: trueinspawn()to support Windows.cmdexecutables-p/--promptflag with positional prompt-yflag for non-interactive YOLO modeworkingDirectoryparameter for cross-drive access on WindowsProblem
Issue 1: Windows spawn fails
On Windows,
geminiis installed asgemini.cmdwhich requiresshell: trueto execute properly via Node'sspawn(). Without this, the MCP fails with:Issue 2: Deprecated flag conflict
The
-pflag is deprecated and causes conflicts when used with positional prompts in newer Gemini CLI versions (v0.18+):Issue 3: Windows multi-drive limitation
Gemini CLI locks workspace to the launch directory. On Windows with multiple drives (C:/, D:/, E:/), users couldn't access files across drives.
Solution
shell: falsetoshell: trueincommandExecutor.ts-pflag usage with positional prompt argument-yflag for YOLO mode (required for non-interactive use)workingDirectoryparameter that setscwdin spawn, allowing users to specify which drive to accessUsage
Testing
Tested on Windows 11 with Gemini CLI v0.18.4 via Claude Code MCP integration.