feat: add Claude plugin executablePath user config#1981
Open
maruen wants to merge 1 commit intoChromeDevTools:mainfrom
Open
feat: add Claude plugin executablePath user config#1981maruen wants to merge 1 commit intoChromeDevTools:mainfrom
maruen wants to merge 1 commit intoChromeDevTools:mainfrom
Conversation
Add a userConfig option for the executablePath CLI flag so users running the plugin via Claude Code can point at a custom Chrome binary without editing the plugin manifest in their plugin cache. Useful when the host has multiple Chrome installations — for example pointing at Chrome for Testing on macOS so the MCP-launched Chrome has a separate bundle ID (com.google.chrome.for.testing) and can be scripted unambiguously by AppleScript / OS automation tools without conflicting with the user's regular Chrome (com.google.Chrome). Mirrors the user_config.browserUrl pattern from ChromeDevTools#1851. Leaving the option blank keeps the existing auto-detected-stable-Chrome behavior — no opt-in cost.
OrKoN
reviewed
Apr 30, 2026
Comment on lines
+5
to
+10
| "userConfig": { | ||
| "executablePath": { | ||
| "description": "Optional path to a custom Chrome executable. Useful when the system has multiple Chrome installations (e.g. point at the Chrome for Testing binary so the MCP-launched Chrome stays separate from the user's regular Chrome and can be scripted unambiguously by AppleScript / OS automation tools). Leave blank to use the auto-detected stable Chrome.", | ||
| "sensitive": false | ||
| } | ||
| }, |
Collaborator
There was a problem hiding this comment.
can we update it as part of npm run gen? so that it does not need to be manually maintained? perhaps a new script to update plugin configurations would be great.
cc @natorion
Contributor
|
I think adding this makes sense. Any other client integrations we have to update? |
Collaborator
AFAIK not all clients support something like this in their plugins. So it would have to be done per client. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
executablePathuser config option so users can point the MCP at a custom Chrome binary (e.g. Chrome for Testing) without editing the plugin manifest in their plugin cache.--executablePath=${user_config.executablePath}. A blank value keeps the default auto-detected-stable-Chrome behavior.pluginConfigssettings shape, mirroring feat: add Claude plugin browser URL config #1851.Motivation
On macOS, when the user's regular Chrome and the MCP-launched Chrome share bundle ID
com.google.Chrome, AppleScripttell application "Google Chrome"becomes ambiguous and OS-automation menu commands (e.g. Tab → Pin Tab) silently no-op on the wrong window. Pointing the MCP at/Applications/Google Chrome for Testing.app/Contents/MacOS/Google Chrome for Testing(bundle IDcom.google.chrome.for.testing) gives the MCP-launched Chrome a separate AppleScript identity and resolves the conflict — but currently requires patching the plugin manifest in the user's plugin cache, which gets reset on plugin upgrade.Testing
jq . .claude-plugin/plugin.jsonparses cleanlynpm run check-format(eslint + prettier) passes