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

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.

1. 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.

1. 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.

+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!

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

+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

+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.

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

+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.

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

This is a major usability issue for us, and actually has moved planning discussions out of Claude Desktop and into Codex.

+1

+1 My agent always attempts to render anyway.

Confirming this on Windows, and adding one detail: it isn't only the chat tab — the Files pane doesn't render mermaid either.

Claude Desktop 2.110.1.0, bundled Claude Code 2.1.271, Windows 11.

Tested with a markdown file open in the Files pane, preview mode on. Markdown tables render correctly in the same file, so the preview renderer is working; mermaid blocks specifically fall through to a plain code block. Four variants all failed: graph TD;, flowchart LR, sequenceDiagram, and an uppercase Mermaid info string. A plain Python block in the same file rendered as a normal code block, as expected.

The same mermaid source pasted into the chat tab also shows as code, so both surfaces are affected.

This matters for local markdown work, not just chat output: plan and design docs kept as .md in a repo can be read in the Files pane, but any diagram in them is unreadable without opening a third-party editor.

+1, confirming on macOS.

Environment

• Claude Desktop 2.2553.13 (Code tab), bundled Claude Code 2.1.280
• macOS 27.0 (26A428)

Behavior: ` `mermaid ` fences in assistant responses still appear as raw source in the Code tab transcript instead of a rendered diagram.

Why it matters for my workflow: My CLAUDE.md asks the agent to show a short Mermaid action plan before it edits files or runs external operations, so I can review the plan at a glance. In the Code tab that plan arrives as raw Mermaid syntax. I have to read graph syntax or paste it into another tool, which defeats the purpose. Rendering it in the transcript, with the Code/Preview toggle proposed above, would make that review step much faster.

+1, confirming on Windows

Environment

• Claude Code VS Code plugin
• Win 11

Behavior: ` `mermaid ` fences in assistant responses still appear as raw source in the Code tab transcript instead of a rendered diagram.

Why it matters for my workflow: I have asked Claude Code to display plans during the workflow by heavily relying on mermaid visualisation

I am surprised that this is missing from claude desktop. even if claude plans with mermaids are not considered, github readme files very commonly contain mermaid diagrams, and github, vscode etc all render them natively. claude should do the same as its a big part of generating docs, architecture diagrams, network diagrams, and algo flows.

+1 I used to have a reason to run multiple apps, and now the only one I can think of is that it doesn't render markdown/mermaid when I need to dive into the codebase

I need to be able to render mermaid in code mode. Thank you

Related use case that the current scope of this issue explicitly defers: Markdown files opened in the Claude Desktop file preview.

When a .md file containing ``` `mermaid ``` blocks is opened in the Claude Code tab's file view, the blocks are shown as raw source, same as AI responses today. For documentation-heavy repos (architecture docs, ADRs, READMEs) this is where diagrams actually live, so it would be great if the same renderer covered it, ideally with the Code / Preview toggle proposed above.

For reference, VS Code's Markdown preview solves this with a preview script rather than a markdown-it plugin (so the parser is untouched and the fenced block is replaced client-side by the rendered SVG). According to the README of mjbvz/vscode-markdown-mermaid, that extension has since been merged into VS Code 1.121. Behaviors worth borrowing:

• separate light/dark Mermaid theme settings that follow the app theme
• a cap on diagram source size (default 50,000 characters)
• pan / zoom / resize controls, with mouse navigation configurable (always / alt / never)
• the configurable set of fence language IDs treated as diagrams
• on a syntax error, the block stays as readable source instead of breaking the view

Sharing a single renderer between AI responses and file previews would also keep the two surfaces consistent.