Claude Code Desktop lets you click DOM elements directly in the app instead of verbally describing which component needs editing.
The feature captures HTML tags, CSS classes, computed styles, parent/sibling elements, and screenshots for complete visual and code context.
React apps receive extra data: source file paths, component names, and props - bridging the gap between rendered UI and source code.
Unlike DevTools inspection, Claude understands intent and can edit components directly based on what you click and point to.
There is a moment in every front-end workflow where you stare at a component on screen and try to describe it in words. "The button - no, not that one - the one in the hero section, third row, with the gradient border." It is a strange tax we pay: translating something visual into something verbal, just so a tool can translate it back into something visual again.
Claude Code Desktop just eliminated that entire step. You can now select DOM elements directly in the app, point at the thing you want changed, and Claude understands exactly what you mean. No describing. No guessing. Just click and edit.
What the DOM Selection Feature Actually Does
Lydia Hallie, a well-known developer advocate who has built a reputation for clear, practical web development content, shared the feature on social media. The explanation is straightforward: Claude Code on desktop lets you select DOM elements directly, which is much easier than describing which component you want updated.
When you click an element, Claude receives a package of context about it:
The HTML tag - whether it is a button, div, section, span, or any other element
CSS classes - every class applied to that element
Key styles - the computed styles that define how it looks
Surrounding HTML - the parent and sibling elements for structural context
A cropped screenshot - a visual capture of the element as it appears on screen
That last one matters more than it might seem. The screenshot gives Claude visual context that pure code never can. It sees what you see. It understands not just the markup but the rendered result.
React Apps Get Even More
If you are working in a React application, the feature goes deeper. On top of all the standard DOM information, Claude also receives:
The source file path - the exact file where the component lives in your project
The component name - not just the rendered HTML tag, but the React component that produced it
Props - the data being passed into that component
This is a significant jump. In a typical React project, the rendered DOM and the source code can feel like two different worlds. A single component might render dozens of nested elements. A styled button might live three directories deep in a design system. The gap between "what I see in the browser" and "where that lives in my code" is real, and it costs time every single day.
With this feature, clicking a button in your app does not just tell Claude about a button element. It tells Claude about the PrimaryButton component in components/ui/PrimaryButton.tsx, with its variant="outline" and size="lg" props. That is the difference between a hint and a complete instruction.
Why This Is Better Than Developer Tools
The obvious comparison is browser DevTools. Developers have been inspecting elements since Firefox first shipped Firebug. Chrome DevTools lets you hover over any element, see its box model, computed styles, event listeners, and the full DOM tree. So what does Claude Code Desktop add?
The answer is intent. DevTools shows you information. Claude Code Desktop acts on it.
When I inspect an element in Chrome, I get a wall of CSS properties, inherited styles, and box-model dimensions. I then have to interpret that information, find the right file in my editor, locate the right selector or component, and make the change myself. It is a research tool, not an editing tool.
Claude Code Desktop collapses that entire chain. I click the element. Claude knows what it is, where it lives, and what it looks like. I say "make the padding larger" or "change this to a gradient background" and the edit happens in context. The AI is not just reading the DOM - it is connected to the codebase and can write the change.
There is also the accuracy factor. When I describe a component in words, there is always room for misinterpretation. "The card with the border" could match five different elements on the page. "The heading in the pricing section" might be ambiguous if there are sub-headings. Pointing removes ambiguity entirely. It is the most natural form of reference humans have - we point at things before we learn to name them.
Effort Levels in Skills
Alongside the DOM selection feature, Claude Code also introduced configurable effort levels for skills and slash commands. You can now set how long the model thinks before answering, with options ranging from low to high thinking time. This overrides your session default, so you can use quick responses for simple tasks and deeper reasoning for complex architecture decisions.
This is a practical addition. Not every question deserves the same amount of computation. Renaming a variable does not need the same thinking depth as refactoring a state management system. Being able to dial that up or down per command means faster responses when speed matters and thorough analysis when accuracy matters.
The combination of these two features - visual element selection and adjustable thinking depth - points toward a workflow where the tool adapts to how you actually work, rather than forcing you into a single interaction mode.
How This Changes the Design-to-Code Workflow
I have spent nearly 20 years in visual design. The gap between design tools and code editors has always been the most frustrating part of the process. You design something in Figma, then you rebuild it in code, then you tweak it in the browser, then you go back to the code to make those tweaks permanent. Every transition between visual and textual is a context switch that costs focus and time.
DOM element selection in Claude Code Desktop is the first feature I have seen that genuinely bridges that gap in the right direction. Instead of going from visual to textual and back, you stay visual. You look at your app. You see something that needs to change. You click it. You describe the change in plain language. It happens.
For someone like me who thinks visually first and in code second, this is how the workflow should have always been. I do not want to grep through a codebase to find a component. I want to point at it. I do not want to describe an element's position in the layout hierarchy. I want to click it and say "change this."
This also has implications for design review workflows. Instead of writing detailed feedback documents that describe which elements need adjustments, you could walk through a page, click each element, and state the change. The feedback loop gets shorter. The margin for miscommunication shrinks.
What This Means for Component Libraries
If you maintain a design system or component library, the React-specific features are particularly relevant. Knowing the component name, source file, and props means Claude can suggest changes at the right abstraction level. It will not just modify a style on one instance - it can identify that the element comes from a shared component and propose the change at the source.
This is something even experienced developers get wrong manually. You see a visual issue, you find it in the DOM, you add a CSS override in the wrong place, and now you have a specificity conflict. The component-level awareness in Claude Code Desktop helps avoid that pattern because the tool understands the architecture, not just the output.
My Take
I build things every day in this studio - Shopify sections, React components, landing pages, product interfaces. The workflow always involves visual decisions that need to become code changes. Being able to point at something on screen and say "make this different" is not just a convenience feature. It is a fundamental shift in how the conversation between designer and tool works.
The effort level controls are a nice complement. Quick fixes get quick responses. Structural changes get deeper reasoning. Together with DOM selection, these features move Claude Code Desktop closer to being a tool that works the way creative people actually think - visually, directly, and without unnecessary translation layers.
This is still early. The feature will get better as it handles more frameworks, more complex component trees, and more edge cases. But the direction is right. The best tools are the ones that remove steps from your workflow without adding new ones. Claude Code Desktop just removed one of the most annoying steps in front-end development: describing what you can already see.
This article contains affiliate links. If you sign up through them, I earn a small commission at no extra cost to you.
Top comments (0)