How to Automate Browser Tasks With Claude Code

TL;DR

Connect Playwright CLI to Claude Code to create repeatable browser automations for testing websites, collecting public contact details, and operating logged-in sessions. The demonstrated workflow generates scripts, runs browser actions, captures screenshots, identifies failures, modifies the application, and retests until the QA process passes, with scheduled tasks providing a path toward autonomous execution.

Transcript

So, when you give a tool as powerful as Cloud Code access to literally control a browser, if you think about it, you can actually automate anything. Whether that's stress testing an app, downloading reports, or even playing a game like you guys saw in my other video. So, today I walk through three use cases that you can use when you connect Playrig... Read More

Key Insights

• Playwright CLI gives Claude Code the ability to open pages, interact with browser interfaces, and capture screenshots through generated scripts. The initial setup was verified when an automatically created demonstration opened a page and saved a screenshot in a fresh project.
• Playwright CLI was chosen after experimenting with Chrome DevTools because the Chrome DevTools MCP consumed many context tokens through its numerous tools and tool descriptions. The CLI approach still provided effective browser automation while supporting scripts that could be saved and reused.
• Browser automation becomes repeatable when generated scripts are paired with a skill. A QA skill could run a browser bot, interpret its feedback, change the application, and execute the bot again as a consistent process rather than requiring every individual action to be prompted manually.
• The onboarding application contained 12 questions presented one page at a time. It included personal and business fields, a progress indicator, drop-down selections, a review stage, and navigation behavior, giving the automated QA process multiple interface elements and workflows to test.
• Headed and headless browser modes support different observation needs. A headed run displays the browser so a person can watch fields being filled and pages changing, while a headless run performs the same type of automated interaction without displaying the browser window onscreen.
• The first QA run found that pressing Enter in the notes textarea did not advance to the review stage. It also found that the review page failed to load, produced zero review items, and left an edit button obstructed by a stale page overlay.
• The automated repair loop used evidence from the failed run, including screenshots, to identify and fix website problems. Claude Code then restarted the server and reran the test, which completed successfully and ended after validation confirmed that the workflow passed.
• The demonstrated use cases extend beyond software testing to searching for dentist offices, collecting contact information, controlling authenticated school-account sessions, and chaining scripts into scheduled tasks. The description also identifies downloading reports from websites without APIs as another potential browser-automation application.

Questions & Answers

Q: How do you connect Playwright CLI to Claude Code?

Start with a fresh Claude Code project and ask Claude Code to plan how to install Playwright CLI for browser automation. In the demonstration, Claude Code initialized the project, installed Playwright, created a sample script, opened a page, and saved a screenshot. That screenshot provided a practical confirmation that the installation and browser-control workflow were functioning correctly.

Q: Why use Playwright CLI instead of Chrome DevTools MCP?

Playwright CLI was selected after experimenting with Chrome DevTools because the Chrome DevTools MCP occupied many context tokens. Its numerous tools each included descriptions, increasing context usage. The Playwright CLI approach worked well for the demonstrated tasks and allowed Claude Code to generate custom browser scripts for screenshots, interface testing, search workflows, and other repeatable automations.

Q: How can Claude Code automatically test and fix a web app?

Claude Code can generate a Playwright QA script that starts the application server, opens the site, fills fields, selects options, navigates between pages, and captures screenshots. After a run, it can inspect failures, modify the application code, restart the server, and execute the test again. The demonstrated second run completed successfully after the identified bugs were repaired.

Q: What bugs did the automated QA test discover?

The first automated QA pass found several connected problems in the onboarding form. Pressing Enter while using the notes textarea did not advance to the review stage, the review page never loaded, the test found zero review items, and an edit button was intercepted by a stale page overlay. Claude Code used these findings to repair the site and retest it.

Q: What is the difference between headed and headless browser automation?

A headed browser displays its window during automation, allowing a person to watch the script type values, choose options, and move through pages. A headless browser performs automated actions without showing the browser onscreen. The QA demonstration specifically requested headed mode so the form-completion process and its temporary difficulties could be observed while the test was running.

Q: How can browser automation become a reusable Claude Code skill?

A generated browser script can be combined with a skill that defines a consistent process. For website QA, that process can run the bot, collect its feedback, update the application, and run the bot again. Packaging these steps together turns a one-time script into a repeatable workflow that can execute the same testing and validation sequence whenever QA is needed.

Q: Can Claude Code automate tasks inside logged-in browser sessions?

The provided description says browser automation can operate inside logged-in sessions and identifies a school account on Skool as the demonstration. This extends the workflow beyond public pages because actions can occur within an existing authenticated session. The source does not provide complete step-by-step authentication instructions, but it explicitly presents logged-in browser control as one of the three use cases.

Q: What browser tasks can Claude Code and Playwright automate?

The demonstrated and proposed tasks include testing a web application, capturing screenshots, finding and fixing interface bugs, searching for dentist offices, collecting contact details, downloading reports from sites without APIs, and operating within logged-in sessions. The description also says generated scripts can be chained into scheduled tasks so an agent can run established browser workflows on its own.

Summary & Key Takeaways

• Playwright CLI can give Claude Code direct browser-control capabilities without relying on a large collection of MCP tool descriptions. The setup begins in an empty project, where Claude Code plans the installation, initializes Playwright, creates a demonstration script, opens a page, and captures a screenshot to confirm that browser automation works.

• The main demonstration builds a polished onboarding website containing 12 questions, with one question displayed per page. Claude Code then creates a Playwright QA script, launches a headed browser, completes the form, captures screenshots, and discovers problems involving textarea navigation, the missing review page, empty review items, and a stale overlay.

• Claude Code uses the QA findings to modify the website and rerun the automated test without requiring another detailed instruction. The second test completes successfully, illustrating a repeatable test, validate, fix, and retest workflow. Additional examples cover collecting dentist contact information, using logged-in sessions, and chaining browser scripts into scheduled tasks.