Factor ExecTool out of FileSystemTools

[vorburger]

Relates to #1644 and #1762 for #1631.

Includes #1768, just to avoid rebase conflicts.

[gemini-code-assist]

Summary of Changes

Hello @vorburger, 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 significantly refactors the tool architecture by extracting the ExecTool into a standalone component and replacing the external modelcontextprotocol/filesystem with a set of built-in Java-based filesystem utilities. These changes enhance modularity and streamline the integration of command execution and file system operations. The accompanying documentation has been updated to provide clear usage guidelines and crucial security warnings for these powerful tools, ensuring users are aware of their capabilities and potential risks.

Highlights

• ExecTool Extraction: The ExecTool has been refactored out of FileSystemTools into its own dedicated class, ExecTool.java, to manage shell command execution independently.
• Built-in Filesystem Tools: The external modelcontextprotocol/filesystem server has been replaced by a comprehensive set of built-in Java-based filesystem tools, now integrated directly into FileSystemTools.
• Documentation and Security Warnings: The documentation for both the exec tool and the new built-in filesystem tools has been significantly updated, including explicit security considerations and usage examples.
• Tool Naming Convention: Tool names within FileSystemTools have been standardized to snake_case (e.g., readFile is now read_file) for consistency.
• Agent Configuration Updates: Example agent configurations have been updated to reflect the new exec tool and the built-in filesystem tools, including the removal of builtin-tool.agent.yaml and the addition of linux-system-summary.agent.yaml.

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

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 refactors the ExecTool out of FileSystemTools, creating a dedicated and more explicit tool for command execution. The new ExecTool is well-isolated, and the built-in filesystem tools are now managed more cleanly. The accompanying documentation updates are excellent, especially the clear security warnings regarding the exec and filesystem tools.

My review includes a few suggestions to improve the robustness of the new ExecTool and maintain class design best practices. Overall, this is a great step towards a more modular and understandable toolset.

[gemini-code-assist]

The current implementation calls process.destroy() on timeout, which sends a SIGTERM signal that can be ignored by the process. Since the command has already timed out, it's safer to terminate it forcefully using process.destroyForcibly() to prevent zombie processes.

Suggested change

	process.destroy();
	process.destroyForcibly();

[vorburger]

done

[gemini-code-assist]

The command execution timeout is hardcoded to 10 seconds. This might not be suitable for all commands; some may need more time, while for others this might be too long. It would be more flexible to make this timeout configurable, for example by passing it to the ExecTool constructor.

[gemini-code-assist]

The final keyword was removed from the class definition. If this class is not designed for extension, it's a good practice to declare it as final. This prevents subclassing, makes the class's behavior more predictable, and can allow for certain compiler optimizations. If you intend for this class to be subclassed, please consider adding a comment explaining why.

Suggested change

	public class FileSystemTools {
	public final class FileSystemTools {