Claude Code Browser Testing for Client Work: Let Claude Verify the Build Before the Client Does

What Browser Testing Means in the Claude Code Desktop App

The desktop app can start a dev server and open it in the Browser pane to verify its own changes. The docs are specific about what verify means: Claude takes screenshots, inspects the DOM, clicks elements, fills forms, and fixes the issues it finds. In most cases it starts the server automatically after editing project files, and by default it auto-verifies changes after every edit, so it takes the screenshot and checks for errors before it tells you the change is done. This works for frontend apps and for backend servers, where Claude can hit API endpoints and read server logs. You can also just ask for a preview at any time.

The pane is a normal tabbed browser you can use yourself. Press Cmd+Shift+B on macOS or Ctrl+Shift+B on Windows to toggle it, click into the running app, and use Cmd+Shift+S to select an element on the page when you want to point Claude at exactly the button that is wrong. It also opens static HTML, PDFs, images, and videos from the project when you click a path in the chat, which is how I check a generated invoice PDF or a rendered email template without leaving the session. Server start and stop, and the Persist sessions toggle that keeps cookies and local storage alive across restarts so you are not logging into the client's staging auth every time, sit in the server dropdown in the session toolbar.

The configuration lives in .claude/launch.json at the root of the folder you opened. Claude writes the first version by detecting the project's dev command; if the client uses something unusual, or a different port, edit the file or click Edit configuration in the server dropdown. The same file holds the autoVerify flag, which is on by default and can be set to false per project. I leave it on for client work. The whole point is that the check happens before the reply, not after the client opens the link.

The Two-Browser Rule

The desktop app is deliberate about having two browsers, and the docs draw the line in one sentence: the Browser pane uses a clean profile, separate from your personal browser, with none of your saved logins or history, for building and testing your app and for sites that do not need your identity; when you want Claude to act as you in your logged-in sessions, use the Claude in Chrome extension instead, which shares your browser's login state. The Profit Room's Two-Browser Rule is just that sentence applied to a laptop with several clients on it: the build lives in the clean browser, the extension comes out for the single task that needs your identity, and no task uses both.

1. Build and verify in the Browser pane. Nothing you are signed into exists there, so a page Claude opens while testing Client A's app cannot see your Gmail, your bank, or Client B's admin panel. Your local dev server and project files need no approval, so auto-verify keeps running without prompts.
2. Treat every external site in the pane as a stranger. The first time Claude acts on an external site you get a permission card: Allow once, Always allow, or Deny. Each site needs its own approval, including each subdomain. Safety classifiers review Claude's clicks and typing on external pages in every permission mode, and in any mode other than Auto and Bypass a domain allowlist check runs before Claude navigates somewhere new. Even on an approved site Claude will not purchase, create accounts, or bypass a CAPTCHA without you.
3. Reach for the Chrome extension only when the job is identity. Moving the client's contact list into their CRM, drafting the weekly update straight into the shared Google Doc, filing an issue in their tracker: those need to happen as you, so they happen in the extension, in a tab group Claude opens in your real Chrome, with a pause at any login page or CAPTCHA for you to handle.
4. Never run the build and the identity task in the same browser. If Claude needs to test the app and also needs your logged-in CRM in one session, that is two tasks. The pane for the app, the extension for the CRM, and the sandbox and permission rules underneath both.

The rule exists because of what the extension can reach. It shares your browser's login state, so it can access any site you are already signed into; that is the feature, and it is also the reason it does not belong anywhere near routine build verification. Site-level permissions for it are inherited from the extension's own settings, which is where you control which sites Claude can browse, click, and type on. The extension needs version 1.0.36 or later, a direct Anthropic plan such as Pro or Max, and a /login sign-in; if you authenticate with an API key or a long-lived token, Claude Code keeps Chrome integration off. It is not available through third-party providers, and it does not work in WSL. The desktop docs also note that with computer use enabled, browsers are capped at view-only and Claude is steered toward the dedicated browser tool, which is the same rule enforced from the other direction.

The Proof Pass Before Handoff

The build loop verifies each edit. The Proof Pass verifies the build. It is the last thing I run before a client sees a link, and it turns the browser from a debugging tool into the artifact that gets the invoice paid. Take the acceptance list from the agreement, the one you wrote when you [set expectations before the build](/blog/set-client-expectations-before-a-claude-code-build), and ask Claude to walk it in the Browser pane one item at a time: submit the intake form with bad data and confirm the error copy, book through the calendar and confirm the confirmation email fires, log in as the demo user and confirm the dashboard loads clean. Ask it to check the console for errors on each page as it goes, and tell it what patterns to look for rather than asking for everything, because console output is verbose.

Then make the pass produce files. In the Chrome extension Claude can save a screenshot to disk and report the path, and it can record a browser session as a GIF, both of which land in the project folder where they belong. A folder of screenshots named for each acceptance item plus a short GIF of the main flow is the whole sign-off package: attach it to the [sign-off request](/blog/get-a-client-to-sign-off-on-a-build), and the client is approving something they can see instead of something they have to imagine. The same files are the body of the [weekly update](/blog/weekly-client-update-prevents-fires) while the build is still in progress. One warning from the docs that I repeat every time: the recording captures everything visible in the browser, including account details on logged-in pages, so review a GIF before it goes to anyone outside the project. Under plan mode the extension also prompts before it records, opens a tab, or runs a shortcut, which is the right default.

The Proof Pass is also where the extension's other skills earn their place. File uploads let Claude attach the exported CSV or a log file to the client's bug tracker from a form on the page, within a 10 MB limit per upload and only for files the session is allowed to read. Data extraction lets it pull the client's existing product listings into a local CSV before a migration. Multi-site work lets it check a calendar, look up each attendee's company, and draft the notes. None of those are testing, and all of them are identity work, so they run in the extension, on their own, after the build is verified in the pane.

When the Browser Pass Finds Something

Most of what the pass finds is small and Claude fixes it in the same reply; that is what auto-verify is for. The findings that matter are the ones that survive a fix, and those get handled the way [a client-found bug after launch](/blog/client-finds-a-bug-after-launch) would, except that you found it first. Write the reproduction in the browser's terms, the page, the click, the console line, and the screenshot Claude saved, and put it in the update with the fix and the date. A client who sees you catch a broken checkout on Tuesday and ship the fix on Tuesday stops asking whether the AI-built thing is reliable, because they are watching it be verified.

A few practical things the docs flag that will save you an afternoon. Enabling the Chrome extension by default in the terminal loads the browser tools into every session and increases context usage, so use the flag only when you need it and keep the desktop pane as the everyday browser. The extension's connection can drop during a long session when its service worker goes idle; /chrome and Reconnect extension brings it back. A JavaScript alert or confirm dialog on the client's page blocks browser events until you dismiss it by hand. And if a task is not browser work at all, a native app with no interface but a window, that is [computer use](https://code.claude.com/docs/en/computer-use), which is broader and slower and off by default; Claude tries the most precise tool first and reaches for the screen last.

Put the browser pass on the client's calendar, not just yours. A [nightly routine](/blog/claude-code-routines-for-client-work) that opens the live site, walks the same acceptance list, and writes the screenshots to a dated folder is a maintenance-plan line item a client understands the first time they hear it, and it is the reason [the build comes back to you](/blog/deliver-a-build-so-clients-come-back) when something changes. The tool that verified the build is the tool that keeps verifying it, and the client is paying for the second part.