Element picker for the Sidebar Browser: select on the page, prompt the agent (Cursor-style design mode)

[PiTZE]

The gap

The Sidebar Browser shows pages, but there is no path from "this element looks wrong" to an agent prompt. Today that trip is manual: open devtools, copy a selector or snippet, describe the spot in words, hope the agent finds it. For frontend work this is the slowest part of the loop, and it stays slow no matter how good the model gets.

The ask

A pick mode in Browser tabs: click an element, see it highlighted, and attach its context (selector, DOM snippet, screenshot) to the composer as a draft attachment or session reference, then prompt from there. Cursor's design mode is the reference interaction.

Suggested shape

• Picker overlay owned by the sidebar browser tab type, emitting a selection (selector + snippet + screenshot) into the existing attachment/session-reference pipeline rather than a new context channel.
• Scriptable targets only: same-origin and loopback pages. Cross-origin iframes stay opaque by browser law, so frame-protected sites are an explicit non-goal for the tab itself.
• Agent side: route observation and act/verify through the existing browser-use provider seam (Playwright / Chrome DevTools / Stagehand MCP), which already own tool schemas and result rendering.
• Later extension path: a companion content script in the spirit of the dsh-browser extension (dsh-browser: Chrome sidebar extension that lets DSH operate your browser directly—no vision capabilities required. #165) could bring the same picking interaction to the user's real Chrome tab, where frame protection does not apply.

Happy to iterate on the slot shape or drop the proposal entirely if the maintainers would rather design the seat differently. The goal is the capability: point at the web, prompt about it.

[TheStreamCode]

Supporting this request, with implementation notes from the 0.2.1-rc.2 source (687f282e).

What blocks a plugin today:

1. No slot inside the Browser body. sidebar.right.pane.tab is keyed by tab type, and BrowserBody renders the toolbar plus one empty viewport div; it declares no children, so a picker cannot mount inside the shipped tab.
2. No public browser-tab service. BrowserController, BrowserFrame and the store are package-private; the /client entry exports only apply, inject and types. A plugin can open a tab (ctx.sidebarRight.openTab('browser', { params: { url } })) but cannot read its target, evaluate in it, or capture it.
3. The two carriers differ. On Web the page is a sandboxed cross-origin iframe and the DSH origin is rejected as a target, so even loopback pages are cross-origin; injection is impossible. On Desktop the page is an Electron <webview> with a stripped preload, sandbox: true and contextIsolation: true, so there is no guest-to-host channel. The host page can call webview.executeJavaScript() and webview.capturePage(), but only by finding webview[data-sidebar-browser-frame], an undocumented DOM detail with no tab identity (inactive tab bodies stay mounted hidden).
4. The composer path is mostly there. ctx.conversation.input.for(ctx.sessions.scope(id)) supports setDraft and addAttachments, and InputActions.insertText inserts text without replacing reference chips; setDraft replaces them. Image attachment ids can only be minted by ConversationController.createDrafts, which is not on IConversation, so text context is shippable today but screenshots are not.

Minimal ask, in order of value:

1. A declared child slot in the Browser body (toolbar action and overlay host), so a picker ships as a plugin instead of patching a builtin package.
2. A public browser-tab service exposing tab identity, target URL, executeJavaScript and capturePage for the Desktop carrier. This also covers the same-tab tooling request in Public native sidebar APIs for persistent sessions, downloads and same-tab tools #9909.
3. createDrafts (or an addImage) on IConversation / SessionInput.
4. A documented position on Web: the iframe carrier cannot be instrumented cross-origin, so plugin authors should know that a streamed Host browser is the only Web path.

With (1) and (2), a picker that emits selector, snippet, styles and screenshot into the existing draft pipeline is a normal plugin, and the same seat serves the region-selection workflow requested in #9393.