fix: similar to policy-engine, throw error in case of requiring tool execution confirmation for non-interactive mode
Summary
Replicate throwing error (inspired by DENY case of policy-engine) in case of non-interactive mode and requiring user confirmation for tool execution. This avoids non-interactive gemini-cli indefinitely waiting for mcp-server tool execution confirmation. This error is caught and an error response is shown to the user.
Details
The issue #11459 is only observed in case the Policy Engine is not enabled. Code flow:
When a tool call is scheduled and processed (inside _processNextInQueue() method of packages/core/src/core/coreToolScheduler.ts), it calls shouldConfirmExecute() method of packages/core/src/tools/tools.ts to determine if user approval is needed. For determining this, the flow splits here depending on whether the policy-engine is enabled or not. In case the policy-engine is not enabled, the legacy confirmation flow is used.
- In case policy-engine is enabled via messageBus, it automatically convert ASK_USER decisions to DENY (check shouldConfirmExecute() method of packages/core/src/tools/tools.ts).
- Else, as per the legacy flow of mcp-tools, in case the server is not trusted, user confirmation message is required (check getConfirmationDetails() method of packages/core/src/tools/mcp-tool.ts).
Finally, if the user confirmation message is required, it is checked if the tool part of --allowedTools list. If not, user confirmation message is triggered (check _processNextInQueue() method of packages/core/src/core/coreToolScheduler.ts).
The user confirmation is required for executing mcp-tools (in case the server is not trusted or the tool is not explicitly allowed). This causes the indefinite waiting of non-interactive gemini-cli on executing mcp-tools.
To solve this, the exact same logic defined in policy-engine of throwing error in case of tool deny is used. This error is caught and an error response is shown to the user (check _processNextInQueue() method of packages/core/src/core/coreToolScheduler.ts)
Related Issues
Fixes #11459
How to Validate
Follow steps to reproduce #11459
Pre-Merge Checklist
- [ ] Updated relevant documentation and README (if needed)
- [ ] Added/updated tests (if needed)
- [ ] Noted breaking changes (if any)
- [ ] Validated on required platforms/methods:
- [ ] MacOS
- [x] npm run
- [ ] npx
- [ ] Docker
- [ ] Podman
- [ ] Seatbelt
- [ ] Windows
- [ ] npm run
- [ ] npx
- [ ] Docker
- [ ] Linux
- [ ] npm run
- [ ] npx
- [ ] Docker
- [ ] MacOS
Working as expected without indefinite wait on invoking mcp-server tool in non-interactive mode:
Summary of Changes
Hello @MayV, I'm Gemini Code Assist[^1]! 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 addresses a critical issue where the gemini-cli would indefinitely wait for user confirmation when attempting to execute tools in a non-interactive environment. By implementing a mechanism to throw an error in such cases, mirroring the behavior of the policy-engine's denial logic, the CLI now gracefully exits with an error, preventing hangs and providing immediate feedback to the user.
Highlights
- Non-interactive Mode Handling: Introduced an error throw when tool execution requires confirmation in non-interactive mode, preventing indefinite waiting.
- Policy Alignment: The new error-throwing logic is similar to the policy-engine's DENY behavior, ensuring consistent handling of unconfirmed tool executions.
-
User Experience: The change prevents the
gemini-clifrom hanging and provides a clear error response to the user in scenarios where tool confirmation is needed but cannot be provided.
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 by creating a comment using either /gemini <command> or @gemini-code-assist <command>. Below is a summary of the supported commands on the current page.
| 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 pull request 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 :thumbsup: and :thumbsdown: 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.
[^1]: 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.
Size Change: +294 B (0%)
Total Size: 21.6 MB
ℹ️ View Unchanged
| Filename | Size | Change |
|---|---|---|
./bundle/gemini.js |
21.6 MB | +294 B (0%) |
./bundle/sandbox-macos-permissive-closed.sb |
1.03 kB | 0 B |
./bundle/sandbox-macos-permissive-open.sb |
890 B | 0 B |
./bundle/sandbox-macos-permissive-proxied.sb |
1.31 kB | 0 B |
./bundle/sandbox-macos-restrictive-closed.sb |
3.29 kB | 0 B |
./bundle/sandbox-macos-restrictive-open.sb |
3.36 kB | 0 B |
./bundle/sandbox-macos-restrictive-proxied.sb |
3.56 kB | 0 B |
The "Tool Call Lifecycle" section of Gemini CLI A2A documentation clearly states that the confirmation requirement is expected for tool calls. Hence do not throw error and break the flow in case of an A2A request. To identify if the request is an A2A request, a new config is added which is only set to true when an A2A request is created.