Feature request for product/service
Cursor IDE
Describe the request
Cursor’s built-in browser element selector is useful, but in component-based apps it currently works at the DOM level. For Vue, React, Svelte, Angular, etc., the thing developers usually want is not just the selected DOM node, but the framework component that rendered it.
It would be very useful if Cursor’s Browser could integrate with framework devtools-style component inspection so that selecting an element can resolve the owning component and make it available as chat context.
For example:
- In a Vue app, selecting an element could identify the nearest Vue component instance, such as
CategorySection.vue. - In a React app, selecting an element could identify the owning React component, such as
BarChart.tsxorResearchPanel.jsx. - Cursor could then offer an action like “Add component to chat”, equivalent to manually typing
@src/path/Component.vue. - The selected browser context could include the component name, source file path, props, route, and relevant DOM snapshot.
This would make browser-driven debugging and UI iteration much faster. Today, when I inspect an element in the Cursor browser, I still need to manually work out which Vue/React component owns it, then find and@that file myself. Framework devtools already solve this problem in the browser, so bringing that same component awareness into Cursor’s Browser would make the browser-to-agent workflow much more precise.
Suggested behavior:
- User opens the app in Cursor Browser.
- User uses element picker and clicks a UI element.
- Cursor resolves the framework component tree for that DOM node.
- Cursor shows the owning component and source file path.
- Cursor allows adding that component, parent components, or related files directly to chat context.
Possible implementation ideas:
- Use framework devtools hooks where available, such as Vue DevTools / React DevTools integration.
- Fall back to source maps, component display names, DOM markers, or route/module metadata.
- Expose the selected component as a first-class context item, similar to
@Browseror@file. - Allow extensions or MCP tools to contribute “component resolver” providers for custom frameworks.
This would be especially helpful for prompts like:
“Update the component for the element I selected in the browser.”
or:
“Why does this selected button have the wrong spacing?”
Instead of the agent having to infer the source file from DOM/classes/text, Cursor could directly attach the actual framework component responsible for the selected UI.
Any thoughts or questions please let me know!