feat: add --profile-directory option to specify Chrome profile by Yasindu20 · Pull Request #753 · ChromeDevTools/chrome-devtools-mcp

Yasindu20 · 2026-01-12T08:08:23Z

Summary

Adds support for specifying which Chrome profile to use via a new --profile-directory CLI option.

Motivation

Users often need to:

Test with different browser profiles that have specific extensions installed
Maintain separate contexts for different projects
Use profiles with pre-configured settings or logged-in accounts

Currently, there's no way to specify which profile Chrome should use when launched by the MCP server.

Changes

✅ Added --profile-directory CLI option with kebab-case alias
✅ Updated BrowserOptions interface to include profileDirectory property
✅ Connected CLI argument to Chrome's --profile-directory launch flag
✅ Added documentation in README.md with usage examples
✅ Included in the auto-generated options documentation

Usage Example

{
  "mcpServers": {
    "chrome-devtools": {
      "command": "npx",
      "args": [
        "chrome-devtools-mcp@latest",
        "--profile-directory=Profile 1"
      ]
    }
  }
}

Or via command line:

npx chrome-devtools-mcp --profile-directory="Profile 1"

Documentation generated correctly with npm run docs
format with npm run format

Related Issues

Fixes #694

Added a new CLI option to allow users to specify which Chrome profile to use when launching the browser. Changes: - Added --profile-directory CLI argument - Updated BrowserOptions interface - Connected CLI arg to Chrome launch flag - Added documentation in README.md

sebastianbenz

Looks good, one suggestion on the docs.

src/cli.ts

sebastianbenz · 2026-01-12T10:10:35Z

Did you test this with autoconnect? I just tested this by running Chrome in "Profile 1" and setting "--profile-directory=Profile 2". In this case, the MCP server still connected to Profile 1, but I would've expected the connection to fail. Or is this the intended behavior?

Co-authored-by: Sebastian Benz <sebastian.benz@gmail.com>

Yasindu20 · 2026-01-13T06:41:49Z

Did you test this with autoconnect? I just tested this by running Chrome in "Profile 1" and setting "--profile-directory=Profile 2". In this case, the MCP server still connected to Profile 1, but I would've expected the connection to fail. Or is this the intended behavior?

@sebastianbenz Yes, I tested this with autoconnect and saw the same behavior even when Chrome is running with “Profile 1”, the MCP server still connects successfully when --profile-directory=Profile 2 is specified. So, I add a validation step to detect a profile mismatch after connecting and fail fast instead of silently attaching to the wrong profile. The intention is to avoid surprising connections when a specific profile is explicitly requested. Let me know if you’d like me to add anything specific to the docs around the profile behavior.

tacsizkral546154 · 2026-01-13T06:43:37Z

- Yasindu, Chrome profilini belirtmek için yeni --profile-directory seçeneğini ekleyen bir çekme isteği başlattı. - Sebastian'ın otomatik bağlantı sırasındaki profil uyuşmazlığı endişeleri üzerine, Yasindu bir doğrulama adımı ekledi. 13 Oca 2026 Sal 09:42 tarihinde Yasindu Dasanga De Mel < ***@***.***> şunu yazdı:

…

