feat(skill): Add Native Browser CDP Takeover Skill - #17
Conversation
There was a problem hiding this comment.
Pull request overview
Adds a new “browser-cdp-takeover” skill documenting how to connect to an already-running Chrome instance via the local CDP port (9222) so automation can reuse the user’s existing session state (cookies/logins).
Changes:
- Introduces a new
browser-cdp-takeoverskill document with setup prerequisites and connection examples. - Provides Playwright (Python) and MCP (
chrome-devtools) connection guidance and Windows-specific notes.
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
| ``` | ||
|
|
||
| ## 4. How to Connect (MCP `chrome-devtools`) | ||
| If the `chrome-devtools` MCP server is installed and configured with `"autoConnect": true`, the AI agent can directly use MCP tools (e.g., `mcp_chrome-devtools_list_pages`, `mcp_chrome-devtools_click`, `mcp_chrome-devtools_fill`) to interact with the active browser. |
There was a problem hiding this comment.
Section 4 references MCP tool names like mcp_chrome-devtools_list_pages/mcp_chrome-devtools_click/mcp_chrome-devtools_fill, but the existing skills/chrome-devtools/SKILL.md documents the tool names as list_pages, click, fill, etc. Using inconsistent/nonexistent tool identifiers will make the instructions fail for users; please align the names with the repo’s documented chrome-devtools tool surface (and, if a prefix is required by your runtime, document the exact prefix format used in this repo).
| If the `chrome-devtools` MCP server is installed and configured with `"autoConnect": true`, the AI agent can directly use MCP tools (e.g., `mcp_chrome-devtools_list_pages`, `mcp_chrome-devtools_click`, `mcp_chrome-devtools_fill`) to interact with the active browser. | |
| If the `chrome-devtools` MCP server is installed and configured with `"autoConnect": true`, the AI agent can directly use the `chrome-devtools` tools (e.g., `list_pages`, `click`, `fill`) documented in `skills/chrome-devtools/SKILL.md` to interact with the active browser. Depending on your MCP host, these tools may be exposed with a runtime-specific prefix, but their base identifiers remain the same. |
| Once checked, Chrome exposes the CDP port at `127.0.0.1:9222`. | ||
|
|
||
| ## 2. Windows-Specific Quirks | ||
| - **Avoid Subagent Tools Defaults**: Do not use standard browser subagent tools (`open_browser_url`, browser recording) as the default path, as they may fail or lose context. |
There was a problem hiding this comment.
The doc warns against using open_browser_url as a “standard browser subagent tool”, but open_browser_url isn’t referenced anywhere else in this repo (search only finds it here), so readers won’t know what tool this refers to. Consider either removing this specific tool name or replacing it with the actual tool/command names used in this repository for browser automation (e.g., the browser / playwright-mcp skill tools).
| - **Avoid Subagent Tools Defaults**: Do not use standard browser subagent tools (`open_browser_url`, browser recording) as the default path, as they may fail or lose context. | |
| - **Avoid Subagent Tools Defaults**: Do not use standard browser subagent tools (such as generic "open URL in browser" helpers or browser recording tools) as the default path, as they may fail or lose context. |
| Once checked, Chrome exposes the CDP port at `127.0.0.1:9222`. | ||
|
|
There was a problem hiding this comment.
Enabling Chrome remote debugging effectively grants full control of the user’s browser profile; this section should include a security warning to ensure the debugging endpoint is bound to localhost only and never exposed to untrusted networks. It may also help to add a quick verification step (e.g., checking the DevTools endpoint is reachable on 127.0.0.1:9222) and note that the port/address can be configured.
| Once checked, Chrome exposes the CDP port at `127.0.0.1:9222`. | |
| > **Security warning** | |
| > Enabling remote debugging gives full control over your browser profile (tabs, cookies, session, filesystem access via downloads, etc.). | |
| > **Never** expose the Chrome DevTools / CDP endpoint to untrusted networks. It should be bound only to `127.0.0.1` (localhost), not `0.0.0.0`, and must not be forwarded over public tunnels, exposed via router port‑forwarding, or shared across multi‑user systems. | |
| By default, once checked, Chrome exposes the CDP port at `127.0.0.1:9222` for this browser instance. | |
| **Verify the endpoint is local-only:** | |
| - In the same machine’s browser, open `http://127.0.0.1:9222/json/version` (or `http://127.0.0.1:9222/`). You should see a small JSON document or DevTools listing. | |
| - From any other machine on your network, this URL **should not** be reachable. If it is, disable remote debugging and review your Chrome launch parameters and network/firewall configuration. | |
| **Configurable address/port:** | |
| Advanced users can configure the debugging address and port when launching Chrome (for example using flags such as `--remote-debugging-port=9222` and, if supported, `--remote-debugging-address=127.0.0.1`). This skill assumes the default local endpoint `http://127.0.0.1:9222` and should never be used with a debugging endpoint bound to a public interface. |
This PR adds a skill for natively taking over a user's running Chrome browser via CDP port 9222 without losing session state. Original repo: https://github.com/Zhihong-KE/browser-cdp-takeover