Chrome DevTools Protocol (CDP)

#How CDP works

A client opens a WebSocket connection to a browser that has remote debugging turned on. It sends JSON messages that name a method and pass parameters, such as enabling a domain or navigating to a page. The browser returns a result for each command and sends events when something happens, such as a network request finishing.

The domains split the protocol by area. Page covers navigation and screenshots. Network covers requests, responses and cookies. DOM covers the document tree.

#Why it matters for AI agents

Most browser automation runs on CDP. Puppeteer uses it directly, and Playwright uses it for Chromium. Agent frameworks use the same channel to read the page, record network traffic and click elements.

CDP is powerful, so anything connected to it can read what the browser can read. The Network domain can return cookies, including HTTP-only cookies. A debugging port should only be opened on a browser that you control.

#In practice with AI agents

An agent that drives Chrome through CDP sees what the browser sees: page content, network calls and, in some cases, cookies. Treat a tool with that access as having the same access as the user's browser session. Ask whether the tool needs that access before you connect it.

#Related terms

• Headless browser
• Browser agent
• Manifest V3
• HAR file

#FAQ

#Is CDP the same as WebDriver?

No. Both let a program drive a browser. WebDriver is a W3C standard that works across browsers. CDP is specific to Chromium-based browsers and exposes lower-level features, such as detailed network events.

#Can CDP see HTTP-only cookies?

Yes. A client connected through CDP can ask the Network domain for cookies, and that includes cookies marked HTTP-only. This is one reason a remote debugging port is sensitive.