Browser Control for Testing

Type checkers and linters verify code correctness. But for frontend work, the ultimate verification is visual: does it look right in the browser? Claude Code's /chrome command opens a browser instance that Claude can control — navigating pages, taking screenshots, clicking elements, and reading the DOM. This turns Claude from a code-only tool into a full-stack verification system that can see the result of its own changes.

The workflow is straightforward. Claude makes a UI change, launches the dev server if it is not running, opens /chrome, navigates to the affected page, takes a screenshot, and evaluates whether the visual result matches the intent. If the button is misaligned, if the colors are wrong, if the layout breaks at a certain viewport width — Claude can see it and fix it in the same loop. No switching to a browser, no manual refreshing, no describing what went wrong. Claude sees the problem the same way you would.

For more structured testing, combine /chrome with specific test scenarios. "Navigate to /login, enter invalid credentials, submit the form, and verify the error message appears in red below the password field." This is end-to-end testing that Claude performs visually. It catches CSS issues, layout bugs, responsive breakpoints, and interaction flows that no type checker or unit test would find. The visual verification loop closes the gap between "the code is correct" and "the product works."