Claude Code Browser Testing: A Practical Workflow

The core conclusion first: agent-driven browser testing is excellent at exactly the checks your test framework is worst at (visual bugs, exploratory passes, logged-in flows), and it should stay out of CI, regression suites, and load testing. The agent complements the suite; it doesn't replace it.

ego (lite) as the browser arm adds the two things the baseline tools lack: tests against pages behind your real logins, and a browser that isn't the one you're working in, since the agent's work happens in its own Space with its own tabs. It's free, and the /ego-browser skill lands in Claude Code during onboarding.

The pitch for agent-driven testing usually oversells it: "Claude Code will test your whole app!" It won't, and chasing that promise is how teams conclude the whole idea was hype.

Visual bugs are the canonical case for what it can do: a collapsed grid or an element rendering under the fold passes every DOM assertion you wrote, while an agent looking at the page catches it in one screenshot.

Where does agent-driven testing actually fit?

Three categories earn the agent its seat. First, visual verification: layout collapse, wrong stacking, elements crushed at mobile widths, a hero image pushing content off-screen. Your assertions check that elements exist and contain text; they don't check that the page looks right, and an agent reading a screenshot does. This is why visual bugs are the demo everyone shows: the before and after is visible without explanation.

Second, exploratory passes on changed surfaces: "I just refactored the checkout form; open it, try the obvious paths, tell me what feels broken." No test file exists for the bug you haven't found yet, and an agent clicking through with judgment finds the missing-error-message class of problem cheaply.

The economics matter here: an exploratory pass that would cost an engineer a distracted half hour costs the agent a prompt, so it actually happens after every change instead of before releases only.

Third, flows behind real logins: does the dashboard actually render with production-shaped account data, does the upgrade path work for an account that's mid-trial. Test fixtures approximate this; a real session shows it, edge-case data and all.

What does the working workflow look like?

The loop, as we run it on our own web project, generalizes to any dev setup:

1. Dev server running with hot reload (pnpm dev)
2. Prompt: "Open localhost:3000/pricing in the browser, screenshot it
   at desktop and 375px width, and tell me anything visually broken."
3. Agent opens the page, captures both widths, reports:
   e.g. the plan cards overflow their container at mobile width
4. "Fix it." Agent edits the CSS, hot reload applies.
5. "Verify." Agent re-screenshots; the fix is visible or it isn't.

Two properties make this loop work. Hot reload keeps the cycle seconds long, so verify-after-fix is cheap enough to always do; an agent that fixed the code but never looked again is the failure mode to design out. And screenshots close the judgment gap: the agent isn't parsing your DOM to guess at appearance, it's looking at the rendered page, which is the same evidence a human reviewer would use.

For logged-in checks, the prompt changes and the loop doesn't: "open the billing page in my session and confirm the invoice table renders with real data" works when the browser carries your sessions, which is where the tool choice below earns its keep.

The exploratory variant swaps step 2 for a looser brief and a report format: "click through the new checkout flow like a hurried customer: wrong card number, back button mid-payment, double-submit. List everything that behaved badly, with a screenshot each." You get back a punch list with evidence instead of a green checkmark, which is the entire point: exploration produces findings, not passes.

Close the loop by graduating findings: each confirmed bug becomes a line in the real suite once fixed, so the agent's discovery becomes the framework's permanent regression check. The agent finds it once; Playwright makes sure it stays found.

Look, fix, look again. That's the whole method.

Which browser tool should the agent drive?

For public localhost checks, honestly, several tools work: Playwright MCP and Cursor's built-in browser both handle the screenshot loop fine, and we compared the full field in the five-ways guide. The choice sharpens on two conditions.

If sessions matter (testing pages that need your login or staging behind SSO), the browser needs your state. ego (lite) is built for that: it's a free browser sharing your logged-in state with agents like Claude Code, so "check the page as my account sees it" is just a prompt, with no fixture-building detour.

And if you're testing while you work, the Space model matters: the agent's browser work happens in its own isolated workspace with its own tabs, so your editor and your own browser stay untouched through a twenty-minute testing pass, and parallel checks (desktop and mobile widths, two locales) can run side by side.

npx skills add citrolabs/ego-lite

What we deliberately don't use for this job: anything that takes over the browser we're working in (Claude for Chrome or Browser MCP, in this context). A testing loop runs dozens of navigations; running them in your own window turns a background check into a foreground hostage situation, and the whole point of delegating the pass was to keep working while it runs.

Which tests don't belong here?

Four categories stay with your framework, and pretending otherwise wastes everyone's month. Assertion-dense regression suites: hundreds of precise checks need determinism and speed, which is Playwright or your existing runner, not model calls.

CI gates: agents are neither cheap enough nor deterministic enough to block merges on, and ego (lite) specifically is a desktop browser with no headless CI mode. Load and performance testing: different discipline, different tools entirely. And unit tests, obviously, which never touch a browser at all.

The division that works: the framework owns repeatable verification of known requirements; the agent owns judgment calls on new surfaces. Teams that respect the line get both; teams that try to replace the suite with prompts get flaky CI and a big bill, then write the blog post about how agent testing is hype.

Download ego (lite) for Mac, free, or see all five ways to connect Claude Code to a browser before you pick the arm.

FAQ

Can Claude Code write my Playwright tests too?

Yes, and that's a separate, also-real workflow: point it at a page, ask for page objects and draft specs, then refactor what it produces (QA practitioners consistently report the drafts save locator time and need human cleanup). This article's workflow is the complement: the agent as tester rather than test author.

Is claude code ui testing reliable enough to trust?

For the visual and exploratory categories, yes, with the verify-after-fix loop as the discipline: the agent's claim is always backed by a fresh screenshot you can look at. For anything you'd gate a release on, encode the finding into a real test afterward; the agent found the bug, the suite keeps it dead.

What about testing against staging behind SSO?

That's the logged-in category, and it's exactly where session-sharing beats fixtures: sign into staging once in ego (lite), and every subsequent test prompt runs as your authenticated self, 2FA included (you complete challenges once, the session persists). No storage-state files to rotate, no test-account drift.

Does this replace QA engineers?

No; it moves where their time pays off. The agent runs the hundredth exploratory pass nobody had time for and catches the visual regressions between formal cycles; humans still decide what matters, own the suite, and judge the ambiguous cases. Teams using this well ship the same QA headcount at noticeably wider coverage.