> Agent-readable docs index: /llms.txt. Download /docs.zip to grep all markdown files locally. --- title: Playwriter vs Chrome Direct CDP sidebarTitle: vs Chrome Direct CDP description: Why Chrome's built-in CDP remote debugging is impractical for agents, and how Playwriter solves it. icon: lucide:shield-alert --- Chrome has a built-in remote debugging mode that exposes the Chrome DevTools Protocol (CDP) over a WebSocket. You can launch Chrome with `--remote-debugging-port=9222` or enable it at `chrome://inspect/#remote-debugging`. This is what most automation tools use under the hood. The problem: **Chrome now shows a permission dialog every time an external app tries to connect.** Chrome "Allow remote debugging?" permission dialog The dialog says "An external app wants full control over this Chrome session to debug it" and requires the user to click **Allow** before any automation can start. The Cancel button is visually highlighted as the recommended action. This is by design; Chrome wants to prevent background processes from silently hijacking browser sessions. This single dialog **breaks every autonomous agent use case.** An agent can't click Allow on its own. The user must be present, watching, and ready to click every time the agent reconnects. If Chrome restarts, the dialog appears again. If the connection drops, the dialog appears again. ## How Playwriter avoids the dialog Playwriter uses a Chrome extension with `chrome.debugger` permissions instead of external CDP connections. The extension runs **inside Chrome**, so it never triggers the remote debugging permission dialog. The user clicks the extension icon once on a tab, and the agent has full CDP access from that point forward. No flags, no Chrome restart, no recurring permission prompts. ## Comparison | | Chrome Direct CDP | Playwriter | | --------------------- | ------------------------------- | ------------------------ | | Permission dialog | Every connection | Never | | Autonomous agents | Blocked by dialog | Works unattended | | Chrome restart needed | Yes (`--remote-debugging-port`) | No | | Login state | Depends on profile flags | Already logged in | | User intervention | Required every reconnect | One-time extension click | | Extensions available | Yes | Yes | | Full CDP access | Yes | Yes | ## Chrome Direct CDP setup To use Chrome's built-in CDP, you need to either: 1. **Launch Chrome with a flag:** `chrome --remote-debugging-port=9222` 2. **Enable in settings:** navigate to `chrome://inspect/#remote-debugging` Both approaches expose a WebSocket endpoint that automation tools can connect to. But the moment any tool connects, Chrome shows the "Allow remote debugging?" dialog. With Playwriter's `--direct` mode, you can still use Chrome's built-in CDP when you need it (for example, to access all open tabs at once). But for most agent workflows, the extension mode is better because it avoids the dialog entirely. ```bash # Extension mode (recommended): no dialog, no flags playwriter session new playwriter -s 1 -e "page.goto('https://example.com')" # Direct mode: uses built-in CDP, dialog appears once playwriter session new --direct playwriter -s 1 -e "page.goto('https://example.com')" ``` ## Why this matters for agents AI agents need to operate **without human babysitting.** A permission dialog that requires a click defeats the purpose. The agent can't proceed until someone is there to approve it, and there's no API to auto-accept the dialog. With Playwriter, the user enables the extension on the tabs they want controlled, then walks away. The agent can reconnect, navigate, and automate freely. If Chrome restarts, the extension reconnects automatically when the user opens Chrome again. No dialog, no flags, no friction.