fix(cli): exclude update_topic from confirmation queue count

[Abhijit-2592]

Summary

This PR centralizes tool visibility logic to fix UI inconsistencies, such as the update_topic tool inflating the confirmation queue count ("X of Y").

Details

The logic that dictates whether a tool call should be visible in the chat history, the active tool group, or the confirmation queue was previously fragmented across the codebase (ToolGroupMessage.tsx, confirmingTool.ts, useGeminiStream.ts).

Specifically, the update_topic tool is an auto-executing background operation that does not require user interaction. Because it was included in the calculation of the tool confirmation queue size in confirmingTool.ts, the UI showed misleading counts (e.g., "1 of 2") when only one actionable tool was actually pending.

This PR introduces a unified tool-visibility utility in the core package that exposes three semantic methods:

• isRenderedInHistory
• requiresUserConfirmation
• isVisibleInToolGroup

This cleanly resolves UI inconsistencies by providing a single source of truth for tool visibility state, removing the need for the UI to manually check against specific tool names like update_topic.

examples

Before

Queue count shows "1 of 2" when an update_topic tool is executing alongside another actionable tool.

After

Queue count accurately shows "1 of 1", excluding background narrative updates.

Related Issues

Fixes #24944

How to Validate

1. Run npm test -w @google/gemini-cli-core -- src/utils/tool-visibility.test.ts to ensure the core rules are functioning correctly.
2. Run npm test -w @google/gemini-cli to ensure existing UI tests pass.
3. Manually verify by triggering a turn with update_topic and another tool; the count should only reflect actionable tools.

Pre-Merge Checklist

[ ] Updated relevant documentation and README (if needed)
[x] Added/updated tests (if needed)
[ ] Noted breaking changes (if any)
[x] Validated on required platforms/methods:
[x] MacOS
[x] npm run

[gemini-code-assist]

Summary of Changes

Hello, I'm Gemini Code Assist¹! 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 UI inconsistency where auto-executing background tools were incorrectly included in the confirmation queue progress indicator. By filtering these specific tools out of the calculation, the user is presented with a more accurate representation of pending actionable tasks.

Highlights

• Queue Filtering: Implemented a filter to exclude the update_topic tool from the confirmation queue count calculation.
• UI Accuracy: Ensured the confirmation queue UI displays accurate counts by ignoring non-interactive background operations.

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 👍 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.

Footnotes

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. ↩

[github-actions]

Size Change: +1.59 kB (0%)

Total Size: 34.1 MB

Filename	Size	Change
./bundle/chunk-23FPURVO.js	0 B	-14.8 MB (removed)	🏆
./bundle/chunk-CTKPWAVZ.js	0 B	-3.16 MB (removed)	🏆
./bundle/chunk-OAJWZDBY.js	0 B	-3.8 kB (removed)	🏆
./bundle/core-WAA6LWYX.js	0 B	-46 kB (removed)	🏆
./bundle/devtoolsService-ZXEWSBFW.js	0 B	-28.4 kB (removed)	🏆
./bundle/gemini-4DPVKFWF.js	0 B	-552 kB (removed)	🏆
./bundle/interactiveCli-4EY5K4HP.js	0 B	-1.66 MB (removed)	🏆
./bundle/oauth2-provider-PHEWYAQH.js	0 B	-9.16 kB (removed)	🏆
./bundle/chunk-6DEPARWY.js	14.8 MB	+14.8 MB (new file)	🆕
./bundle/chunk-P7YYYQLE.js	3.8 kB	+3.8 kB (new file)	🆕
./bundle/chunk-PVMZ3CAF.js	3.16 MB	+3.16 MB (new file)	🆕
./bundle/core-GV2XKSEP.js	46.2 kB	+46.2 kB (new file)	🆕
./bundle/devtoolsService-VXQL6APW.js	28.4 kB	+28.4 kB (new file)	🆕
./bundle/gemini-NYGTFTOH.js	552 kB	+552 kB (new file)	🆕
./bundle/interactiveCli-VF47HAWC.js	1.66 MB	+1.66 MB (new file)	🆕
./bundle/oauth2-provider-5GKT7XDP.js	9.16 kB	+9.16 kB (new file)	🆕

ℹ️ View Unchanged

