[BUG] Inline KaTeX math (`$...$`) no longer renders in chat output — only block `$$...$$` works (regression)

Found 3 possible duplicate issues:

1. https://github.com/anthropics/claude-code/issues/36576
2. https://github.com/anthropics/claude-code/issues/50569
3. https://github.com/anthropics/claude-code/issues/36742

This issue will be automatically closed as a duplicate in 3 days.

• If your issue is a duplicate, please close it and 👍 the existing issue instead
• To prevent auto-closure, add a comment or 👎 this comment

🤖 Generated with Claude Code

Analysis: Inline KaTeX $...$ Rendering Regression

Root Cause Analysis

This is almost certainly a KaTeX auto-render delimiter configuration regression. When inline $...$ fails to render but block $$...$$ works, the most common causes are:

1. renderMathInElement delimiter config missing inline delimiters

The typical KaTeX auto-render call looks like:

renderMathInElement(element, {
  delimiters: [
    {left: '$$', right: '$$', display: true},
    {left: '$',  right: '$',  display: false},  // ← this line missing
  ]
});

If a recent change removed the {left: '$', right: '$', display: false} entry (or the entire delimiters array was overwritten to only include $$), inline math stops rendering immediately while block math continues to work.

2. Escaping conflict in the markdown preprocessor

Some markdown renderers pre-process $ signs (treating them as literal dollar amounts or as part of other syntax). If a new escaping rule was added that consumes or transforms single $ before KaTeX sees them (e.g., escaping $ to \$ or wrapping in <code>), KaTeX would never see the delimiters. Block $$ is less susceptible because it is less ambiguous (two consecutive dollars rarely appear outside math).

3. Regex change in the math-detection splitter

Many markdown renderers split text into "math" and "non-math" segments using a regex like:

/\$\$([\s\S]*?)\$\$|\$([\s\S]*?)\$/g

If the inline $ capture group was accidentally removed or the regex was simplified to only match $$, inline math would break.

4. Desktop app's webview configuration differs from terminal

The desktop app (macOS) uses an Electron webview. If the KaTeX initialization for the webview was updated separately from the terminal renderer, or if a CSP/content-security change blocks inline KaTeX resources, this could explain why it regressed only on desktop.

Diagnostic Checklist

To diagnose, check the following (in order of likelihood):

1. Search for renderMathInElement or katex.render calls — verify the delimiters array still includes {left: '$', right: '$', display: false}.
2. Search for the math split regex — confirm it has a capture group for single $, not just $$.
3. Check the markdown-to-HTML pipeline — look for any pre-processing step that might consume or escape single $ before the KaTeX pass.
4. Git bisect the relevant renderer file between the last working version and v2.1.156 to find the exact commit that dropped inline math support.

Suggested Fix

The most targeted fix is to ensure the math rendering configuration includes inline delimiters:

// Ensure both display and inline delimiters are configured
delimiters: [
  {left: '$$', right: '$$', display: true},
  {left: '$',  right: '$',  display: false},
],

If using a custom markdown parser (like marked + KaTeX plugin), check that the plugin's inlineMath option is not set to false or that inline math rendering was not accidentally disabled via a feature flag.

Still reproduces in Claude Code 2.1.167 on macOS 26.5.1 (desktop app, Claude Code tab).

A few additional data points beyond the original report:

• \(...\) inline delimiters are also ignored — not just $...$.
• $$...$$ renders, but only as a centered display block on its own line. Placing it mid-sentence forces a line break, so it is not a usable substitute for inline math. Net effect: there is currently no delimiter that produces true inline math in the desktop app.

Test snippet (paste into chat, or have Claude emit it):

Inline single: the identity $e^{i\pi}+1=0$ is famous.
Inline paren:  the identity \(e^{i\pi}+1=0\) is famous.
Inline double: the identity $$e^{i\pi}+1=0$$ is famous.

Observed: lines 1–2 show the raw delimiters with no rendering; line 3 renders but is pulled onto its own centered line, breaking the sentence.

This keeps getting reported and auto-closed without ever being fixed. Every prior report was closed by the stale bot (github-actions[bot]) on an inactivity timeout — not resolved by a maintainer, and in several cases after an automated stale label — even though the bug is still present:

• #36576 — labeled stale, then auto-closed by github-actions[bot] (not planned)
• #36742 — labeled invalid + stale, then auto-closed by github-actions[bot] (not planned)
• #27372 — labeled stale, then auto-closed by github-actions[bot] (not planned)
• #21433 — auto-closed by github-actions[bot], bot-labeled duplicate
• #31866 — auto-closed by github-actions[bot], bot-labeled duplicate

