feat: implement Open Plugins agents support#23647
feat: implement Open Plugins agents support#23647NTaylorMullen wants to merge 1 commit intontm/gh.1595from
Conversation
Summary of ChangesHello, 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 introduces a significant enhancement by allowing Open Plugins to define and manage their own sub-agents. This feature includes automatic discovery of agents within a plugin's directory structure, proper namespacing to avoid conflicts, and dynamic variable expansion for Highlights
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. Footnotes
|
🧠 Model Steering GuidanceThis PR modifies files that affect the model's behavior (prompts, tools, or instructions).
This is an automated guidance message triggered by steering logic signatures. |
There was a problem hiding this comment.
Code Review
This pull request introduces support for sub-agents within Open Plugins, a valuable enhancement that enables automatic discovery, namespacing, and variable expansion. The implementation is well-structured and includes both unit and integration tests. I've identified one high-severity security issue related to path manipulation, where the ${PLUGIN_ROOT} variable expansion could fail or be exploited if the plugin's file path contains special characters. The suggested fix effectively sanitizes the path component. Overall, this is a solid contribution with a critical security improvement.
Note: Security Review is unavailable for this PR.
| function recursivelyExpandPluginRoot<T>(obj: T, pluginRoot: string): T { | ||
| if (typeof obj === 'string') { | ||
| // eslint-disable-next-line @typescript-eslint/no-unsafe-type-assertion | ||
| return obj.replace(/\${PLUGIN_ROOT}/g, pluginRoot) as unknown as T; |
There was a problem hiding this comment.
The String.prototype.replace() method interprets special character sequences (like $&, $') in the replacement string as substitution patterns rather than literal strings. If the pluginRoot path happens to contain these characters (which is valid for file paths on some systems), the expansion of ${PLUGIN_ROOT} will be incorrect. This constitutes a path manipulation vulnerability, as unsanitized path components can lead to broken paths, unexpected behavior, or even path traversal if the resulting path is used in file system operations without further validation. To ensure pluginRoot is always treated as a literal string during replacement, it's safer to use a replacer function, effectively sanitizing the path component.
| return obj.replace(/\${PLUGIN_ROOT}/g, pluginRoot) as unknown as T; | |
| return obj.replace(/\${PLUGIN_ROOT}/g, () => pluginRoot) as unknown as T; |
References
- Sanitize user-provided file paths used in file system operations to prevent path traversal vulnerabilities. This comment addresses a similar issue where a path component needs sanitization to prevent incorrect interpretation during string replacement, which could lead to path manipulation.
e6ba2c6 to
19bb7a2
Compare
6f82a02 to
4e264eb
Compare
19bb7a2 to
f741356
Compare
- Add pluginRoot to AgentDefinition metadata
- Implement ${PLUGIN_ROOT} expansion in markdownToAgentDefinition
- Automatically discover and namespace agents in Open Plugins
- Update ExtensionManager to pass plugin root during agent loading
- Display sub-agents in extensions list output
Fixes google-gemini/maintainers-gemini-cli#1594
4e264eb to
1a3741d
Compare
Summary
This PR implements support for specialized sub-agents within Open Plugins. It enables automatic discovery, namespacing, and variable expansion for agents defined in an Open Plugin's
agents/directory.Details
AgentDefinitionto includepluginRootin metadata.recursivelyExpandPluginRootinagentLoader.tsto support${PLUGIN_ROOT}expansion in agent configs (system prompts, descriptions, MCP server args).loadAgentsFromDirectoryto handle optionalpluginRoot.resolvePluginAgentsinplugin.tsto discover and namespace agents using the{plugin-name}:{agent-name}format.ExtensionManagerto pass the effective extension path during agent loading.extensions listoutput to display discovered sub-agents.Related Issues
Fixes https://github.com/google-gemini/maintainers-gemini-cli/issues/1594
How to Validate
npm test -w @google/gemini-cli-core -- src/agents/agentLoader.test.tsto verify variable expansion logic.npm run test:e2e -- integration-tests/open-plugin-agents.test.tsto verify the full discovery and namespacing flow.agents/directory containing a.mdagent file.gemini extensions install <path>.gemini extensions listand verify the agent appears correctly namespaced and with expanded paths.Pre-Merge Checklist