Claude Code is good at code. Ask it to rename a prop across a project or trace why an API call returns null, and it reads the right files and gets on with it. Ask it why the sidebar overlaps the footer on the settings page and it has a harder time. It has never seen the settings page.
That's not a model problem. Claude Code runs in your terminal and sees your files, command output and whatever you put in the conversation. The rendered UI is somewhere else. This post walks through the practical ways to show it what you're looking at, what each one actually sends, and when you're better off skipping all of them and debugging from the code.
What does Claude Code see by default?
Your repository, and the text you type. From those it can infer a lot. It can read a component, its styles and the layout around it, and reason about what they produce. For bugs where the code is plainly wrong, like a missing flex-wrap or a hard-coded width, that inference is enough.
Where it breaks down is when the cause is something only the browser knows: which of three similar components is on this page, which rule won the cascade, what the computed width actually is at this viewport, or whether a console error is stopping a component from rendering. For those, you need to bring the browser's view to the agent.
Can you just paste a screenshot into Claude Code?
Yes. Claude Code accepts images, so you can drag a screenshot into the terminal or paste one into your prompt, then describe what's wrong. This is the quickest way to start and needs no setup.
It's also the least precise. A screenshot tells Claude Code what the problem looks like, not where it comes from. It still has to guess the component from the picture and search for it. Two things help a lot:
- Include the URL and some visible text in your message. Text in the UI is often a string in your source, which gives the agent something exact to search for.
- Crop to the problem, and say what "right" looks like. "This row should line up with the header above it" beats "this looks off".
How can Claude Code look at the page itself?
Give it a browser through MCP. With a browser server connected, Claude Code can open your localhost URL, inspect the page, read the console and take its own screenshots. Two common options:
- Playwright MCP from Microsoft. Add it with
claude mcp add playwright npx @playwright/mcp@latest. It mainly works from the page's accessibility tree, which gives the agent structured text about each element rather than pixels. - Chrome DevTools MCP from the Chrome team. It lets the agent drive a live Chrome window, take screenshots, read console messages with source-mapped stack traces, look at network requests and record performance traces. Its README has the current install steps for Claude Code.
This is the right choice when you want Claude Code to check things on its own: reproduce a bug by clicking through a flow, confirm the console is clean after a change, or look at the page at a few widths. It's slower when you already know exactly which element is wrong, because you end up describing it in words so the agent can find it again in its own browser session.
How do you point Claude Code at one specific element?
Use a tool that runs in your page and captures context when you click. There are two styles.
Copy and paste. On React, React Grab lets you hover an element and press Cmd+C to copy it along with its component stack and source locations. You paste that into Claude Code with your request. It's precise and free, and limited to React.
Click and send. PulseDev, which we make, takes this one step further. A script tag on your dev page adds a button; you click the element, type the fix, and PulseDev runs Claude Code in your project with the context attached. It sends the selector, page URL, markup, computed styles, matched CSS rules, recent console errors and an element screenshot. In review mode, PulseDev asks Claude Code for a proposed diff rather than file edits. You read the proposal on the page and press Approve to apply it.
Under the hood it starts Claude Code in non-interactive mode in your project folder, using the login you already have, so there's no API key to set up. It works on any stack that serves HTML on localhost, because it reads the DOM rather than a framework's internals. The flip side is that it doesn't send component names yet; the agent finds the file from the classes, text and rules it's given. The same flow works with Codex and Gemini CLI if you use those instead.
When is code-first debugging still faster?
Visual context is for problems you can see. Plenty of UI bugs aren't really visual:
- Data and state bugs. The list is empty because the fetch failed or a filter is wrong. Point Claude Code at the data flow, the API route and the logs. A screenshot of an empty list adds nothing.
- You already know the file. If you wrote the component this morning, open it with Claude Code and describe the change. Pointing at it first is an extra step.
- Sweeping changes. "Replace every hard-coded grey with the new token" is a search-and-edit job across the codebase, not an element-by-element one.
- Build and type errors. These come with file names and line numbers already.
A useful rule: if you'd normally open DevTools to understand the bug, give the agent visual context. If you'd normally open your editor, start from the code.
What does a combined workflow look like?
Most days end up using more than one of these. A pattern that works well:
- Do a pass through the page you're polishing and point at each thing that's off, one note per problem. Each note carries its own element context.
- Review the diffs as they come back. Approve the good ones, reply on the ones that are close, reject the ones that took the wrong approach.
- For anything behavioural, like a modal that won't close, switch to Claude Code directly, with a browser MCP server so it can reproduce the issue.
- Before committing, ask Claude Code to check the console on the pages you changed.
If you'd rather drive everything from Claude Code, PulseDev also exposes an MCP server. Connect it and Claude Code can list the notes you left on the page and work through them in one session. The editor docs show the config it writes, and the agent guide covers how PulseDev runs Claude Code.
