Giving Claude Code Eyes with Playwright MCP

One of the most frustrating parts of building frontends with AI coding tools in WSL is that the AI can’t see what you’re looking at. I can open Chrome on the Windows side and view my dev server just fine, but Claude Code, running in WSL, has no way to access that browser. It can’t see the page, inspect the DOM, or interact with anything on screen. So whenever something doesn’t look right, I become the middleman: I look at the browser, try to describe the issue in words, and hope my description is precise enough for Claude to act on.

That workflow is slow, imprecise, and breaks the momentum of working with an AI that can otherwise move incredibly fast. Chrome on Windows doesn’t have a native integration path that Claude Code on WSL can use. But Playwright’s Chromium does. It runs directly in the same Linux environment where Claude Code lives, and the MCP integration gives Claude full control over it: navigation, screenshots, clicks, form fills, DOM inspection, JavaScript execution.

Setting this up fundamentally changed how I build frontends, test features, and think about browser automation.

What Playwright MCP Does

Playwright is a browser automation framework. The MCP (Model Context Protocol) integration connects it to Claude Code, giving Claude direct control over a Chromium browser within a normal coding session.

Because Playwright runs natively in WSL, the integration works without any bridging between Windows and Linux, and without a display server. It runs headless when needed, which also means the same setup works identically on any Linux machine, whether that’s a local dev environment, a VPS, or a Docker container. That portability turned out to matter more than I initially expected.

How It Changed My Development Workflow

Visual verification

This was the original problem I wanted to solve, and it’s still where I get the most value. When I’m building or updating a site (this one, PineconeTales, any frontend project), I can ask Claude to navigate to the local dev server, take a screenshot, and assess the result. If something looks off, Claude identifies and fixes the issue visually, often without me saying anything beyond “check how this looks.”

Responsive design is where it really pays off. Instead of manually resizing a browser window and checking each breakpoint, I have Claude resize the Playwright viewport to mobile, tablet, and desktop widths and verify the layout at each one. It catches text overflow, misaligned elements, and spacing issues in seconds, things I might not notice until much later in the process.

End-to-end testing during development

This one surprised me with how useful it became. When I’m adding features to a web app, I now have Claude run through the full user flow before I even open a browser myself. Navigate to the page, click the relevant elements, fill out forms, submit, verify the response. If something breaks, Claude sees it immediately, diagnoses it through the DOM or console output, and fixes it. All in one loop.

It’s not a replacement for formal automated testing, but as part of the development workflow it catches issues early. I’ve had sessions where Claude found and fixed three or four bugs through Playwright before I’d even looked at the page. That’s time I would have spent manually clicking through flows, noticing something was wrong, switching back to the terminal, describing the problem, and waiting for a fix.

DOM inspection and debugging

Sometimes the issue isn’t visual. A click handler isn’t firing, or state isn’t updating correctly. Claude can use Playwright to inspect the actual DOM, read element attributes, check computed styles, and execute JavaScript directly in the browser context. This eliminates an entire category of back-and-forth where I used to be the relay between DevTools and the AI.

Beyond Development: Browser Automation on a VPS

Once I had Playwright working locally, I realized the same setup runs headless on a server. That opened up a different set of use cases entirely.

If you’ve read my previous post about learning to automate, you’ll know I spent years building browser automation with UiPath, then Selenium, then headless Chromium scripts. Playwright is the latest evolution of that approach, but with a meaningful upgrade: when you pair it with an AI model, the automation can handle ambiguity. A traditional Selenium script breaks when a site changes its layout or renames a CSS class. An AI-driven Playwright workflow can adapt because it understands what it’s looking at, not just where a specific selector used to be.

Some of the use cases I’ve been exploring:

Competitive intelligence. Monitoring competitor landing pages on a schedule to track messaging changes, new offers, and positioning shifts. Valuable for any marketing or strategy team, tedious to do manually at scale.
Price monitoring. Consumer price comparison across sites that don’t offer APIs. A scheduled workflow visits product pages, extracts pricing, and logs it for analysis.
E2E testing in CI/CD. Running automated test suites against staging environments as part of a deployment pipeline. Playwright is already the standard tool for this in many engineering teams.
Data collection from web-only platforms. Some platforms only expose data through a UI. When there’s no API and no export option, a headless browser on a schedule is often the most practical path.

All of this runs on the same VPS where I host my other projects. Chromium in headless mode, Playwright handling the browser interaction, scheduled scripts handling the cadence.

Setting It Up

The setup is straightforward once you know the gotchas. Here’s what worked for me on WSL (Ubuntu), and it applies to any Linux environment.

Prerequisites

Claude Code CLI installed
Node.js, npm, and npx available
WSL (Ubuntu) or any Linux environment with sudo access

Step 1: Install Chromium via the MCP’s Playwright

This is the one that tripped me up initially. The Playwright MCP package bundles its own version of Playwright and expects a specific Chromium revision. If you install Chromium separately via npx playwright install, you’ll likely hit version mismatch errors.

First, trigger the MCP package to cache itself:

npx @playwright/mcp@latest --help

Then find the cached Playwright and use it to install the correct Chromium:

# Find the MCP's npx cache directory
for dir in ~/.npm/_npx/*/; do
  if [ -d "$dir/node_modules/@playwright/mcp" ]; then
    echo "Found MCP cache: $dir"
    MCP_DIR="$dir"
    break
  fi
done

# Install Chromium using the MCP's own playwright-core
node "${MCP_DIR}/node_modules/playwright-core/cli.js" install chromium

Step 2: Install System Dependencies

Chromium needs system libraries (libgbm, libnss3, libasound2, fonts, etc.). This requires sudo:

sudo npx playwright install --with-deps chromium

This also downloads a Chromium binary to /root/.cache/ms-playwright/ which won’t be used. The important part is the system dependency installation via apt.

Step 3: Add Playwright MCP to Claude Code

Add it globally with Chromium and vision (screenshot analysis) enabled:

claude mcp add --scope user playwright \
  -- npx @playwright/mcp@latest --browser chromium --caps vision

This uses headed mode by default. If you’re on a headless server or VPS with no display:

claude mcp add --scope user playwright \
  -- npx @playwright/mcp@latest --browser chromium --headless --caps vision

Step 4: Restart Claude Code

Exit and restart your Claude Code session so the new MCP server loads.

Step 5: Verify

claude mcp list

You should see:

playwright: npx @playwright/mcp@latest --browser chromium --caps vision - Connected

In a Claude Code session, the mcp__playwright__* tools (navigate, screenshot, click, fill, etc.) should now be available.

Troubleshooting

“Browser chromium is not installed”: Version mismatch. The MCP’s bundled Playwright expects a different Chromium revision than what’s installed. Re-run Step 1 to install the correct version through the MCP’s package.

“Browser chrome is not found at /opt/google/chrome/chrome”: The MCP is defaulting to Chrome instead of Chromium. Make sure you pass --browser chromium in the MCP config.

Browser fails to launch (no display): On headless servers or WSL without an X server, switch to headless mode by removing and re-adding the MCP with the --headless flag.

Looking Ahead

AI-assisted development is moving fast, and tools like Playwright MCP are a good example of how the boundaries between writing code, testing code, and automating with code continue to blur. They’re becoming part of the same loop, with the AI handling whichever capability is needed at any given moment.

For anyone building frontends with AI coding tools on WSL or Linux, this setup is worth the ten minutes it takes to configure. It solved a real friction point for me and has since become a core part of how I work.

If you’re using a similar setup or have found other MCP integrations worth exploring, I’d love to hear about it. Feel free to use the contact form below or reach out on LinkedIn.