Claude Code + Playwright CLI: The Best Way to Automate Your Browser

Playwright CLI is the most efficient way to do browser automation inside Claude Code — and it's not even close. It uses a fraction of the tokens compared to the MCP server or Claude's Chrome extension, it runs headless, and it can run multiple browser sessions in parallel. I've been using it to test form submissions on my own site by spinning up three parallel sub-agents that each attack the UI from different angles — edge cases, validation, happy path — all without touching a single browser tab myself.

Here's exactly how it works, how to set it up, and how to turn it into a repeatable workflow.

What Is Playwright CLI and Why Should You Care?

Playwright CLI (@playwright/cli) is a command-line interface built by Microsoft specifically for AI coding agents to control browsers. It's open source, free, and designed from the ground up to be token-efficient. Playwright itself has been around for a while as a web testing and automation framework, but the CLI is a relatively new addition — it dropped just a few weeks ago.

The key difference between the CLI and older approaches (like the Playwright MCP server or Claude's Chrome extension) is how it handles information. Instead of dumping massive amounts of browser data directly into Claude Code's context window, the CLI saves that data to your local disk and only passes a lightweight summary to the model.

This matters because token usage directly impacts speed, cost, and how much Claude Code can actually reason about. In comparisons between the CLI and the MCP server, the token difference for the same task can be roughly 90,000 tokens. That's enormous. It's the difference between Claude Code having room to think and Claude Code being jammed full of accessibility tree data it doesn't need.

How Does Playwright CLI Compare to the MCP Server and Chrome Extension?

There are three ways to do browser automation with Claude Code right now. Here's how they stack up:

Playwright CLI: Lowest token usage by far. Supports headless and headed browsers. Can run in parallel. Full Playwright capabilities.
Playwright MCP Server: Decent capability, supports headless and parallel, but extremely token-heavy because it dumps the entire accessibility tree into the context window every interaction.
Claude Code Chrome Extension: Takes screenshots of your web page to understand what's happening. Very costly on tokens. Not headless. Cannot run in parallel. Probably the worst option for automated testing workflows.

The choice here is obvious. The CLI does everything the MCP server can do and more, at a significantly lower token cost. The Chrome extension has its uses for quick personal automation, but for any kind of structured testing or repeated workflow, the CLI wins.

Why Is the Playwright CLI So Much More Token-Efficient?

This is actually a cool technical detail worth understanding. All three approaches use something called an accessibility tree — the underlying structure of a web page that maps every element in a way that assistive technologies (like screen readers) can understand. Think about how a blind person navigates a website. That entire structure — buttons, inputs, labels, headings — that's the accessibility tree.

Playwright uses this tree to understand and interact with web pages. Here's where the approaches diverge:

The MCP server takes the entire accessibility tree and shoves it into Claude Code's context window. Every single time. These trees can be massive — articles have documented MCP dumping over 100,000 tokens for a single page snapshot.
The CLI gets that same accessibility tree but saves it to your local disk. Then it passes just a compressed summary — element references like e15: [Button] "Submit" — to Claude Code. The agent uses those references to act. Way less data in the context window.

It's essentially a "pay-as-you-go" model for the CLI versus an "all-you-can-eat buffet whether you're hungry or not" model for MCP. The result is that the CLI can save upwards of 18% more context window space, which means Claude Code has more room to actually reason about your task instead of being bogged down by raw page data.

How Do You Install Playwright CLI for Claude Code?

Setup is straightforward. You need three things:

Install the Playwright CLI globally:
```
npm install -g @playwright/cli
```
Install the browser engine:
```
npx playwright install chromium
```
(If you want a different browser, just check the Playwright docs or ask Claude Code for the command.)
Install the Claude Code skill:
```
playwright-cli install --skills
```

That last step installs the skill that Microsoft built — it's essentially an instruction file that tells Claude Code how to use the Playwright CLI properly. You can find it on the Microsoft Playwright CLI GitHub repo.

Alternatively, you can skip the manual steps entirely. Just open Claude Code, give it the GitHub repo URL, and say "install everything I need." It'll handle it.

One thing to know: the skill Microsoft provides is a starting point, not gospel. You can edit it, audit it with the skill creator tool, or build your own from scratch. It's a living document.

What Can You Actually Do With Playwright CLI in Claude Code?

The capability list is broad. Anything that requires interacting with a browser is fair game:

UI testing — form submissions, validation checks, edge cases, happy paths
Screenshot capture — get visual proof of page states
Data extraction — scrape dynamic, JavaScript-heavy sites
Form filling — automate repetitive data entry
Session management — log in, persist cookies, maintain state across pages
Multi-tab handling — run multiple browser contexts simultaneously
PDF generation — capture pages as PDFs

I've been primarily using it for UI testing on my own projects, which is probably the most immediately practical use case for most people. But you could literally have it go shop on Amazon for you — it has the ability to log in, maintain sessions, and navigate complex flows.

My recommendation: one of the first things you do after installing is have a conversation with Claude Code asking "What can you do with the Playwright CLI skill?" Walk through some theoretical use cases. The waters here are deep.

How Do You Run a Browser Test With Playwright CLI?

This is the easy part. You just talk to Claude Code in plain language.

For a single headed browser test (meaning you can actually see the browser open), I said:

"Can you use the Playwright CLI tool to test the form submission? Make it a single agent and make it headed so I can see it."

That's it. Claude Code loaded the skill, checked the project structure, opened the page, scrolled to the form, started filling in fields, checked boxes, and submitted. When it finished, it automatically closed the browser and gave me the test results plus screenshots.

Important note: by default, Playwright CLI runs headless — meaning the browser operates in the background and you won't see anything. If you want to watch it work, you need to explicitly say "make it headed." Otherwise, it just runs invisibly and reports back.

For the multi-agent approach I showed in the demo, the prompt was essentially:

"I want to run three parallel agents. I want you to attack the form from different angles — edge cases, validation, and the happy path. Make them headed."

Three sub-agents spawned. Each ran their own browser instance. Each tested from a different angle. All simultaneously. Think about how long that would take you manually — spinning up the dev server, going through each test scenario one by one, checking every field. Now it's a two-sentence prompt.

How Do You Turn a Playwright Workflow Into a Reusable Skill?

This is where things go from cool to actually transformative for your productivity. Running that three-agent parallel test once is great. But if you're making frequent changes to your site and need to re-run the test every time? You don't want to type out the full instructions each time.

The move is to package the workflow into its own skill. Here's how I did it:

Nail down the workflow first. Run it a few times with plain language. Get specific about what you want — three parallel agents, what each one tests, headed vs headless, what gets reported back. Make it so Claude Code can't mess it up.
Use the skill creator tool. In Claude Code, just type skill creator and say something like: "I want to turn this following workflow process into its own meta skill" — then paste in your finalized workflow description.
Name and save it. In my case, it created a "form tester" skill. Now instead of describing the whole process, I just say "use the form tester skill" and three parallel agents spawn exactly like the demo.
Iterate on it. Because you used the skill creator, you can run tests, send it through evaluation, and refine it over time.

This is the headspace you should be in with any Claude Code workflow: can I standardize this? And if I can standardize it, can I turn it into a skill? That's how you go from using AI as a tool to building actual automated systems.

What Are the Best Practices for Playwright CLI in Claude Code?

After running this across my own projects, here's what I've found works best:

Start headed, then go headless. Watch the first few runs so you understand what Claude Code is doing. Once you trust the workflow, switch to headless for efficiency.
Use parallel agents for testing, not for complex sequential flows. Parallel is great when each agent is doing an independent task. If steps depend on each other, keep it single-threaded.
Ask Claude Code for testing strategy. I didn't know the best way to stress-test my form. It did. Just ask "What's the best way to test this?" and let it suggest the approach.
Your local projects have an advantage. When you're testing your own codebase, Claude Code has full visibility into how your pages are structured. This means fewer accessibility tree issues and more accurate tests compared to testing external sites.
Package repeated workflows into skills immediately. Don't wait until you've typed the same prompt 10 times. If you run something twice, make it a skill.

FAQ

Do I need to know how to code to use Playwright CLI with Claude Code?

No. The entire point is that Claude Code abstracts the technical complexity away. You interact in plain language — "test my form submission with three parallel agents" — and Claude Code handles the Playwright commands, the browser control, everything. Having some technical understanding helps you get more out of it, but it's not a prerequisite.

Is Playwright CLI free to use?

Yes. Playwright is an open-source Microsoft project, and the CLI is completely free. You do need Node.js 18 or newer installed, and obviously you need a Claude Code subscription, but the Playwright tooling itself costs nothing.

Can Playwright CLI interact with sites that require login?

Yes. Playwright CLI supports session persistence and cookie management, so you can log into a site and maintain that authenticated state across multiple actions. This opens up automation for dashboards, admin panels, e-commerce flows, and anything else behind a login wall.

What's the difference between a headed and headless browser?

A headed browser is one you can actually see — it opens a window on your desktop and you can watch it work. A headless browser runs in the background with no visible window. Headless is more efficient and less resource-intensive, which is why Playwright CLI defaults to it. Use headed when you want to watch and debug; use headless for production workflows.

Can I use Playwright CLI with other AI coding agents besides Claude Code?

Yes. The Playwright CLI was designed to work with any AI coding agent that can execute CLI commands, including GitHub Copilot and Cursor. The skill system and installation process may differ slightly, but the core CLI functionality is agent-agnostic.

If you want to go deeper into Claude Code and browser automation workflows, join the free Chase AI community for templates, prompts, and live breakdowns. And if you're serious about building with AI, check out the paid community, Chase AI+, for hands-on guidance on how to make money with AI.

Claude Code + Playwright CLI: Browser Automation Guide