Playwriter: running Playwright snippets against the Chrome you already have open

The problem is authentication, not browser control

Most browser automation starts from a blank profile. The README puts the contrast bluntly: other browser MCPs "spawn a fresh Chrome", which means no logins, no extensions, and a browser that bot detectors can spot immediately. Playwriter's answer is to skip the spawn entirely and attach to the Chrome you already have running. That single decision determines everything else about the project. If your automation target sits behind a login you cannot script, or depends on a browser extension you installed for personal use, the attach model removes an entire class of setup work. If your target is a public page you can hit with a fresh context, the attach model buys you nothing and costs you isolation. The intended user is therefore narrower than the tagline suggests: someone automating their own authenticated session, typically on a developer machine, not someone building a test suite that has to run the same way on every machine.

Sessions, shared tabs, and where state actually lives

Playwriter separates two things that are easy to conflate. A session is a stateful sandbox with isolated state, created by `playwriter session new`, which prints an id such as `1`. Browser tabs are shared across sessions. So two sessions can hold different variables while looking at the same tab, and the README warns about exactly this: create your own page with `state.myPage = await context.newPage()` to avoid interference from other agents. The variables in scope for each `-e` call are `page`, `context`, `state`, `require`, `importModule`, native `import()`, and Node.js globals, with relative imports resolving from the session working directory. The `state` object is what makes the model usable across invocations: the README's network interception example assigns `state.requests = []`, registers a `page.on('response', ...)` handler, and then reads `state.requests` in a later command. That is a REPL with a lifetime, not a script runner. It is also the design's main hazard. A handler registered in one command keeps firing in later ones, and nothing in the documented command set appears to enumerate or tear down individual handlers, only `playwriter session reset <id>` to clear the whole sandbox.

Getting it running: extension first, then CLI, then skill

The install order matters. First the Chrome extension from the Web Store, then clicking the extension icon on a tab, which turns green when connected. Only then the CLI: `npm i -g playwriter`, followed by `playwriter -s 1 -e 'await page.goto("https://example.com")'`. The `-s 1` flag selects the session and the README says to always use it. There is a second path that does not require a pre-existing Chrome: `playwriter browser start` launches Chrome for Testing or Chromium with the bundled Playwriter extension, and accepts an explicit binary path as an argument. From there the loop is `playwriter session new`, then repeated `-e` calls, with `playwriter session list` to show sessions and their state keys. One quoting rule is easy to get wrong: use single quotes for `-e` so bash does not interpret `$`, backticks or backslashes in the JavaScript, and double quotes for strings inside it. Multiline input uses `-e $'...'`. For agent use the README recommends the CLI plus a skill installed via `npx -y skills add https://playwriter.dev`, with direct MCP server configuration deferred to a separate MCP.md file rather than documented in the README itself.

The extension is a capability boundary as well as a connector

Playwriter's comparison tables list bot detection bypass twice, in the Playwright MCP and Playwright CLI columns, with the mechanism given as disconnecting the extension. Read that against the installation instructions and a tension appears. The extension is what connects the CLI to your browser; disconnecting it is also what changes the automation's fingerprint. The README does not explain what remains functional after disconnection, whether existing sessions survive it, or how to reconnect cleanly. Treat this as the least specified part of the project. The same caution applies to the CDP features. `getCDPSession({ page })` feeds `createDebugger({ cdp })` for breakpoints and `createEditor({ cdp })` for live-editing page source, which are genuinely beyond what a normal Playwright wrapper exposes, but they are documented as three-line snippets with no discussion of what happens when the target page navigates mid-session or the source map does not match the served file.

The performance claims in the README are not substantiated

