How to pass --browserUrl when chrome-devtools-mcp is a Claude Code plugin?

4 answers

• Best answerAgentArmorHQ teamTeam4d ago

  Status: still open. A contributor acknowledged the request ("Indeed, we should support this."), and the thread's workaround is to keep the plugin installed for its skills while using a separate standalone MCP server for the Chrome connection.

  The original reporter's standalone .mcp.json configuration is:

  jsonCopy to clipboard

  {
    "mcpServers": {
      "chrome-devtools": {
        "command": "npx",
        "args": ["chrome-devtools-mcp@latest", "--browserUrl", "http://127.0.0.1:9222"]
      }
    }
  }
  

  This connects to the existing Chrome instance, but the plugin's bundled skills (a11y-debugging, debug-optimize-lcp, chrome-devtools, troubleshooting) are not available because the plugin is disabled.

  Commenters reported a better workaround: install the Chrome DevTools MCP plugin so its skills stay available, disable only the plugin-sourced MCP server, and add a manually configured MCP server with your --browserUrl flag. One commenter described this combination as their current working approach, and another recommended the same.

  The issue proposes making CLI flags configurable through Claude Code's pluginConfigs in settings.json:

  jsonCopy to clipboard

  {
    "pluginConfigs": {
      "chrome-devtools-mcp@claude-plugins-official": {
        "mcpServers": {
          "chrome-devtools": {
            "browserUrl": "http://127.0.0.1:9222"
          }
        }
      }
    }
  }
  

  A commenter additionally suggested declaring a userConfig option in the plugin's plugin.json, citing Claude Code's plugin options feature (changelog 2.1.83), and shared a draft snippet for browserUrl. The commenter warned the snippet came from their own local Claude Code session analysis, not official docs. The thread does not show that approach being implemented.

  General advice: keep Chrome's remote debugging port bound to 127.0.0.1 and avoid exposing it to untrusted networks.

  Did this work for you?WorkedDidn't work
  UpvoteStarReport
• AgentArmorHQ teamTeam4d ago

  What @Sayvai tried on GitHub (Worked)

  A commenter installed the Chrome DevTools MCP plugin so its automatically bundled skills are available, disabled the plugin-sourced MCP server, and relied on a separately integrated manual MCP server for the custom browser URL. They described this as their current working workaround, and another commenter later recommended the same approach.

  Source: https://github.com/ChromeDevTools/chrome-devtools-mcp/issues/1232#issuecomment-4178053519 (opens external site) ↗

  Did this work for you?WorkedDidn't work
  UpvoteStarReport
• AgentArmorHQ teamTeam4d ago

  What a GitHub user tried on GitHub (Partly worked)

  The reporter disabled the plugin and added a standalone MCP server in .mcp.json with command: npx and args: ["chrome-devtools-mcp@latest", "--browserUrl", "http://127.0.0.1:9222"]. This connected to the existing Chrome instance, but the plugin's bundled skills were lost.

  Source: https://github.com/ChromeDevTools/chrome-devtools-mcp/issues/1232 (opens external site) ↗

  Did this work for you?WorkedDidn't work
  UpvoteStarReport
• AgentArmorHQ teamTeam4d ago

  What @Sayvai tried on GitHub (Partly worked)

  A commenter on macOS edited two plugin.json files under .claude/plugins/marketplaces/chrome-devtools-plugins/.claude-plugin/ and .claude/plugins/cache/chrome-devtools-plugins/chrome-devtools-mcp/<CURRENT_MCP_VERSION>/.claude-plugin/ to inject the custom MCP server configuration. This made Claude Code reliably list pages or tabs on the existing Chrome instance, but the commenter later retracted it because future chrome-devtools-mcp releases override and reset those files.

  Source: https://github.com/ChromeDevTools/chrome-devtools-mcp/issues/1232#issuecomment-4178615817 (opens external site) ↗

  Did this work for you?WorkedDidn't work
  UpvoteStarReport