Test local web apps and fix errors in one session
AI coding agents can write code. Task: AI coding agents can write code. That part is solved. The part that was missing until recently: can they check their own work in a real browser? With Claude Code (or Claude Desktop) and the Claude for Chrome extension, the answer is yes. We have been using this setup daily for the past few weeks, and it has changed how we build. Claude writes code, opens localhost:3000 in your browser, clicks through the UI, reads console errors, and fixes what is broken. All in the same session, without you touching the browser. It is the tightest local dev feedback loop we have seen from any AI coding tool. But it comes with real tradeoffs - cost, scope, and stability - that are worth understanding before you adopt it. What the setup looks like The installation takes about two minutes: Install the Claude in Chrome extension from the Chrome Web Store Connect it to Claude Code or Claude Desktop: Claude Code (CLI): run claude --chrome or type /chrome inside an existing session Claude Desktop: the extension connects automatically when both are running Claude Code (CLI): run claude --chrome or type /chrome inside an existing session Claude Desktop: the extension connects automatically when both are running That is it. Claude can now see and interact with your browser. Both Claude Code and Claude Desktop work with the extension. We mostly use Claude Code because the terminal-to-browser loop is faster for development - write code, test in browser, fix, repeat. But if you prefer the Desktop app for general tasks or conversation-heavy workflows, the Chrome extension works there too. Same capabilities, same browser access. The key detail that makes this work: the extension shares your actual Chrome session. Your cookies, your logins, your local dev server - Claude sees exactly what you see. There is no separate browser profile, no headless instance, no credential management. You approve new domains through a whitelist the first time Claude tries to access them. After that, it can navigate freely within approved domains. The closed loop that makes this useful The workflow goes like this. You ask Claude to build a feature. It writes the code. Then - and this is the part that matters - it opens the page in your browser and actually tests what it just built. If the form validation is broken, Claude sees it. If there is a console error after submit, Claude reads it. If the layout is off, Claude checks the rendered page. Then it goes back to the terminal, fixes the code, and retests. You sit back and watch the iteration happen. A concrete example from our own workflow: we asked Claude to add a new filter to a dashboard table. It wrote the component, opened the page, tried the filter, noticed the query params were not updating the URL correctly, fixed the router logic, and confirmed the filter worked with a page reload. Three iterations, zero context switches on our end. This works especially well when you are already logged into services that are annoying to authenticate programmatically. Stripe dashboard, Firebase console, OAuth-protected staging environments - Claude just uses your existing sessions. No test credentials, no auth scripting, no token refresh headaches. The alternatives we tried first Before settling on the Claude Chrome extension, we tried two other approaches. Neither stuck. Playwright MCP On paper, Playwright MCP is the more powerful tool. 33+ browser automation tools. Cross-browser support for Chromium, Firefox, and WebKit. Accessibility tree snapshots for token-efficient DOM interaction. In practice, it kept falling apart. The browser session would disconnect after extended use, throwing "Session not found" errors mid-workflow. Initialization would sometimes fail completely on first install, requiring a full restart of Claude Code. When a browser profile was already in use, browser_navigate would enter a retry loop and spawn five or six about:blank tabs before giving up. These are not obscure edge cases. They are documented issues (see anthropics/claude-code#6224, microsoft/playwright-mcp#1307, microsoft/playwright-mcp#1311). The stability problems span from mid-2025 through early 2026. The bigger issue: Playwright MCP spawns a fresh Chrome instance. No logins, no extensions, no cookies. You are starting from scratch every time. For local dev testing where you need your authenticated session, that is a dealbreaker on its own - even before the crashes. Playwriter; tools: Claude Code, Claude in Chrome. Human role: The original post does not say how a person stayed involved.; limitations: The setup is restricted to Chrome and Edge, lacks headless mode for CI/CD, and requires manual domain whitelisting. It does not support persistent test plans or team visibility, making it suitable only for individual developer workstation testing rather than systematic regression or production pipelines..
Tools
Published on Agent Work Atlas:
Overview
AI coding agents can write code.
Workflow
AI coding agents can write code. That part is solved. The part that was missing until recently: can they check their own work in a real browser? With Claude Code (or Claude Desktop) and the Claude for Chrome extension, the answer is yes. We have been using this setup daily for the past few weeks, and it has changed how we build. Claude writes code, opens localhost:3000 in your browser, clicks through the UI, reads console errors, and fixes what is broken. All in the same session, without you touching the browser. It is the tightest local dev feedback loop we have seen from any AI coding tool. But it comes with real tradeoffs - cost, scope, and stability - that are worth understanding before you adopt it. What the setup looks like The installation takes about two minutes: Install the Claude in Chrome extension from the Chrome Web Store Connect it to Claude Code or Claude Desktop: Claude Code (CLI): run claude --chrome or type /chrome inside an existing session Claude Desktop: the extension connects automatically when both are running Claude Code (CLI): run claude --chrome or type /chrome inside an existing session Claude Desktop: the extension connects automatically when both are running That is it. Claude can now see and interact with your browser. Both Claude Code and Claude Desktop work with the extension. We mostly use Claude Code because the terminal-to-browser loop is faster for development - write code, test in browser, fix, repeat. But if you prefer the Desktop app for general tasks or conversation-heavy workflows, the Chrome extension works there too. Same capabilities, same browser access. The key detail that makes this work: the extension shares your actual Chrome session. Your cookies, your logins, your local dev server - Claude sees exactly what you see. There is no separate browser profile, no headless instance, no credential management. You approve new domains through a whitelist the first time Claude tries to access them. After that, it can navigate freely within approved domains. The closed loop that makes this useful The workflow goes like this. You ask Claude to build a feature. It writes the code. Then - and this is the part that matters - it opens the page in your browser and actually tests what it just built. If the form validation is broken, Claude sees it. If there is a console error after submit, Claude reads it. If the layout is off, Claude checks the rendered page. Then it goes back to the terminal, fixes the code, and retests. You sit back and watch the iteration happen. A concrete example from our own workflow: we asked Claude to add a new filter to a dashboard table. It wrote the component, opened the page, tried the filter, noticed the query params were not updating the URL correctly, fixed the router logic, and confirmed the filter worked with a page reload. Three iterations, zero context switches on our end. This works especially well when you are already logged into services that are annoying to authenticate programmatically. Stripe dashboard, Firebase console, OAuth-protected staging environments - Claude just uses your existing sessions. No test credentials, no auth scripting, no token refresh headaches. The alternatives we tried first Before settling on the Claude Chrome extension, we tried two other approaches. Neither stuck. Playwright MCP On paper, Playwright MCP is the more powerful tool. 33+ browser automation tools. Cross-browser support for Chromium, Firefox, and WebKit. Accessibility tree snapshots for token-efficient DOM interaction. In practice, it kept falling apart. The browser session would disconnect after extended use, throwing "Session not found" errors mid-workflow. Initialization would sometimes fail completely on first install, requiring a full restart of Claude Code. When a browser profile was already in use, browser_navigate would enter a retry loop and spawn five or six about:blank tabs before giving up. These are not obscure edge cases. They are documented issues (see anthropics/claude-code#6224, microsoft/playwright-mcp#1307, microsoft/playwright-mcp#1311). The stability problems span from mid-2025 through early 2026. The bigger issue: Playwright MCP spawns a fresh Chrome instance. No logins, no extensions, no cookies. You are starting from scratch every time. For local dev testing where you need your authenticated session, that is a dealbreaker on its own - even before the crashes. Playwriter
Reported result
The workflow successfully reduced context switches during development, with one example requiring only three iterations to fix a dashboard filter. However, the author reports significant token consumption, noting that browser-heavy workflows can cost thousands of dollars on API pricing, making a subscription plan essential for viability.
Human role
The original post does not say how a person stayed involved.
Limitations
The setup is restricted to Chrome and Edge, lacks headless mode for CI/CD, and requires manual domain whitelisting. It does not support persistent test plans or team visibility, making it suitable only for individual developer workstation testing rather than systematic regression or production pipelines.
Try it
Act as a senior developer using Claude Code with the Claude in Chrome extension. My goal is to implement [replaceable feature, e.g., a new search filter] in my local app running at [replaceable URL, e.g., localhost:3000]. Steps: 1. Write the necessary code for the feature. 2. Open the page in my current Chrome session. 3. Interact with the UI to test the feature. 4. Check the browser console for errors. 5. If errors or UI issues are found, fix the code and retest. 6. Stop after one successful iteration and show me the result. Constraints: - Do not deploy or push to production. - Do not spend more than [replaceable token limit] tokens. - If the browser disconnects, stop and ask for help. Output: - A summary of the code changes. - A screenshot or description of the working UI. - Confirmation that console errors are resolved. Before starting, confirm you have access to my Chrome session and ask for the specific file paths if needed.
Source reports are not independently verified. Publication date is the catalog publication date, not the original article date.