CDP Protocol
Chrome DevTools Protocol client in Rust, with first-class Node, Deno and Bun bindings.
A WebSocket-based CDP client for browser automation, scraping, and testing. The entire protocol — 664 commands, 233 events, 608 types — is generated from the published schema as typed Rust structs, with napi-rs bindings exposing the same API to JavaScript.
Start Chrome with remote debugging
google-chrome --headless=new --remote-debugging-port=9222 --no-first-runGenerated, not hand-written
The Chrome DevTools Protocol is large and moves with Chrome. Hand-maintaining bindings for it is a losing position, so the types here are generated by an xtask from vendored protocol schemas.
That yields complete coverage — all 664 commands, 233 events, and 608 types — as typed structs rather than the stringly-typed JSON most CDP wrappers settle for.
Sessions
One connection reaches other tabs, iframes, and workers through CDP sessions, which is what makes the client usable for real automation rather than single-page scripts.
Two crates, one API
`cdp-protocol` is the Rust engine, exposing `CdpClient`, `BrowserAgent`, and `Cluster`, and ships to crates.io.
`cdp-protocol-node` is a native addon built with napi-rs that exposes the same three classes to JavaScript with Promises and TypeScript types, published to npm and usable from Node, Deno, and Bun.
Why CDP over WebDriver
CDP and WebDriver solve overlapping problems with different trade-offs — the protocol surface, the event model, and the latency profile all differ.
That comparison is written up separately in a deep dive on dev.to rather than restated here.