Claude Design preview: artifact comments can't anchor to design elements — anchors collapse to editor-chrome selectors

Summary

In the Claude Design preview (the /design skill publishing a canvas editor as an Artifact), comment threads cannot anchor to the design content the user is actually commenting on. The user clicks/highlights a specific element inside an artboard, but the anchor that reaches the Claude Code session is a CSS selector into the editor's host DOM — typically editor chrome. The selection the user visibly made is discarded at the iframe boundary.

Observed behavior

On a real multi-artboard canvas (11 artboards, ~11 comment threads over two days):

• Five separate threads, each left on a different object in different artboards, all arrived with near-identical anchors of the form:

#root > div > div > main > div > div:nth-of-type(2) > div:nth-of-type(1) > button:nth-of-type(1)

• None of these selectors resolve to anything inside any artboard's DOM. They point at host-page/editor elements.
• Concrete cost: the responding Claude session answered a thread about the wrong object entirely (user: "No no no no.... we're not aligned. We're talking about different objects"), and a full design iteration was spent on the mixup. The user was highlighting/selecting the target element while commenting — the intent signal existed and was dropped.

Why it happens (as far as a session can see)

The design content renders inside the editor's sandboxed preview iframe (opaque origin, no allow-same-origin, postMessage-only). The comment tool belongs to the hosting artifact page, so its anchoring walks the host DOM and cannot see into the preview frame. The [anchored at] selector delivered to sessions via the Artifact comments action is therefore structurally incapable of naming a design element.

Why it matters

Comment-driven iteration is the primary loop for exactly the users Claude Design should serve: non-technical users who will never open a properties panel or edit source. They point at a thing and say what's wrong with it. Today that pointing is silently lost, and the workaround is asking users to write out an address in prose ("[Frame title → the block titled 'X']") — which works for technical users and is a real usability cliff for everyone else. The canvas editing experience is genuinely strong; this is the weakest link in the review loop around it.

Suggested direction

Bridge the anchor across the iframe boundary. The editor already knows, at comment time, which artboard is focused and can resolve the click target inside the preview document. Deliver to the session, alongside (or instead of) the host selector:

• the artboard file the comment landed on (e.g. Reconcile.dc.html),
• a stable path or source offset within that artboard's .dc.html, and/or
• the target element's visible text excerpt (the most robust key for a session to grep the source with).

Even artboard-file + text-excerpt alone would eliminate the entire failure class.

Environment

• Claude Code CLI 2.1.170 (VSCode extension environment, macOS 15 / Darwin 24.6.0)
• /design skill bundle 2.1.234, canvas runtime contract pin 0.1.31
• Comments read via the Artifact tool, action: "comments"

Filed by a Claude Code session on the user's behalf, from a live multi-session design workflow.