Rustwright: A native Rust CDP engine that replaces Playwright's Node driver

What Rustwright replaces and who it targets

Rustwright solves a specific operational problem: the Playwright Python and Node libraries launch a separate Node.js driver subprocess that communicates with the browser over a pipe. That driver is a moving part that consumes memory, adds startup latency, and leaves automation fingerprints. Rustwright removes that subprocess entirely. Your Python or Node code talks directly to Chromium over raw Chrome DevTools Protocol (CDP) through a native Rust core. The target audience is developers who already know the Playwright API and want the same ergonomics without the Node runtime in the path. The README also positions it for AI agent workloads: the companion CLI and MCP server give agents a browser through compact accessibility snapshots with element references like @e1, instead of raw HTML or screenshots. This is an alpha project, so the primary audience is early adopters and teams building agent tooling, not teams looking for a drop-in production replacement.

Architecture: one Rust core, two thin bindings

The architecture is simple on purpose. One Rust core implements an async CDP client built on Tokio, using WebSocket by default with an opt-in Unix-pipe transport. That core talks directly to Chromium. On top of it sit two thin bindings: PyO3 for Python and napi-rs for Node. Both expose the same Rust core in-process, so there is no separate driver process. The README's diagram makes the difference clear: playwright-python routes your code through a pipe to a Node driver, then to CDP, then to Chromium. Rustwright skips the middle step. This design is the source of the claimed performance benefits: 2.55x faster and 70% less memory, according to the README's benchmarks. Those numbers come from the project's own benchmark files, and you should treat them as vendor claims until you reproduce them. The trade-off is that every CDP feature must be implemented in Rust, which is a large surface area. The fact that the project is alpha and only supports a subset of the Playwright API reflects that burden.

Installation and the one-line import swap

Getting started is straightforward for Python. You run pip install rustwright, then python -m rustwright install chromium to fetch a browser. After that, you change one import line: from rustwright.sync_api import sync_playwright instead of from playwright.sync_api import sync_playwright. The rest of your Playwright code, such as browser.launch(headless=True) and page.goto, stays the same. For Node, the situation is more experimental. You install the npm package, but the binding expects an existing Chromium or Chrome binary, which you point to via the RUSTWRIGHT_CHROMIUM, CHROME, or CHROMIUM environment variables. Alternatively, you can clone the repo and run npm install && npm run build in the node/ directory. The CLI installs via a curl pipe to a shell script, which is a trust decision you should make consciously. The MCP server installs with cargo install --git https://github.com/Skyvern-AI/rustwright rustwright-mcp. The README notes that an npm package for the MCP server is on the way, but not yet shipped. For a quickstart example in Node, the README points to examples/quickstart.js, which you run from the repository root after building.

Input handling and the no-fingerprint claim

One of Rustwright's distinctive choices is how it handles user input. Clicks and typing go through real CDP input events, specifically Input.dispatchMouseEvent, rather than synthetic DOM calls like element.click(). The README calls this 'trusted input by default' and says untrusted DOM shortcuts are opt-in only. This matters for sites that detect synthetic events, and it also feeds into the project's claim of having no Playwright automation fingerprint. Because the Node driver never loads, its signatures never appear in the browser. That is a plausible claim, but it is not a guarantee of stealth. Sites can still detect automation through other signals, such as CDP usage itself or browser flags. The README is careful to say 'no Playwright automation fingerprint,' not 'undetectable.' The input approach is a genuine differentiator from Playwright, which historically used synthetic events in some paths. But it also means that Rustwright's behavior may differ from Playwright in edge cases where DOM events have side effects that CDP input events do not trigger.

Agent tooling: CLI, snapshots, and MCP server

