Agent's output text fails to render

Where does the bug appear (feature/product)?

Cursor IDE

Describe the Bug

Sometimes, when an agent’s output text includes formulas or latex, it fails to render

Steps to Reproduce

make it to output a long text including some formula or latext

Screenshots / Screen Recordings

Operating System

MacOS

Version Information

Version: 3.0.9 (Universal)
VSCode Version: 1.105.1
Commit: 93e276db8a03af947eafb2d10241e2de17806c20
Date: 2026-04-03T02:06:46.446Z (1 day ago)
Layout: editor
Build Type: Stable
Release Track: Default
Electron: 39.8.1
Chromium: 142.0.7444.265
Node.js: 22.22.1
V8: 14.2.231.22-electron.0
OS: Darwin arm64 25.3.0

Does this stop you from using Cursor

No - Cursor works, but with this issue

Hey, I see the screenshot. This is a known renderer limitation in Cursor.

Cursor only supports LaTeX with specific delimiters:

  • Inline math: \(...\)
  • Block math: \[...\] or $$...$$

Standard $...$ for inline math is intentionally not supported because it can conflict with the dollar sign. When the model outputs formulas using $...$, the renderer won’t recognize them, and * and _ inside formulas can accidentally trigger italic formatting. That’s why you see the “garbage” in the screenshot.

Workaround: add an instruction in .cursorrules to make the model use \(...\) instead of $...$ for inline math. Something like:

When writing mathematical formulas, always use \(...\) for inline math and \[...\] for block math. Never use $...$ notation.

The team knows this limitation gets in the way. Here’s the main thread for this feature request: LaTeX rendering in chat

Let me know if the workaround helps.

thanks @deanrie
To my experience, before this new version, it never was colored ‘red’ if failed to render! However, it’s happenning more often

Where does the bug appear (feature/product)?

Cursor IDE

Describe the Bug

I’ve reported this issue before here:

but the solution doesn’t work and this is super annoying!

Steps to Reproduce

read the previous issue

Operating System

MacOS

Version Information

Version: 3.2.11 (Universal)
VSCode Version: 1.105.1
Commit: e9ee1339915a927dfb2df4a836dd9c8337e17cc0
Date: 2026-04-24T14:36:47.933Z
Layout: editor
Build Type: Stable
Release Track: Default
Electron: 39.8.1
Chromium: 142.0.7444.265
Node.js: 22.22.1
V8: 14.2.231.22-electron.0
OS: Darwin arm64 25.3.0

Does this stop you from using Cursor

Yes - Cursor is unusable

Hey, I need a bit more info to figure out if this is the same case or a regression.

Can you send:

  1. A recent screenshot showing how it breaks on 3.2.11, ideally with the raw formula visible. You can ask the model to show the same answer inside a code block.
  2. The Request ID for that session: Chat menu in the top right > Copy Request ID.
  3. Exactly what’s in your .cursorrules, word for word, and what format the model uses for formulas in the broken reply: $...$, \(...\), $$...$$, or something else.

If the model keeps using $...$ even with the rule, that’s on the prompt or the model. The rule isn’t holding it, so we’ll need a stronger workaround. If it’s already using \(...\) or $$...$$ and rendering still breaks, that’s a different bug, and we’ll need these details to escalate.

i cannot find .cursorrules

Hey, there’s no .cursorrules file by default, you need to create it yourself. The easiest option is to skip the file and add a User Rule in settings:

  • Cursor SettingsRulesUser Rules section
  • Paste this:
When writing mathematical formulas, always use \(...\) for inline math and \[...\] for block math. Never use $...$ notation.
  • Save, then open a new chat.

This will apply globally to all projects.

If you want it as a project file, create .cursor/rules/latex.mdc in the repo root with the same content. This is the new format, the old .cursorrules still works, but .cursor/rules/ is preferred.

After that, test it in a new chat. Ask the model to solve any equation and confirm it uses \(...\) instead of $...$. If it still uses $...$, send the Request ID chat menu top right → Copy Request ID and a screenshot of the broken rendering in 3.2.11, and we’ll dig in.