*Yasindu20* left a comment (ChromeDevTools/chrome-devtools-mcp#753) <#753 (comment)> Did you test this with autoconnect? I just tested this by running Chrome in "Profile 1" and setting "--profile-directory=Profile 2". In this case, the MCP server still connected to Profile 1, but I would've expected the connection to fail. Or is this the intended behavior? @sebastianbenz <https://github.com/sebastianbenz> Yes, I tested this with autoconnect and saw the same behavior even when Chrome is running with “Profile 1”, the MCP server still connects successfully when --profile-directory=Profile 2 is specified. So, I add a validation step to detect a profile mismatch after connecting and fail fast instead of silently attaching to the wrong profile. The intention is to avoid surprising connections when a specific profile is explicitly requested. Let me know if you’d like me to add anything specific to the docs around the profile behavior. — Reply to this email directly, view it on GitHub <#753 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/BMNMCXR527L4IE7CKSWEF5D4GSHUHAVCNFSM6AAAAACRMMOQI2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTONBSGI3TAOBUHE> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

OrKoN · 2026-01-13T11:23:57Z

src/browser.ts

+
+  if (options.profileDirectory && options.userDataDir) {
+    try {
+      const portPath = path.join(options.userDataDir, 'DevToolsActivatePort');


such file does not exist, did you mean DevToolsPort. A single user data dir hosts multiple profiles so I am not sure if the check handles it correctly.

OrKoN · 2026-01-13T11:24:43Z

src/browser.ts

    );
  }
+
+  if (options.profileDirectory && options.userDataDir) {


I do not think this check should be in the connection code branch.

OrKoN · 2026-01-13T11:25:11Z

src/cli.ts

    default: true,
    describe: 'Set to false to exclude tools related to network.',
  },
+  profileDirectory: {


we probably should be using https://pptr.dev/api/puppeteer.browser.browsercontexts to locate the browser context for the profile (currently the default browser context is used)

… the connection path, switched to referencing browser.browserContexts()

Yasindu20 · 2026-01-13T15:31:31Z

@OrKoN I fixed the DevToolsActivePort from DevToolsActivatePort. Removed the profile validation logic since a single userDataDir can contain multiple profiles, and that check isn’t reliable. Also removed the profile-related checks from the connection path, add it to the function launch(). For profile handling, I switched to referencing browser.browserContexts() and added clear logging that we currently fall back to the default context. Proper profile → context mapping can be improved once Puppeteer exposes a cleaner way to do this.

OrKoN · 2026-01-13T15:34:28Z

src/browser.ts

+    logger(`Found ${contexts.length} browser context(s)`);
+
+    logger(
+      `Profile directory "${profileDirectory}" specified. ` +


I think this PR does not add anything useful without the implementation for finding the browser context that matches the profileDirectory name. Passing --profile-directory to Chrome is already possible via the --chrome-arg param. Would you be up to figuring out how to find the correct browser context? it might right changes on the CDP and Puppeteer side.

Yasindu20 · 2026-01-13T16:44:23Z

@OrKoN Puppeteer or CDP don’t currently expose profile directory info for browser contexts. Now I tried to implement it to open a temporary page in each context, reads chrome://version to get the profile path, and matches it to the requested --profile-directory. If no match is found, it falls back to the default context. This works with existing APIs and can be updated later if CDP/Puppeteer expose profile metadata. If need any changes let me know

OrKoN requested a review from sebastianbenz January 12, 2026 08:52

sebastianbenz reviewed Jan 12, 2026

View reviewed changes

src/cli.ts Outdated Show resolved Hide resolved

Yasindu20 and others added 4 commits January 13, 2026 08:56

Update src/cli.ts

e15f5dc

Co-authored-by: Sebastian Benz <sebastian.benz@gmail.com>

Merge branch 'main' into support-multiple-chrome-profiles

0abdf77

added a validation step to detect a profile mismatch

08f98e4

Run the npm run docs to up to date the documentation

3d5da8b

OrKoN reviewed Jan 13, 2026

View reviewed changes

fixed the DevToolsActivePort, removed the profile-related checks from…

276f81a

… the connection path, switched to referencing browser.browserContexts()

OrKoN reviewed Jan 13, 2026

View reviewed changes

Probe each BrowserContext

6744657

Yasindu20 requested review from OrKoN and sebastianbenz January 14, 2026 13:52

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

feat: add --profile-directory option to specify Chrome profile#753

feat: add --profile-directory option to specify Chrome profile#753
Yasindu20 wants to merge 7 commits intoChromeDevTools:mainfrom
Yasindu20:support-multiple-chrome-profiles

Yasindu20 commented Jan 12, 2026

Uh oh!

sebastianbenz left a comment

Uh oh!

Uh oh!

sebastianbenz commented Jan 12, 2026

Uh oh!

Yasindu20 commented Jan 13, 2026

Uh oh!

tacsizkral546154 commented Jan 13, 2026 via email

Uh oh!

OrKoN Jan 13, 2026

Uh oh!

OrKoN Jan 13, 2026

Uh oh!

OrKoN Jan 13, 2026

Uh oh!

Yasindu20 commented Jan 13, 2026

Uh oh!

OrKoN Jan 13, 2026

Uh oh!

Yasindu20 commented Jan 13, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

Conversation

Yasindu20 commented Jan 12, 2026

Summary

Motivation

Changes

Usage Example

Related Issues

Uh oh!

sebastianbenz left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

sebastianbenz commented Jan 12, 2026

Uh oh!

Yasindu20 commented Jan 13, 2026

Uh oh!

tacsizkral546154 commented Jan 13, 2026 via email

Uh oh!

OrKoN Jan 13, 2026

Choose a reason for hiding this comment

Uh oh!

OrKoN Jan 13, 2026

Choose a reason for hiding this comment

Uh oh!

OrKoN Jan 13, 2026

Choose a reason for hiding this comment

Uh oh!

Yasindu20 commented Jan 13, 2026

Uh oh!

OrKoN Jan 13, 2026

Choose a reason for hiding this comment

Uh oh!

Yasindu20 commented Jan 13, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants