Conversation
Define the validation shape for SSH remote filesystem config with fields: enabled, sshHost, sshKeyPath, sshPort, and allowedPaths.
Existing configs without remoteFileSystem will get disabled defaults automatically, ensuring zero breaking changes.
Returns empty array when remote filesystem is not enabled in config.
Auto-accepts first connection but rejects changed host keys for safety.
Ensures clean failure instead of indefinite hang when key auth fails.
Pipes @modelcontextprotocol/server-filesystem stdio through SSH, passing configured allowedPaths to restrict remote access.
Allows subagents to request remote filesystem tools via delegation.
Subagents can now request remoteFilesystem tools via delegation.
The main agent now has direct access to remote filesystem MCP tools alongside local filesystem tools.
Summary of ChangesHello @MarvelNwachukwu, 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 enhances the agent's capabilities by enabling secure access to remote file systems via SSH. This allows agents to interact with files on external machines, expanding their operational reach and facilitating tasks that require remote data manipulation or inspection. The new functionality is configurable and integrates seamlessly with existing tool delegation. Highlights
Changelog
Activity
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 introduces remote filesystem access via SSH. The overall implementation is sound, but I've identified a few critical issues related to security and correctness. Specifically, the configuration schema for the new feature needs stricter validation to prevent runtime errors. More importantly, there are two security vulnerabilities in how the SSH command is constructed: one concerning host key verification which could lead to MITM attacks, and another related to using an unpinned package version with npx, creating a supply chain attack vector. I've provided detailed comments and suggestions to address these points.
| command: "ssh", | ||
| args: [ | ||
| "-o", | ||
| "StrictHostKeyChecking=accept-new", |
There was a problem hiding this comment.
Using StrictHostKeyChecking=accept-new poses a significant security risk as it makes the SSH connection vulnerable to Man-in-the-Middle (MITM) attacks. This option automatically trusts new host keys without verification. For a more secure implementation, it's recommended to remove this option and require users to add the host key to their known_hosts file manually before the first connection.
| remoteFileSystem: z | ||
| .object({ | ||
| enabled: z.boolean(), | ||
| sshHost: z.string(), | ||
| sshKeyPath: z.string(), | ||
| sshPort: z.number().default(22), | ||
| allowedPaths: z.array(z.string()), | ||
| }) | ||
| .optional() | ||
| .default({ | ||
| enabled: false, | ||
| sshHost: "", | ||
| sshKeyPath: "", | ||
| sshPort: 22, | ||
| allowedPaths: [], | ||
| }), |
There was a problem hiding this comment.
The current schema allows remoteFileSystem to be enabled with an empty sshHost or sshKeyPath, which will cause runtime errors when the SSH command is executed. You should add a .refine() validation to the Zod schema to ensure these fields are non-empty strings when enabled is true.
remoteFileSystem: z
.object({
enabled: z.boolean(),
sshHost: z.string(),
sshKeyPath: z.string(),
sshPort: z.number().default(22),
allowedPaths: z.array(z.string()),
})
.refine(
(data) => !data.enabled || (data.sshHost !== "" && data.sshKeyPath !== ""),
{
message: "sshHost and sshKeyPath must be provided when remoteFileSystem is enabled.",
},
)
.optional()
.default({
enabled: false,
sshHost: "",
sshKeyPath: "",
sshPort: 22,
allowedPaths: [],
}),| remoteFsConfig.sshHost, | ||
| "npx", | ||
| "-y", | ||
| "@modelcontextprotocol/server-filesystem", |
There was a problem hiding this comment.
Executing npx -y without pinning the package version creates a supply chain security risk. This command will always fetch the latest version of @modelcontextprotocol/server-filesystem, which could be a compromised version in the future. It is strongly recommended to pin this to a specific, known-good version. Please replace 0.0.0 in the suggestion with the actual version you intend to use.
| "@modelcontextprotocol/server-filesystem", | |
| "@modelcontextprotocol/server-filesystem@0.0.0", |
…docs Remote filesystem tools had identical names to local tools (read_file, write_file, etc.), causing collisions. Prefix all remote tools with "remote_" and inject remote PC tool documentation into the agent system prompt so it knows when and how to use them.
|
Deprioritized- Will re-implement if we decide to continue development |
1 participant
No description provided.