Rustwright is not just a library. The repository includes a CLI and an MCP server aimed at AI agents. The CLI, rustwright-cli, opens a persistent Chromium session and lets you drive it from a shell. You run rustwright-cli open https://example.com, then rustwright-cli snapshot to get a compact page tree with element references like @e1, then rustwright-cli click @e1 to act on an element. The refs are session-scoped and never reused, which is a nice touch for agent loops that need stable handles. The README explicitly says these refs are best-effort and not a security boundary, so you should not rely on them for access control. The MCP server, rustwright-mcp, is a native Rust binary that exposes browser_* tools over stdio to any MCP client. It requires no Python or Node runtime in the serving path, which is consistent with the project's no-subprocess philosophy. You can wire it into Claude Code with claude mcp add rustwright -- rustwright-mcp, or into any MCP client by specifying the command in a JSON config. For agent use, the snapshot approach is more compact than raw HTML and avoids the cost of screenshots, though inline PNG screenshots are also supported.

Limitations: Chromium only, partial API, alpha status

The most obvious limitation is browser support. Rustwright is Chromium-only. Playwright supports Firefox and WebKit, and Rustwright does not. If you need cross-browser testing, this is not the tool. The second limitation is API coverage. The README says 'only a subset of the API surface is bridged' and points to a Limitations section. That means your existing Playwright code may not run unchanged beyond the basic navigation and click examples. The Node binding is explicitly experimental, and the Python binding is alpha. There are no recent releases listed, which means you are likely working with git snapshots or early package versions. The README also notes that CPython 3.15 support is verified on a release candidate and remains pre-release, with CI tracking the dev branch. That is a warning for anyone on the latest Python. Finally, the project is maintained by Skyvern-AI, a company known for AI agents, so the focus is clearly on agent automation rather than general-purpose testing. If you need a stable, full-featured automation library for CI pipelines, Rustwright is not there yet.

Alternatives: Playwright itself and the trade-off

The obvious alternative is Playwright itself, since Rustwright is an interoperable reimplementation. Playwright uses a Node driver subprocess, which is exactly what Rustwright removes. That driver is the source of the fingerprint and the memory overhead. But Playwright has years of maturity, a full API surface, and support for three browsers. If you are on Python, the official Playwright package is stable and well-documented. The trade-off is clear: you keep the Node driver and its fingerprints, but you get a complete, battle-tested tool. Another alternative is Selenium, which uses a WebDriver wire protocol and a separate driver per browser, but Selenium is not API-compatible with Playwright, so switching would require rewriting your automation code. Rustwright's value proposition is that you keep your Playwright code and lose the driver. That is compelling for agent workloads where fingerprint avoidance and memory matter, but it is a bet on an alpha project. For most production testing needs, the safer choice is still Playwright.

Maintenance and licensing considerations

The project is MIT-licensed, which is permissive and should not block adoption for commercial use. However, the maintenance picture is thin. There are no recent releases listed, and the project is alpha. The README mentions a Discord server and a test.yml GitHub Action, which suggests active development, but you cannot verify release cadence from the material. The Rust core is a significant piece of code, and the project depends on Tokio, PyO3, and napi-rs. Upgrading those dependencies or keeping pace with Chromium's CDP changes will be an ongoing cost. Because the API is a subset, you may need to contribute missing features yourself or wait for the maintainers. The Node binding is experimental, so expect breakage. The MCP package is not yet on npm, so the only install path is from source via cargo, which requires a Rust toolchain. If you adopt Rustwright, budget time for upstream fixes and pin your dependencies. The license is friendly, but the maintenance risk is real for a project at this stage.

Editorial conclusion

Adopt Rustwright if you need Playwright-style automation in Python or Node but want to drop the Node driver subprocess, especially for AI agent loops that benefit from the CLI and MCP server. Do not adopt it for production yet if you rely on the full Playwright API surface, Firefox or WebKit support, or stable releases. Before adopting, verify that your specific Playwright calls are covered by the bridged subset, confirm CPython 3.15 compatibility in your environment, and check the current state of the Node binding, which is experimental and may require building from source.

Official sources

1. Official README
2. Project repository