superpowers-chrome vs Playwright: which tool to drive a browser with Claude Code?

The problem: driving a browser from the terminal

When you work with Claude Code, there comes a point where reading code isn't enough anymore. You need to see the page. Check a CSS render. Debug JavaScript behavior. Take a screenshot to document a bug. Scrape a page protected by a login.

For all of this, the AI agent needs to be able to drive a browser. Two tools exist in the Claude Code ecosystem: Playwright MCP (the Microsoft standard) and superpowers-chrome (a plugin that controls your real Chrome). They do similar things, but with very different philosophies.

Playwright MCP: the Microsoft standard

How it works

Playwright is a testing and automation framework developed by Microsoft. The Playwright MCP exposes its capabilities to Claude Code via the MCP protocol. When you use it, Playwright launches an isolated Chromium instance - a completely blank browser, with no cookies, no extensions, no history.

Installation is simple:

{
  "mcpServers": {
    "playwright": {
      "command": "npx",
      "args": ["@anthropic/playwright-mcp"]
    }
  }
}

Claude Code can then navigate to a URL, click on elements, fill in forms, take screenshots, and read the page content. Everything happens inside a sandboxed Chromium.

Strengths and limitations

Strengths:

• Reproducibility - every session starts from an identical blank state
• Isolation - no interference with your personal browsing
• Stability - mature project, maintained by Microsoft and Anthropic
• CI/CD compatible - runs without a graphical interface (headless mode)
• Multi-browser - supports Chromium, Firefox, WebKit

Limitations:

• No sessions - impossible to access a site where you're already logged in
• No extensions - no ad blocker, no password manager
• Chromium is not Chrome - rendering may differ slightly from your real Chrome
• Heavy - downloads and launches a full Chromium on every session

superpowers-chrome: your Chrome, your sessions

How it works

superpowers-chrome takes the opposite approach. Instead of launching an isolated browser, it connects to your real Chrome via the Chrome DevTools Protocol (CDP). Your Chrome, with your tabs, your cookies, your sessions, your extensions - it's all there.

The only requirement: Chrome must be launched with the remote debugging flag:

# macOS
/Applications/Google\ Chrome.app/Contents/MacOS/Google\ Chrome --remote-debugging-port=9222

# Linux
google-chrome --remote-debugging-port=9222

# Windows
chrome.exe --remote-debugging-port=9222

Classic pitfall on first launch: if Chrome is already open, the flag is --remote-debugging-port silently ignored. Chrome detects that an instance is already running and attaches to it - without enabling the debug port. Result: superpowers-chrome can't connect and shows the error "Chrome is not launched in Remote Debugging mode".

The solution: close Chrome completely (all windows + check that no Chrome process is still running in the background), then relaunch it with the flag. On macOS, a Cmd+Q isn't always enough - Chrome can stay in memory. If in doubt:

# Forcer la fermeture de tous les processus Chrome
pkill -f "Google Chrome"

# Puis relancer avec le flag
/Applications/Google\ Chrome.app/Contents/MacOS/Google\ Chrome --remote-debugging-port=9222

Tip: create an alias in your ~/.zshrc so you don't have to think about it again:

alias chrome-debug='/Applications/Google\ Chrome.app/Contents/MacOS/Google\ Chrome --remote-debugging-port=9222'

Once Chrome is open with this flag, superpowers-chrome can connect to it and control everything: navigate, click, type text, run JavaScript, read the DOM, take screenshots.

Skill Mode vs MCP Mode

superpowers-chrome offers two modes of use :

Skill Mode - slash commands directly in Claude Code:

/chrome navigate https://example.com
/chrome screenshot
/chrome click "#login-button"
/chrome type "#email" "user@example.com"
/chrome evaluate "document.title"

MCP Mode - the same capabilities exposed as MCP tools, usable autonomously by the AI agent in its workflows. Claude Code itself decides when to navigate, when to click, when to capture.

Skill Mode is handy for one-off actions (quick debug, capture). MCP Mode is more powerful for automated workflows where Claude Code chains actions without intervention.

The 17 commands

Strengths and limitations

Strengths:

