← All Reviews

Claude Code Chrome Browser Skill: Real Browser Automation Without the Playwright Setup Tax

claude-code-chrome-browser on GitHub
📦 claude-code-chrome-browser
72
Stars
🍴
0
Forks
🐛
0
Issues
🕐
7
Min Read
📝
1,352
Words
Stable
View on GitHub →

Claude Code Chrome Browser Skill: Real Browser Automation Without the Playwright Setup Tax

72 stars and holding steady. Not viral, not dead — which for a utility skill in the SkillsMP ecosystem is actually a decent signal. Trending tools that spike and crash usually have hype problems. Stable tools with a modest star count usually have real usage problems — as in, people are actually using them and not rage-uninstalling after day one.

I spent some time with the claude-code-chrome-browser skill from stevehuang0115, which is part of the larger Crewly multi-agent platform. Here's my honest take.

What This Skill Actually Does

At its core, this skill is a thin configuration wrapper that tells Claude Code to use the mcp__claude-in-chrome__* tool suite — a set of MCP (Model Context Protocol) tools that communicate with a Chrome extension you install in your browser. When Claude Code is started with the --chrome flag (which Crewly handles automatically if you're using it), your agent gains the ability to interact with whatever Chrome instance you have running.

This is not Playwright. It's not Puppeteer. It's not a headless browser spun up in a Docker container. It's your actual Chrome, with your cookies, your logged-in sessions, your extensions. That distinction matters more than it might seem at first.

The Problem It Solves

Anyone who's tried to automate web tasks with AI agents has hit the same wall: most automation approaches require either (a) a headless browser that knows nothing about your authenticated state, or (b) complex setup involving browser drivers, credential injection, and session management. Both approaches are fine for CI pipelines. They're a pain in the ass for day-to-day agent workflows.

What this skill enables is something more pragmatic: you're already in Chrome, you're already logged into your tools, and now you can tell an agent "go to our internal dashboard, pull the error counts from the last 24 hours, and summarize them" — and it can actually do that without you setting up a whole automation framework first.

For multi-agent workflows in Crewly specifically, this fills a real gap. If you have a QA agent or a research agent that needs to verify something on a live site, they can just... do it. No infrastructure yak-shaving required.

Key Capabilities Worth Highlighting

mcp__claude-in-chrome__find — Natural language element discovery This is the one I was most skeptical about and ended up being most impressed by. Instead of writing CSS selectors or XPath expressions, you describe what you're looking for in plain language. "The submit button" or "the username field" and the tool resolves it against the page's accessibility tree. It won't always work perfectly, but it degrades gracefully — which is more than I can say for brittle CSS selector chains.

mcp__claude-in-chrome__read_page — Accessibility tree reading Rather than dumping raw HTML at the model (which is noisy and token-expensive), this reads the accessibility tree. This is the right call. The accessibility tree gives you structured, semantic information about what's actually interactive on the page without the soup of <div> nesting that most modern web apps produce.

mcp__claude-in-chrome__javascript_tool — Escape hatch for edge cases When the higher-level tools can't handle something, you have a direct JavaScript execution channel. This is the escape hatch you'll need eventually, and I'm glad it's there. Any automation tool that doesn't give you a raw execution path eventually becomes a dead end.

mcp__claude-in-chrome__computer — Mouse and keyboard fallback For truly dynamic UIs where accessibility tree reading fails (canvas elements, custom widgets, that one legacy app your company refuses to retire), there's a mouse/keyboard interaction tool. This is the blunt instrument in the toolbox. Use it last, but it's good that it exists.

Screenshot capability Seemingly minor, but critical for debugging. When your agent is doing something wrong on a page and you can't figure out why, being able to ask it to take a screenshot and show you what it sees is genuinely useful. I've spent way too long debugging headless browser automation with nothing but logs.

Who Should Install This

Install it if: - You're already using or evaluating Crewly for multi-agent orchestration - You want Claude to help with web research tasks that require authentication - You're doing QA or testing workflows where you want an agent to verify UI state on a real browser - You need to automate tasks on internal tools where setting up proper API access isn't worth the overhead - You regularly find yourself doing repetitive web tasks (form submissions, data entry, scraping behind login walls) that you'd rather hand off to an agent

Skip it if: - You need headless, server-side browser automation for CI/CD pipelines — this is the wrong tool for that - You're not on Claude Code as your runtime (the skill explicitly requires it) - You're uncomfortable with an agent having access to your active, authenticated browser session — the security implications are real and worth thinking about - You need cross-browser support; this is Chrome-only by design

How to Install

The skill itself is straightforward to add:

# Drop it in your project-level skills directory
cp chrome-browser.skill.md .claude/skills/

# Or globally
cp chrome-browser.skill.md ~/.claude/skills/

But the skill file is just the configuration layer. The actual requirement is the Claude Code Chrome extension installed in your browser, and Claude Code started with --chrome. If you're using Crewly, the platform handles the --chrome flag automatically when this skill is active. If you're running Claude Code standalone, you'll need to manage that flag yourself.

The Chrome extension install step is the real friction point here — it's not a one-command setup. Budget 10-15 minutes the first time.

Concerns and Honest Limitations

Security surface area is non-trivial. When you give an agent access to your authenticated Chrome session, you're giving it access to everything you're logged into. That's your email, your banking, your AWS console, your GitHub. The skill documentation doesn't spend much time on this. I'd recommend being deliberate about what you ask agents to do with this enabled, especially in automated/unattended workflows.

Chrome-only is a real constraint. If your team uses Firefox or Safari, this doesn't help them. The claude-in-chrome MCP toolset is built around the Chrome extension model, so this isn't something Crewly can easily fix.

The skill itself is thin. To be clear about what you're actually installing: the SKILL.md file is essentially a configuration manifest that registers the MCP tool pattern and sets the --chrome flag. The actual implementation lives in the Chrome extension and the claude-in-chrome MCP server. This skill is a connector, not an implementation. That's fine — it's the right architecture — but go in with accurate expectations.

Stability on dynamic SPAs is variable. Modern single-page applications with aggressive DOM mutations can cause the accessibility tree reader to get confused. The find tool works well on well-structured pages and struggles on heavily custom-component UIs. The JavaScript escape hatch helps, but you'll hit pages where the agent needs multiple attempts.

No built-in wait/retry logic in the skill definition. The best practices section mentions "wait for page loads" but there's no built-in mechanism for this — you're relying on the model to reason about timing correctly. In practice, this means you occasionally need to be explicit in your prompts about waiting for things to load.

Verdict

This is a solid, practical skill for the use case it targets. If you want Claude Code agents to interact with real web pages in your existing browser context — especially behind authentication — this is the most friction-free path I've found. The architecture is sound (MCP tools, accessibility tree over raw HTML, JavaScript escape hatch), and the Crewly integration makes it genuinely seamless if you're already in that ecosystem.

The 72 stable stars suggest real users, not hype. I'd trust that signal.

Just go in clear-eyed about the security implications of browser access, the Chrome-only constraint, and the fact that this is a connector to an external extension — not a self-contained automation engine. For the right workflow, it's worth the setup time.


Install it: SkillsMP Listing

Source: GitHub — stevehuang0115/crewly

// THE VERDICT
View claude-code-chrome-browser on GitHub →
Need help building with tools like this?
We build AI-powered applications and developer tools. 30+ years of engineering experience.
Get in Touch
claude-skillsbrowser-automationmcpcrewlychrome
← Previous gstack Has 69K Stars — But Is It Actually Useful or Just Garry Tan's Personal Config? Next → Get Shit Done: 54K Stars Says This Claude Code Workflow System Is Worth Your Attention
← Back to All Reviews