docs: explain --cdp-endpoint with a manually launched real Chrome#1624
Open
mohamedalwhaidi wants to merge 1 commit into
Open
docs: explain --cdp-endpoint with a manually launched real Chrome#1624mohamedalwhaidi wants to merge 1 commit into
mohamedalwhaidi wants to merge 1 commit into
Conversation
The User profile section currently covers three paths to a persistent browser session: bundled Chromium with --user-data-dir, --isolated, and the Chrome extension. There is no narrative coverage of the --cdp-endpoint flow against a real Chrome the user launched themselves, even though the flag is documented in the configuration table. This is a frequently-asked workflow on Discord and in issues like microsoft#347 (network capture) and microsoft#1130 (CDP port exposure) — users want MCP to drive the same Chrome they already have logged in, but find the combination of `--remote-debugging-port` + a dedicated `--user-data-dir` through trial and error. Add a fourth subsection under "User profile" that walks through: - the cross-platform launch command - the MCP config snippet using `--cdp-endpoint=http://localhost:9222` - the gotcha that the default Chrome profile cannot be used (Chrome blocks CDP attach on it, so a dedicated profile dir is mandatory)
Author
|
@microsoft-github-policy-service agree [company="N/A"] |
Author
|
@microsoft-github-policy-service agree |
|
Hi! I built a GitHub Action for MCP server observability — instruments your MCP server with logging, traces, and error diagnostics directly in CI/CD. Repo: https://github.com/SolvoHQ/mcp-logger-action Would love your feedback — does this solve a real problem for MCP server developers? |
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
2 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
The User profile section in the README covers three paths to a persistent browser session:
--user-data-dir)--cdp-endpointis documented in the configuration flag table but there is no narrative coverage of using it against a real Chrome the user launched themselves. This is a frequently-asked workflow — users want MCP to drive the same Chrome they already have logged in to (a SaaS, a staging environment, etc.) without installing an extension or re-logging-in inside Playwright's bundled Chromium.This PR adds a fourth subsection — Connect to your own Chrome via CDP — that walks through:
--cdp-endpoint=http://localhost:9222--user-data-diris mandatory (highlighted with a callout)Motivation
Related discussions and feature requests where this workflow comes up:
In both cases users land on
--cdp-endpointafter trial and error. Documenting the recipe should cut the support load and lower the barrier to a real-Chrome workflow.Scope
Docs-only. No code, no behavior change. CONTRIBUTING.md exempts minor documentation fixes from the issue-first rule.
Test plan