feat(plan): hide plan write and edit operations on plans in Plan Mode

[jerop]

This change hides 'WriteFile' and 'Edit' tool operations from the terminal history when they are executed while the agent is in Plan Mode. This avoids redundancy because the resulting plans are displayed in a specialized UI separately for approval.

Details:

• We store 'approvalMode' directly on the 'ToolCall' status objects in the scheduler. This ensures that tool calls remain hidden even after the CLI transitions out of Plan Mode, preventing them from suddenly popping back into history during a re-render.
• Refactored 'shouldHideAskUserTool' into a generic 'shouldHideToolCall' utility in 'packages/cli/src/ui/utils/toolUtils.ts'. This centralizes the logic for hiding tools that are either redundant or handled by specialized UI (like 'Ask User' calls).
• Updated 'Scheduler' and 'CoreToolScheduler' to capture and propagate the active 'approvalMode' at the time of tool invocation.
• Preserved 'approvalMode' across all tool call state transitions in the 'SchedulerStateManager'.

Alternatives Considered:

• Path-based hiding (checking if a write targets the 'plansDir'): Rejected because it is less semantic and would require adding complex path normalization/comparison logic and tool arguments to the UI display layer.
• Reading current mode from config: Rejected because history items would reappear as soon as the user exited Plan Mode.

Fixes #18918

---

[gemini-code-assist]

Summary of Changes

Hello @jerop, 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 improves the user experience in the CLI's 'Plan Mode' by intelligently filtering out certain tool operations from the main terminal history. Specifically, 'WriteFile' and 'Edit' operations are no longer displayed in the history when the agent is in Plan Mode, as their outcomes are presented through a dedicated planning UI. This change centralizes the logic for determining tool visibility, making the UI cleaner and more focused on relevant information for the user.

Highlights

• UI Filtering for Plan Mode: WriteFile and Edit tool operations are now hidden from the terminal history when executed in Plan Mode, preventing redundancy as these plans are displayed in a specialized UI.
• Centralized Tool Visibility Logic: The logic for hiding tool calls has been refactored into a new, generic shouldHideToolCall utility. This utility now handles both in-progress 'Ask User' tools and 'WriteFile'/'Edit' tools in Plan Mode.
• Approval Mode Propagation: The approvalMode is now captured and propagated through the Scheduler and CoreToolScheduler to individual ToolCall status objects, ensuring consistent visibility behavior even after exiting Plan Mode.
• State Management Preservation: The approvalMode property is preserved across all tool call state transitions within the SchedulerStateManager.

Changelog

• packages/cli/src/ui/components/messages/ToolGroupMessage.test.tsx
  • Imported new display name constants and ApprovalMode.
  • Added new test cases to verify tool visibility filtering based on ApprovalMode.
• packages/cli/src/ui/components/messages/ToolGroupMessage.tsx
  • Replaced the specific shouldHideAskUserTool import with the new generic shouldHideToolCall utility.
  • Updated the tool call filtering logic to use the new shouldHideToolCall utility, passing additional parameters including approvalMode.
• packages/cli/src/ui/types.ts
  • Imported the ApprovalMode type.
  • Added an optional approvalMode property to the IndividualToolCallDisplay interface.
• packages/cli/src/ui/utils/toolUtils.test.ts
  • Added a new file containing unit tests for the shouldHideToolCall utility.
  • Included tests for hiding 'Ask User' tools based on status and result display.
  • Included tests for hiding 'WriteFile' and 'Edit' tools specifically in Plan Mode.
• packages/cli/src/ui/utils/toolUtils.ts
  • Added a new file defining the shouldHideToolCall utility function.
  • Implemented logic to hide 'Ask User' tools when in-progress or errored without results.
  • Implemented logic to hide 'WriteFile' and 'Edit' tools when approvalMode is set to PLAN.
• packages/core/src/core/coreToolScheduler.ts
  • Captured the current approvalMode from the configuration.
  • Propagated the approvalMode to newly created ToolCall objects, including those for errors and successful invocations.
• packages/core/src/scheduler/scheduler.ts
  • Imported the ApprovalMode type.
  • Captured the current approvalMode at the start of the scheduling process.
  • Modified _validateAndCreateToolCall to accept and propagate the approvalMode to tool call objects.
• packages/core/src/scheduler/state-manager.ts
  • Ensured the approvalMode property is included when creating and transitioning various tool call state objects.
• packages/core/src/scheduler/types.ts
  • Imported the ApprovalMode type.
  • Added an optional approvalMode property to all relevant tool call type definitions (e.g., ValidatingToolCall, ErroredToolCall, SuccessfulToolCall).
• packages/core/src/tools/ask-user.test.ts
  • Removed tests for the shouldHideAskUserTool function, as its logic has been moved and generalized.
• packages/core/src/tools/ask-user.ts
  • Removed the shouldHideAskUserTool function, as its functionality was migrated to a new generic utility.
• packages/core/src/tools/edit.ts
  • Imported the EDIT_DISPLAY_NAME constant.
  • Updated the EditTool constructor to use EDIT_DISPLAY_NAME for consistency.
• packages/core/src/tools/glob.ts
  • Imported the GLOB_DISPLAY_NAME constant.
  • Updated the GlobTool constructor to use GLOB_DISPLAY_NAME for consistency.
• packages/core/src/tools/read-file.ts
  • Imported the READ_FILE_DISPLAY_NAME constant.
  • Updated the ReadFileTool constructor to use READ_FILE_DISPLAY_NAME for consistency.
• packages/core/src/tools/tool-names.ts
  • Centralized and defined new display name constants for WriteFile, Edit, ReadFile, and FindFiles tools.
• packages/core/src/tools/write-file.ts
  • Imported the WRITE_FILE_DISPLAY_NAME constant.
  • Updated the WriteFileTool constructor to use WRITE_FILE_DISPLAY_NAME for consistency.

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.

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

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

[gemini-code-assist]

Code Review

This pull request effectively hides WriteFile and Edit tool operations from the UI when in Plan Mode, which is a great enhancement to reduce redundancy. The approach of storing the approvalMode on the ToolCall object is solid, ensuring that the visibility state is preserved even if the application's mode changes. The refactoring of shouldHideAskUserTool into a more generic shouldHideToolCall utility is a commendable improvement for maintainability, centralizing the logic for tool visibility. The changes to propagate the approvalMode through the schedulers and state manager are implemented correctly and consistently. The addition of new tests and the updates to existing ones provide good coverage for the new functionality. Overall, this is a well-executed feature with clean and robust changes.

[github-actions]

Size Change: +2.19 kB (+0.01%)

Total Size: 24.4 MB

Filename	Size	Change
./bundle/gemini.js	24.4 MB	+2.19 kB (+0.01%)

ℹ️ View Unchanged

Filename	Size
./bundle/sandbox-macos-permissive-open.sb	890 B
./bundle/sandbox-macos-permissive-proxied.sb	1.31 kB
./bundle/sandbox-macos-restrictive-open.sb	3.36 kB
./bundle/sandbox-macos-restrictive-proxied.sb	3.56 kB
./bundle/sandbox-macos-strict-open.sb	4.82 kB
./bundle/sandbox-macos-strict-proxied.sb	5.02 kB

_{compressed-size-action}

[jerop]

note: failing windows tests are flaky (unrelated to these changes)

[jacob314]

Approved once shouldHideToolCall is mode to package/core

[jacob314]