Add browser rendering / DOM inspection capability to Claude Code

Preflight Checklist

• [x] I have searched existing requests and this feature hasn't been requested yet
• [x] This is a single feature request (not multiple features)

Problem Statement

Claude Code currently has no built-in way to render HTML/JS output in a real browser, inspect the resulting DOM, or verify visual output. For tasks that produce or modify web UIs, this forces the user into a manual loop: switch to a browser, eyeball the result, screenshot, describe the problem back to Claude. Claude itself remains blind to what it just produced, which breaks the feedback loop on every iteration.

Meanwhile, Claude.ai + Chrome Extension does have this capability but lacks the local filesystem / CLI / API access that Claude Code provides. Neither environment is complete on its own, forcing users to run both in parallel and manually sync context between them.

Proposed Solution

A headless browser tool (Playwright or Puppeteer) that Claude Code can invoke to:

• Render a URL or local HTML file
• Capture a screenshot (returned as image Claude can actually see)
• Query the DOM (e.g. document.querySelector('.foo').innerText)
• Inject and evaluate short JS snippets
• Capture console logs so JavaScript errors surface back to Claude

Results returned as image + structured DOM snippet + console output. This closes the verification loop for any task that produces web UI.

Alternative Solutions

In descending order of preference if the full headless-browser approach is too heavy:

1. MCP server for browser control — expose navigate / click / screenshot / eval / getText via the standard MCP interface, usable like any other MCP tool. Keeps the capability out of core and modular.
2. Bridge to an already-running browser session — similar to what the Chrome Extension does for Claude.ai, so auth and cookies are reused from the user's existing session. Important for on-premise tools behind corporate auth (which WebFetch can't reach).
3. Screenshot-only tool as a minimum viable version — even a one-way "take screenshot of URL X" with no interaction would already solve 60% of the verification pain.

Priority

Medium - Would be very helpful

Feature Category

CLI commands and flags

Use Case Example

Priority

Medium.

Not blocking — there is a workaround (run Claude.ai + Chrome Extension and Claude Code in parallel, hand-sync via a markdown file). But the workaround is fragile and visibly slows down any UI-related task, and competing coding-agent tools already ship this (Cursor, Aider with browser-use, etc.), so Claude Code is noticeably behind on this specific capability.

---

Use Case Example

I'm building an HTML/JS dashboard for PRTG Network Monitor (on-premise monitoring tool). The dashboard is embedded in a PRTG Map object and renders live sensor states via the PRTG JSON API.

What Claude Code handles well today:

• Reading/writing the dashboard HTML/JS/CSS files locally
• Calling the PRTG REST API via PowerShell helpers
• Editing sensor configurations via the PRTG API (divisors, channel units, duplicating sensor definitions across devices)
• Refactoring the code, source control

Where Claude Code is stuck today:

• After editing the dashboard HTML, neither Claude nor I can see the rendered result from within the session.
• I manually paste the code into PRTG's Map editor, open the Map in a browser, screenshot the output, describe problems back to Claude. Every iteration is ~2–3 minutes of human copy-paste work per change.

Claude.ai + Chrome Extension can render and inspect the live Map, but it has no access to my local source files or the PowerShell/API helpers I've built up in this project. So I end up running both in parallel with a ~230-line handover markdown file that exists solely to keep both Claudes in sync.

Additional Context

• Broader relevance beyond my one case: on-premise / authenticated internal web apps (dashboards, admin UIs, monitoring tools) are a very common target. WebFetch can't reach them, and even where it can, raw HTML without a rendered DOM is of limited value — the app's state lives in JavaScript-rendered elements.
• Nice-to-have extensions: viewport parameter (mobile / desktop) for responsive checks; console log capture; optional interaction (click, type) for flows that require auth or navigation before the target view is reachable.
• Not in scope of this request: replacing Claude.ai's Chrome Extension for general browsing — the ask here is specifically about giving Claude Code the means to verify UI work it has produced, not to browse the web.

---

Submitted by a user who currently splits time between Claude.ai + Chrome Extension (for browser work) and Claude Code (for filesystem + API work) on the same project.