• Real Chrome - it's your browser, with your full profile
• Sessions preserved - connects to Gmail, GitHub, admin dashboards, etc.
• Active extensions - ad blockers, password managers, dev tools
• No download - uses the Chrome already installed
• Dual mode - Skill (manual commands) + MCP (automated)
• Lightweight - connects via CDP, no extra process

Limitations:

• BETA - version 1.8.0, may contain bugs
• Chrome only - no Firefox or Safari
• Not reproducible - state depends on your Chrome session
• Mandatory flag - Chrome must be launched with --remote-debugging-port=9222
• Security - the CDP port exposes your Chrome, use locally only

Detailed comparison

When to use which?

Scenario 1: visual debugging of a production site

You have a CSS bug reported by a client. You want to see the page exactly as it appears in a real browser, with fonts loaded, cached images, and Chrome's exact rendering.

Tool: superpowers-chrome. It uses your real Chrome - the same rendering engine as your users. You can inspect styles, read the DOM, take a screenshot, and share it. No need to reconfigure anything.

/chrome navigate https://client-site.com/page-buggee
/chrome screenshot
/chrome styles ".header-nav"
/chrome console

Scenario 2: automated E2E tests

You're writing integration tests to check that the sign-up form works: enter an email, a password, click "Sign up", verify the confirmation message.

Tool: Playwright. Tests must be reproducible. Every run must start from a blank state - no cookies, no previous sessions. Playwright guarantees this isolation. It's also the only one that runs in CI/CD without a graphical interface.

Scenario 3: scraping with authentication

You want to extract data from a SaaS dashboard where you're logged in. The site uses OAuth, httpOnly cookies, and a CSRF token.

Tool: superpowers-chrome. Your session is already active in Chrome. No need to script a complex login flow. superpowers-chrome accesses the protected pages directly because Chrome already has the authentication cookies.

/chrome navigate https://app.saas-tool.com/dashboard
/chrome html ".data-table"
/chrome evaluate "JSON.stringify([...document.querySelectorAll('.row')].map(r => r.textContent))"

Scenario 4: screenshots for documentation

You're writing an article with technical documentation and need screenshots of your site running in local development.

Tool: superpowers-chrome. This is the most direct option. Navigate to localhost:3000, take the screenshot, keep working. No extra configuration, no separate Chromium to launch.

/chrome navigate http://localhost:3000
/chrome screenshot

If, on the other hand, you need screenshots at several resolutions (mobile, tablet, desktop) in an automated way, Playwright is better suited thanks to its configurable viewports.

My setup

Here's how I configured the two tools to coexist. In my CLAUDE.md, the rule is simple: superpowers-chrome by default, Playwright as fallback.

superpowers-chrome is installed as a Claude Code plugin:

# Installation (une seule fois)
/plugin marketplace add obra/superpowers-marketplace
/plugin install superpowers-chrome@superpowers-marketplace

Playwright MCP is configured in ~/.claude.json :

{
  "mcpServers": {
    "playwright": {
      "command": "npx",
      "args": ["@anthropic/playwright-mcp"]
    }
  }
}

For everyday use, I launch Chrome with the debug flag at the start of my work session:

/Applications/Google\ Chrome.app/Contents/MacOS/Google\ Chrome --remote-debugging-port=9222

And in my CLAUDE.md, I added a section explaining to Claude when to use which. Result: when I ask "take a screenshot of the site", Claude uses superpowers-chrome. When I ask "run the E2E tests", it uses Playwright.

The important point: both can coexist. There's no conflict. They use completely different mechanisms (CDP vs Playwright instance). It's like having a flathead screwdriver and a Phillips - you don't choose one "against" the other, you pick the one that fits the screw.

Conclusion

superpowers-chrome and Playwright MCP aren't competing. They address different needs:

• superpowers-chrome is your everyday work tool - debug, inspection, captures, scraping with auth. It's your Chrome, with all your context.
• Playwright is your testing and automation tool - clean, reproducible environment, CI/CD compatible.

The right setup is to have both. superpowers-chrome as the first choice for interactive work. Playwright when you need an isolated environment or a reproducible workflow.

superpowers-chrome is still in BETA (v1.8.0), but it's already very functional for its main use case: driving your real browser from the terminal. And that's a use case Playwright doesn't cover - by design.