Filename	Size	Change
./bundle/bundled/third_party/index.js	8 MB	0 B
./bundle/chunk-34MYV7JD.js	2.45 kB	0 B
./bundle/chunk-5AUYMPVF.js	858 B	0 B
./bundle/chunk-5PS3AYFU.js	1.18 kB	0 B
./bundle/chunk-664ZODQF.js	124 kB	0 B
./bundle/chunk-DAHVX5MI.js	206 kB	0 B
./bundle/chunk-IUUIT4SU.js	56.5 kB	0 B
./bundle/chunk-P52CHEF3.js	1.96 MB	0 B
./bundle/chunk-RJTRUG2J.js	39.8 kB	0 B
./bundle/cleanup-2M2N2Y2H.js	0 B	-932 B (removed)	🏆
./bundle/devtools-36NN55EP.js	696 kB	0 B
./bundle/dist-T73EYRDX.js	356 B	0 B
./bundle/events-XB7DADIJ.js	418 B	0 B
./bundle/gemini.js	4.97 kB	0 B
./bundle/getMachineId-bsd-TXG52NKR.js	1.55 kB	0 B
./bundle/getMachineId-darwin-7OE4DDZ6.js	1.55 kB	0 B
./bundle/getMachineId-linux-SHIFKOOX.js	1.34 kB	0 B
./bundle/getMachineId-unsupported-5U5DOEYY.js	1.06 kB	0 B
./bundle/getMachineId-win-6KLLGOI4.js	1.72 kB	0 B
./bundle/memoryDiscovery-23MICZEL.js	980 B	0 B
./bundle/multipart-parser-KPBZEGQU.js	11.7 kB	0 B
./bundle/node_modules/@google/gemini-cli-devtools/dist/client/main.js	222 kB	0 B
./bundle/node_modules/@google/gemini-cli-devtools/dist/src/_client-assets.js	229 kB	0 B
./bundle/node_modules/@google/gemini-cli-devtools/dist/src/index.js	13.4 kB	0 B
./bundle/node_modules/@google/gemini-cli-devtools/dist/src/types.js	132 B	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-open.sb	3.36 kB	0 B
./bundle/sandbox-macos-restrictive-proxied.sb	3.56 kB	0 B
./bundle/sandbox-macos-strict-open.sb	4.82 kB	0 B
./bundle/sandbox-macos-strict-proxied.sb	5.02 kB	0 B
./bundle/src-QVCVGIUX.js	47 kB	0 B
./bundle/tree-sitter-7U6MW5PS.js	274 kB	0 B
./bundle/tree-sitter-bash-34ZGLXVX.js	1.84 MB	0 B
./bundle/cleanup-JKYIOWVM.js	932 B	+932 B (new file)	🆕

_{compressed-size-action}

[gemini-code-assist]

Code Review

This pull request updates the confirming tool state logic to filter out specific tool names, ensuring they are excluded from the pending tools list. The review highlights that filtering by display name is brittle and suggests implementing a more robust approach, such as adding an 'isSystemTool' flag to the 'IndividualToolCallDisplay' interface, to improve maintainability and adherence to project standards.

[jacob314]

Overall, the logic centralization into packages/core looks solid and adheres nicely to the architectural boundaries. The cleanup in the React components makes the codebase much easier to read!

One point of potential improvement I noticed:
Code Duplication (DRY): The ToolVisibilityContext object is constructed inline in four different files (ToolGroupMessage.tsx, useGeminiStream.ts, confirmingTool.ts, and historyUtils.ts).

Suggestion: Consider creating a small helper function in packages/cli (e.g., buildToolVisibilityContext(tool: IndividualToolCallDisplay)) to map a tool instance to the context object. This would reduce the boilerplate currently duplicated across these files.

Besides that minor point, I've verified that the extracted logic matches what was previously there, so there don't appear to be any unintended side-effects or behavior changes.

[Abhijit-2592]

I have addressed all of the review feedback:

1. Centralized Visibility Logic: Refactored the core visibility rules to use a unified ToolVisibilityContext.
2. Reduced Boilerplate (DRY): Implemented helper methods in both Core and CLI to map complex tool objects to the visibility context. All call sites now pass tool objects directly through these helpers.
3. Improved Naming: Renamed requiresUserConfirmation to belongsInConfirmationQueue.
4. Interface Alignment: Refactored the visibility context to be a clean subset of the standard tool call interface.

All tests are passing locally and the branch has been rebased onto main.

[jacob314]