---
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.**

<Image
  src='/chrome-cdp-dialog.jpg'
  alt='Chrome "Allow remote debugging?" permission dialog'
  width={650}
  height={360}
/>

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.
