[Claude Desktop] Mermaid code blocks not rendered in Claude Code tab

[Sarozs2863]

Related Work

Related to #14375 but scoped differently:

• [FEATURE] Introduce Mermaid rendering support in Claude Code for outputting diagrams/charts #14375 targets the terminal TUI (Claude Code running in iTerm/Ghostty/etc.) and proposes ASCII rendering via mermaid-ascii
• This issue targets the GUI host — the built-in Claude Code tab inside the Claude Desktop app — where native SVG rendering (mermaid.js) is feasible and should produce a much better experience than ASCII fallback

Environment

• Claude Desktop with the built-in Claude Code tab

Current Behavior

In the Claude Code tab within Claude Desktop, when the AI response contains a mermaid-tagged fenced code block (triple backticks with the mermaid language identifier), it is displayed as raw source text instead of being rendered into a visual diagram.

Expected Behavior

Mermaid code blocks in AI responses should be rendered as diagrams, consistent with the claude.ai web experience.

Scope (MVP)

Render only mermaid blocks from AI responses. Other sources (file reads, Bash tool output, user input) can be handled in later iterations — AI responses cover the primary use case.

UI Suggestion

Adopt a Code / Preview toggle similar to Claude.ai artifacts, defaulting to Preview:

• Preserves the ability to copy or inspect the source (useful for debugging / re-using the diagram elsewhere)
• Matches existing Anthropic product interaction patterns, so users have no mental-model switching cost
• Satisfies the core need (seeing the diagram, not the source)

Why this matters

Mermaid is a common format for architecture diagrams, flowcharts, data-flow diagrams, and sequence diagrams in AI-assisted workflows. Not rendering them in the Claude Code tab breaks parity with claude.ai and forces users to copy the source into an external tool (mermaid.live, Obsidian, etc.) to visualize — which disrupts the flow of the conversation the tab is designed to support.

[mr-phariyawit]

Still highly relevant — would appreciate this being prioritized over the stale label.

Mermaid is becoming the de-facto format for AI-generated structural output
(architecture diagrams, sequence flows, state machines, dependency graphs).
Modern AI assistants emit them frequently, and other chat UIs (claude.ai web,
ChatGPT, GitHub PR/Issue render, VS Code with bierner.markdown-mermaid)
already visualize them inline.

In the Claude Code tab today, those same blocks display as raw text, which:

1. Breaks parity with claude.ai web — same model, same output, very different
   reading experience depending on where you happen to be running it.
2. Forces an out-of-context detour (copy → mermaid.live → paste back) that
   defeats the chat UI's main value proposition: keeping the thought
   in-place.
3. Trains users to avoid asking for diagrams in this surface at all,
   because the response is unreadable here. That's a quiet
   capability-loss, not a neutral one.

Suggested minimum viable scope:

• Detect ```mermaid fenced blocks
• Render via the same mermaid pipeline claude.ai web uses
• Keep "view source" affordance so the original code remains accessible
  (toggle, click-to-expand, or hover button)

Happy to test a beta build if there's an internal flag.

[digitaldias]

+1 We need this too. Important ability to display diagrams. They save on token space and are easier for humans to understand. Hope to see this happen soon!

[alexbojko]

+1 to this issue. Highly valuable feature unfortunately doesn't work

[vynnlee]

+1 I use Mermaid quite a bit, and having to copy the code into another tool just to see the diagram gets old pretty quickly

[phpmac]

+1 — cross-client consistency matters. The same ```mermaid block renders on
claude.ai web but not in the Desktop Code tab or the CLI. Whatever the
solution lands on (#64643 passthrough for CLI, #13600 renderer), Desktop
should reuse it so behavior is identical across web / desktop / CLI. Right
now the same model response produces different output depending on which
surface the user is in, which is confusing and breaks shared workflows.

[Konigj]

+1. We don't want to open other apps to visualize our mermaid flows (eg Cursor).

[alexargb]

+1 and adding evidence measured with Opus 5 after having to put effort on a workaround using a CDN.

The renderer already ships in this app. Published artifacts draw ```mermaid fences and
<pre class="mermaid"> blocks natively, with no external library. I confirmed this today by publishing a
page with flowchart, ER and sequence diagrams and they all rendered. So this is not "add Mermaid to the
desktop app", it is "reuse the renderer already in the binary on a second surface". That should be a much
smaller change.

What the gap costs in tokens. I measured this while building the workaround. Getting one diagram into a
chat message today means emitting a widget that loads Mermaid from a CDN, and the wrapper has to be re-sent
on every call because nothing persists between tool calls:

Diagrams	Widget with CDN Mermaid	Plain ```mermaid fence	Saving
1	~286 output tokens	~60	79%
2	~346	~120	65%
3	~413	~180	56%

The alternative is a hand-positioned SVG, roughly 450 tokens per diagram, where the model computes every
coordinate and gets the layout wrong often enough to matter. Those are output tokens, spent on every diagram
for every user who asks for one (like me).

The workaround has a supply-chain cost. To make it work today I pinned mermaid to an exact version
from a public CDN with a sha256 integrity hash, and audited it (0 advisories across 111 packages, no
network APIs in the bundle, DOMPurify present) because the supply-chain attacks are still a threat that I'd rather avoid. That is
a real cost imposed by the renderer not being reachable from chat.

Details worth deciding, since they are where this kind of feature could stall:

• Streaming. A partially streamed fence is invalid Mermaid. Draw on fence close, show source until then,
  the same way code blocks already wait before highlighting.
• Syntax errors. Degrade to the source text. Never an error box, never blank space.

Extra UI recommendation.

• Theme. Redraw on light/dark switch. The app owns the renderer so it can, which is impossible inside a
  sandboxed widget. I had to pin diagrams to a fixed light theme purely to avoid losing
  contrast.

[sumedhe]

+1 to have this feature. It already there in the claude chat, so better to have it in markdown also.