💭 Looking at the PR changes, I see it's adding a parseRawHtml prop to ChatMarkdown that disables rehype plugins when set to false and allows raw HTML through. The issue is that setting rehypePlugins={undefined} would strip out all plugins—not just rehypeRaw and rehypeSanitize, but also critical ones like syntax highlighting and KaTeX rendering that handle important UI functionality. When parseRawHtml is false, rehypePlugins become undefined so rehypeRaw doesn't execute, leaving HTML nodes that react-markdown renders as escaped text. The sanitize schema gets dropped too, but that's not a problem since raw HTML never makes it through in the first place. I'm wondering if the sanitize schema serves another purpose beyond filtering HTML. Remark plugins add data attributes via node.data.hProperties that get passed to the hast tree, and rehypeSanitize would normally strip disallowed attributes. Without sanitize, those attributes pass through unchanged—so removing it actually allows more attributes, not fewer. The test expects <code data-inline-code=""> to be present, which works fine. Without sanitize, everything's allowed, so custom components get the attributes they need. The real shift is that with parseRawHtml=false, any HTML in user messages that was previously sanitized now stays as literal text instead. Now I'm checking UI consistency—shared components, Tailwind, CSS, themes, layout—but this PR is really about markdown rendering behavior, not styling. The behavioral risk centers on skipHtml={false} and how react-markdown handles raw HTML nodes when remark-rehype is configured with allowDangerousHtml. Checking the rendering logic... I need to verify whether skipHtml is still available in react-markdown 10, since I recall it being removed in a recent version update. I'm checking whether react-markdown v10 still supports the skipHtml option by reviewing the available props, and I'm fairly confident it does, though I'd like to verify this by looking at the actual types or searching for existing usages in the codebase. Now I'm thinking about how raw HTML nodes are handled in v10—there's a transform function that checks if a node is of type raw, and if skipHtml is enabled, it removes that node from the parent's children; otherwise it converts it to a text node. This logic should still be present in v10. The real concern here is a UI consideration: without the rehypeSanitize plugin, the title attribute filtering is lost for user messages. In the previous setup, the sanitize schema stripped title attributes globally to prevent native browser tooltips from conflicting with the app's custom Tooltip UI. In a markdown pipeline without sanitization, title attributes can still come from markdown link and image syntax like [text](url "title"), which produces elements with title attributes that would now be preserved. This creates an inconsistency—user messages would show native browser tooltips while assistant messages wouldn't, which breaks the consistent interaction pattern the app was designed for. I should check the git history to understand why title was originally filtered, and also verify that markdownUrlTransform properly blocks javascript: protocol hrefs since the sanitize plugin's protocol restrictions would no longer apply. I need to look at that commit to see what caused the title to be removed. I'm checking whether removing the sanitize plugin affects how user messages render compared to assistant messages, particularly around title attributes on links and images that come from markdown syntax—these would show as native browser tooltips in user messages but not in assistant messages, and I need to see how the custom markdown components handle the a and img elements. I should also verify that other attributes like class names and URL protocols are handled consistently, since the default schema already allows certain classes on code elements and URL transforms handle protocol validation anyway. Let me search the ChatMarkdown component to see if title attributes are actually used in the component mappings. The title filter is a deliberate UI choice to suppress native tooltips in favor of the app's custom Tooltip component, but with parseRawHtml=false the sanitization step gets skipped entirely. This means markdown link and image titles in user messages would now show native tooltips, creating an inconsistency with how assistant messages render them. Let me verify whether the markdown components for a and img elements actually spread the title prop through. The spread operator is passing the title attribute through, so user message links with markdown titles show native tooltips while assistant messages don't—a minor inconsistency from removing the entire rehype chain instead of just rehypeRaw. I'm weighing whether this falls under the UI consistency check scope, which focuses on the shared component system, Tailwind ownership, and behavior constraints, particularly around preserving accessibility and interaction semantics during migrations. The sanitize schema's title filter seems like it might be a deliberate UI decision between native tooltips and app tooltips, so I should check the commit diff for that specific line to see if there's any context or reasoning behind it. Considering whether the title attribute inconsistency is significant enough for this UI-consistency check—the native browser tooltip on user-message links conflicts with the app's custom Tooltip component that displays hrefs for external links, creating a concrete interaction and visual inconsistency introduced by the change. The mdast-util-to-hast converter does set title from markdown syntax like [x](url "tip"), so this finding holds for both links and images. I'm also checking whether removing sanitization introduces other regressions: raw HTML isn't parsed in user messages, but markdown image syntax renders <img> elements in both modes anyway since they're allowed by the default schema. URL transformation still handles protocol validation safely even without the sanitizer, and className stripping behavior differs but remarkGfm plugins might introduce additional considerations here. The real issue is that dropping all rehype plugins is too blunt — a better approach would keep rehypeSanitize while only toggling rehypeRaw, since the sanitizer enforces the schema's attribute policies consistently. But there's a catch: if rehypeSanitize runs without rehypeRaw, it would actually drop raw HTML nodes entirely rather than escape them, which defeats the purpose of the PR. So the fix isn't as simple as just keeping sanitize enabled. The actual solution would be to either strip the title attribute at the component level, apply sanitize after converting raw nodes to text, or have the link component ignore the title prop — though each adds its own complexity. The concrete issue here is real though: users now see both a native browser tooltip from the title attribute and the app's custom tooltip, creating duplicate and conflicting UI. Let me check the external-link Tooltip implementation to nail down the specifics of this inconsistency. So the external links with tooltips are creating a duplicate tooltip issue because the title attribute gets passed through when sanitization is skipped. The skipHtml={false} default is harmless and just documentation. I'm also thinking through whether there are other UI problems in the diff—in literal mode, raw HTML becomes text nodes, though the raw node value seems to be cut off mid-thought. Looking at the markdown components, the details component is fine. The escaped text like <img ...> displays as raw text as expected per the issue. The copy behavior with chatMarkdownClipboardPayload isn't affected by these changes. Considering the accessibility rules about preserving interaction semantics and the duplicate tooltip problem, I think reporting this finding with a fix makes sense—the simplest approach would be to drop the title attribute in the a renderer or strip title props when not sanitized, maybe by destructuring it out in the component. Since assistant mode already strips it via sanitize, removing title unconditionally at the renderer keeps both modes consistent. Images are a bit trickier since there's no custom img component override, so image titles would pass through in user messages, but that's a minor edge case. I'm wondering if I should apply the sanitize pass in literal mode too, but that would remove raw nodes. Let me think through how hast-util-sanitize handles raw nodes—it switches on node type and removes unknown types, so raw nodes would get stripped. The key thing is that react-markdown's raw-to-text conversion happens after rehype plugins run, so the order matters: remark processes first, then rehype plugins, then react-markdown's own processing on the final tree. So if I apply sanitize before the raw-to-text conversion, it would delete the raw nodes entirely. The cleanest approach would be a rehype plugin that converts raw nodes to text first, then sanitizes. But given the need for the smallest expected fix, I think stripping title in the anchor renderer is the most straightforward solution, though I should note the img case too. The real question is whether a reviewer would push back on this being too minimal—title tooltips on user links are pretty trivial, and the instruction says not to fail for optional aesthetic preferences. Let me trace through what else might change if I drop sanitize entirely. The parseRawHtml default is true in MessagesTimeline, but other components like SkillInlineText or the composer haven't changed. GitHub alerts and code metadata rendering should be fine since those attributes were already allowed. For footnotes, remarkGfm generates data attributes that are fine, and the default schema does allow id on certain elements with the clobberPrefix handling for user-content prefixes. But here's the thing — without sanitize, footnote ids won't get that user-content prefix, so the same footnote anchor could collide across different messages in the DOM, and fragment links would resolve inconsistently between user and assistant messages. It's a niche issue but a real one. The id-clobbering is actually significant since sanitize normally prefixes id attributes with user-content, and I need to check what mdast-util-to-hast actually generates for footnote link hrefs by default. I should report this title finding. The check defaults to failure unless I mark it "All clear," so since I found an issue, I need to post it and fail the check. But first let me verify whether defaultSchema's wildcard attribute list actually includes title. Looking at the different versions of hast-util-sanitize to understand how the default schema has evolved, particularly around which attributes are allowed on elements like a and what's permitted globally on all elements... The key finding is that user-message links and images are now preserving markdown titles, which creates native browser tooltips, but the sanitization schema deliberately strips the title attribute everywhere else — and on external links this causes a double-tooltip issue where both the native tooltip and the Base UI tooltip appear showing the href. I'm planning to add an inline comment at ChatMarkdown.tsx line 1798 to document this behavior. The issue is that skipping the rehype chain removes rehypeSanitize, which filters out the title attribute. When parseRawHtml={false}, markdown links with titles like [text](url "tip") now pass the title directly to the anchor element, creating unwanted native tooltips in user messages that conflict with the existing Base UI tooltip. I could fix this by keeping the sanitize step in literal mode—converting raw nodes to text first, then running sanitization—to strip the title attribute consistently. The analysis feels solid and actionable. I'm going to post this review.

1. modify_pr — One consistency issue found in the parseRawHtml switch: disabling the whole rehype chain also disables the sanitize schema, which is the only thing enforcing the project's no-native-title policy on rendered markdown. See the inline comment.