So those closures reflect inactivity timeouts, not fixes — the underlying problem has never been addressed. Related open feature requests: #16446 (VS Code plugin), #44479 (terminal output).

Confirming this is still unresolved in the latest build, and asking that #65632 stay open until it's actually fixed. Inline $...$ (and ideally \(...\)) parsing would bring the desktop app in line with claude.ai, GitHub-Flavored Markdown, Obsidian, and KaTeX/MathJax defaults. In the meantime the only workaround is Unicode (a² + b² = c²) or accepting display blocks — neither produces real inline math.

For anyone reading this, please leave a 👍 on the OP so this issue doesn't get auto-closed again by Github bots

Yes， This problem don't be solved now.

Cross-device data point (same account, same messages, 2026-06-10):

| Surface | inline $...$ | inline \(...\) | display $$...$$ |
|---|---|---|---|
| macOS desktop app (Claude Code tab) | ❌ raw source | ❌ raw source | ✅ (own line only) |
| iPad app | ✅ renders | not tested | ✅ |
| iPhone app | ✅ renders | not tested | ✅ |

The identical markdown renders correctly as inline math on the iPad/iPhone apps, so the model/CLI output is fine — the failure is specific to the desktop app's renderer. Consistent with the analysis in #65777 (inline single-$ rule not enabled in the desktop markdown→math pass while block math is), and with the report there that this was fixed in a previous release and then re-broken.

still not resolved.

still not resolved.

still not resolved.

Still not resolved. Incredibly annoying and really gets in the way of Claude being useful to my workflow.

Still not resolved

I'm seeing an improvement in this behavior on both web (Safari) and in the latest Mac build (1.20186.0). Both inline and block equations are rendering _after streaming concludes_.

I'm seeing an improvement in this behavior on both web (Safari) and in the latest Mac build (1.20186.0). Both inline and block equations are rendering _after streaming concludes_.

@tylersax can you share a screenshot? which prompt did you use. can get it to render in my end

Here's an example prompt whose answer renders properly for me (both inline and display): https://claude.ai/share/99e9d502-eb1f-4a86-b98a-7e208400cfb3

One thing to note: check whether Claude has learned to produced different formatting based on your instructions. (For example, I had given the instruction to avoid KaTeX while waiting for this bug fix).

<img width="873" height="268" alt="Image" src="https://github.com/user-attachments/assets/558d83ea-6be9-43b7-a656-072a61b6896f" />

@tylersax is that from the claude code or regular claude chat?

Regular chat

@tylersax yea it always seemed to have worked with the regular chat. this issue is Claude Code exclusive

Shoot - I thought this issue was with both. Apologies for the false hope! I tried the same prompt in Code and indeed it still fails.

please fix!

I'm about to move to codex if this doesn't get fixed

Please use your most advanced and powerful model to provide a precise and rapid fix!

I asked chatgpt to find a solution and he told me to ask this (and it worked for me). I guess you can adjust it for other things than just math expressions.

For all mathematical expressions, use standard LaTeX delimiters. Use \( ... \) for inline mathematics and \[ ... \] for display mathematics. Never wrap LaTeX in code blocks or backticks. Do not output raw $...$ delimiters.

I also added that he needs to take this in his memory and after that the inline worked again (Claude desktop (Sonnet 5)).

I asked chatgpt to find a solution and he told me to ask this (and it worked for me). I guess you can adjust it for other things than just math expressions. `` For all mathematical expressions, use standard LaTeX delimiters. Use \( ... \) for inline mathematics and \[ ... \] for display mathematics. Never wrap LaTeX in code blocks or backticks. Do not output raw $...$ delimiters. `` I also added that he needs to take this in his memory and after that the inline worked again (Claude desktop (Sonnet 5)).

Thats huge!! It's finally fixed. its a very recent update then

Workaround: use \(...\) for inline math instead of $...$. Credit to @Maarten522 for catching this just above.

| delimiter | inline render |
|---|---|
| $...$ | ❌ still raw |
| \(...\) | ✅ renders |
| $$...$$ on its own line | ✅ renders |

\(...\) handles the cases that otherwise force a display block: subscript chains like \(f_{X \mid Y = k}(x)\), inline fractions, sums with limits, multi-char hats such as \(\widehat{\mathrm{Var}}(\bar{X}_n)\), and mixing with **bold** on the same line.

Worth noting escaped parens did not render when this was filed — @cossio confirmed that back in June. They started working recently. Single-$ is still broken.

Single-$ is still broken.

@GuyAzene Why did you close then?

@cossio does it matter really which way you can use inline math?

Yes ! The problem is the model sometimes uses $...$ instead of \( ... \). That's an issue that should be fixed.

Not Solved. This is a critical issue, PLEASE fix this. From this aspect, the readability is far away from codex.