Claude Code Browser: How I Let Claude Test Its Own Changes in the Desktop App

The Claude Code browser is a pane inside the desktop app's Code tab. Open it with Cmd+Shift+B on macOS, Ctrl+Shift+B on Windows, or from the Views menu. When Claude edits a web project it starts the dev server, opens the running app in that pane, and verifies its own change: it takes screenshots, checks for errors, inspects the DOM, clicks elements, fills forms, and fixes what it finds before it tells you it is done. That auto-verify step is on by default. The pane is also a tabbed browser you can use yourself, for docs or an issue tracker, and Claude can read and act on external pages there with extra safety checks. It runs in a clean profile with none of your saved logins, which is the single fact that decides when you use it and when you use the separate Claude in Chrome extension instead.

I turned the pane on for the club site the week it shipped and have not opened a second window to check Claude's work since. The interesting part is not that Claude can click a button. It is what auto-verify caught that I would have shipped, and where the clean-profile line sent me to the extension. Both are below.

Claude Code can drive a browser two ways, and people mix them up because both are called "browser" in the docs. The Browser pane lives inside the desktop app and uses its own clean profile. The Claude in Chrome extension lives in your real Chrome or Edge and shares your login state. The CCC Clean-or-Signed-In Rule is the whole decision: does the task need to happen as you? If no, use the pane. If yes, use the extension. I have not found a third case.

The extension has a few tricks the pane does not: it can attach files from your machine to an upload field, record a browser session as a GIF, and save screenshots to disk. The pane has one the extension does not: it is where auto-verify runs, next to the diff and the chat, without you switching windows. If you set both up, the desktop app routes browser work to the extension when the task calls for it and uses the pane for verifying your app.

When autoVerify is on, Claude verifies code changes after editing files. It screenshots the result, checks for errors, and confirms the change works before it finishes its response. You do not prompt for this. It is a setting in the .claude/launch.json file at the root of the folder you opened, and it defaults to on. Set "autoVerify": false in that file, or flip it from the server dropdown in the session toolbar, and the preview tools stay available but only run when you ask.

On the club site, the first change I watched it verify was a form. I asked for a required-field check on the email input. Claude made the edit, the pane reloaded, and instead of stopping there it submitted the form empty, read the page, and noticed the error message rendered but the submit button stayed disabled afterwards. It went back and fixed the button state. I would have merged the first version, because in the diff it looked complete. That is the pattern: auto-verify catches the class of bug that only exists once the page is running, and diffs never show those.

Two things to know before you rely on it. First, the pane can also open static HTML, PDFs, images, and videos from your project, so a landing page with no server still gets checked; click the file path in the chat to open it. Second, verification costs tokens and time on every edit. On a long refactor where I know the page does not change, I turn it off from the dropdown and ask for one verification at the end. [Claude Code context management](/blog/claude-code-context-management) covers why that matters on big sessions.

Claude detects your dev server the first time and writes the configuration to .claude/launch.json in the folder you selected when you started the session. If your project uses a different command, say yarn dev instead of npm run dev, or a non-default port, edit that file or click Edit configuration in the server dropdown. The file accepts comments. You can list more than one configuration, which is how I run the frontend and the API server side by side and let Claude test an endpoint and the page that calls it in the same pass.

This is the same launch.json that the deploy step reads when you get to shipping, so getting it right here pays twice. [How to deploy an app with Claude Code](/blog/how-to-deploy-an-app-with-claude-code) picks up from a working preview.

The pane is a real tabbed browser, so you can open documentation or an issue tracker next to your app, and you can sign in to sites in it, including popup flows like Google sign-in. Claude can read and act on those pages with the same tools it uses to verify your app, plus two checks that do not apply to localhost. Safety classifiers review Claude's write actions on external pages, clicking and typing, in every permission mode, and when one flags an action you get a prompt regardless of mode. And in every mode except Auto and Bypass permissions, a domain allowlist check runs before Claude navigates to a new site.

The first time Claude acts on an external site, a card appears with Allow once, Always allow, or Deny, and Claude waits. Always allow is saved per site on your device, subdomains count as separate sites, and you can revoke it in Settings. Your local dev servers and project files never need approval, which is why auto-verify keeps running without interrupting you. Even on an approved site, Claude will not buy things, create accounts, or get past a CAPTCHA without you. If you are doing client work in the pane, [is Claude Code safe for client work](/blog/is-claude-code-safe-for-client-work) covers what else to lock down.

Auto-verify handles the edit you just made. These are the checks I ask for on purpose, usually before a commit, and they are short because the pane gives Claude the page, so I do not have to describe it.

If a check fails and Claude's fix is not obvious, the pane is also where I debug, because it can read the failing state instead of my description of it. [How to debug with Claude Code](/blog/how-to-debug-with-claude-code) is the longer method; the short version is that a screenshot plus the DOM beats a paragraph of me explaining what I saw.

Turn the pane on, leave auto-verify at its default for a week, and read what it fixes after each edit. Then decide where to switch it off. That order matters: most people turn it off first because it feels slow, and never learn which bugs it was quietly catching.