The README states that Playwriter video recording is "100x more efficient than Playwright video recording", attributing the difference to Playwright sending base64 images for every frame, and the comparison table lists native tab capture at 30 to 60fps against file-based tracing. No methodology, hardware, resolution or measurement is given, and I have not run either tool to check. The architectural argument is plausible on its face: base64-encoding frames into a stream is wasteful compared to capturing a tab. The multiplier is not something a reader should carry into a decision. The same applies to the comparison tables generally. They are the project's own framing of its competitors, not independent measurements, and the BrowserMCP row in particular reduces that project to a tool count and a context-usage claim. The one comparison worth taking seriously is structural rather than numeric: Playwriter exposes a single `execute` tool that runs JavaScript, while tool-per-action servers expose a schema the model has to learn. That is a real difference in how an agent is prompted, and it cuts both ways, as the next section explains.

One execute tool is a strength for strong models and a trap for weak ones

The README frames the single-tool design as low context usage and no learning curve, on the grounds that the model already knows Playwright. For a capable coding model with a real tool-use loop, that is close to correct: arbitrary Playwright is a larger action space than twelve fixed tools, and `require` plus `importModule` plus native `import()` means the executed snippet can pull in npm packages. For a weaker model, or one running without the skill installed, the same design removes the guardrails. A tool schema constrains what the model can attempt; a JavaScript sandbox does not. There is no documented validation layer, dry-run mode or allowlist between the agent and the executed code. The README's own examples include live-editing a page's JavaScript source and opening a raw CDP session. Anyone wiring an agent to this should assume the agent can do anything the Node process can do, because the documented surface offers nothing that says otherwise.

What you give up, and what to use instead

The clearest alternative is Playwright itself, driven normally. The difference is not capability, since Playwriter's own table concedes the underlying API is the same. It is lifecycle. A normal Playwright script creates a browser, a context and a page, runs, and tears everything down, so two runs cannot contaminate each other and a failure is reproducible from the script alone. Playwriter inverts that: the browser outlives the process, tabs are shared between sessions, and state persists until you reset it. That is the feature when your target is an authenticated session on your own machine, and the defect when you need a clean room. A second alternative is a tool-per-action browser MCP server, which trades expressiveness for a constrained, inspectable action set; if your agent cannot reliably write JavaScript, that constraint is worth more than the extra reach. A third is Playwright's own storage-state mechanism, which exports cookies and local storage from one authenticated run and injects them into a fresh context. That keeps isolation while carrying the login forward, and it is the option to weigh first if your only reason for attaching to a live browser is authentication.

Licence, maintenance and what a version bump costs you

The repository is MIT licensed, which permits commercial use, modification and redistribution provided the copyright notice and permission notice are retained. That is a permissive grant and I am not going to read more into it than that; if you redistribute Playwriter inside a product, have someone check the notice requirements rather than taking this paragraph as advice. On maintenance, the material shows two release lines moving in parallel: the CLI at playwriter@0.5.0 and the extension at 0.0.118, both dated 2026-08-23, with playwriter@0.4.0 roughly two months earlier. The version numbers tell you something practical. The extension is still on a 0.0.x line, so it should be treated as fast-moving, and the CLI and extension are versioned separately, which means an upgrade on one side can outpace the other. Before upgrading either, check that the CLI version you install matches what the installed extension expects, and keep `playwriter session reset <id>` in mind as the documented recovery step for connection issues. There is no documented compatibility matrix in the README, so that check is on you.

Editorial conclusion

Adopt Playwriter if your automation has to run inside an authenticated session you cannot reproduce from scratch, and if you are comfortable giving a long-lived Node process the ability to execute arbitrary Playwright code against your own browser profile. Do not adopt it if you need reproducible, isolated CI runs, per-test browser contexts, or a stable tool schema for an agent that cannot write JavaScript. Before committing, verify three things yourself: that the extension connects on the Chrome build you actually use, that `playwriter session reset <id>` recovers the failure mode you hit, and that the session working directory resolves your relative imports the way you expect.

Official sources

1. License: MIT
2. Project website
3. README
4. Releases
5. remorses/playwriter on GitHub