Where does the bug appear (feature/product)?
Cursor IDE
Describe the Bug
Cursor’s agent chat markdown renderer greedily matches distant * characters across sentences and paragraphs. All text between the matched pair is rendered as a single italic span with spaces removed, producing unreadable word-soup. This is particularly bad when the model generates financial analysis, math, or any prose that naturally uses * near numbers.
Steps to Reproduce
Ask an agent to produce text containing *emphasis* interspersed with financial figures or math. For example, a prompt like “analyze our monthly costs and explain the pricing model” reliably triggers it.
The model outputs valid markdown like:
The $xxxK is a *minimum commitment floor*, not a cap or a fixed
annual price. You still pay for every dollar of consumption above
it at the same per-token rates. If Opendoor consumes $xx worth
of tokens,xxx pays ~$xxx -- *not* $xxx.
The renderer incorrectly pairs the closing * after “floor” with the opening * before “not” several sentences later (or vice versa), collapsing everything between into one italic run with spaces stripped.
What renders
...a *minimumcommitmentfloor*,notacaporafixedannualprice.Youstillpay
foreverydollarofconsumptionaboveitatthesameper-tokenrates.Ifxxx
consumes*xxxM worth of tokens...
Another example from a different session:
...costs **xxxk/year *thanconsumption.The"subsidy"onlyworkswhenyou
haverelatively* 40/month in cost...
Expected Behavior
Expected
Each *...* pair should only match when both delimiters are immediately adjacent to non-whitespace on the interior side (per CommonMark), rendering short inline emphasis like minimum commitment floor and not independently.
Screenshots
Agent session generating a Slack draft with financial data. The model output * for emphasis around terms like “minimum commitment floor”. The renderer matched a * with a distant * several sentences later, collapsing the entire span into:
104kintokenvalueatAPIrates)coveronlyaportionofactualusage.**8220.8k)
and the allotment value (104.2k)--onlyyields 7k/month net benefit
versus pure consumption (119k-112k = $+ALT
Spaces stripped, parentheses and numbers concatenated with words, completely unreadable.
Screenshots / Screen Recordings
Operating System
MacOS
Version Information
Version: 2.6.14
VSCode Version: 1.105.1
Commit: eb1c4e0702d201d1226d2a7afb25c501c2e56080
Date: 2026-03-08T15:36:54.709Z
Build Type: Stable
Release Track: Early Access
Electron: 39.6.0
Chromium: 142.0.7444.265
Node.js: 22.22.0
V8: 14.2.231.22-electron.0
OS: Darwin arm64 25.3.0
For AI issues: which model did you use?
Claude Opus 4.6 (affects all models – this is a renderer bug, not a model bug)
Additional Information
The bug is in the chat panel’s markdown-to-HTML renderer. It violates CommonMark spec section 6.2 (Emphasis and strong emphasis) in at least two ways:
1. Flanking delimiter rules are not enforced
CommonMark defines:
A left-flanking delimiter run is a delimiter run that is (1) not followed by Unicode whitespace, and (2a) not followed by a Unicode punctuation character, or (2b) followed by a Unicode punctuation character and preceded by Unicode whitespace or a Unicode punctuation character.
A right-flanking delimiter run is a delimiter run that is (1) not preceded by Unicode whitespace, and (2a) not preceded by a Unicode punctuation character, or (2b) preceded by a Unicode punctuation character and followed by Unicode whitespace or a Unicode punctuation character.
Cursor’s renderer appears to ignore these constraints. A * followed by a space (e.g., costs *276k/year *than) should not open emphasis, but the renderer treats it as a valid opener and scans forward for a matching closer.
2. Emphasis spans across paragraph boundaries
CommonMark specifies that emphasis delimiters cannot match across blank lines (paragraph boundaries). The renderer appears to search across multiple paragraphs or streamed chunks to find a matching *, which dramatically increases the blast radius of a single unpaired delimiter.
3. Spaces stripped from emphasis content
Even when emphasis is incorrectly matched, the rendered content should preserve internal whitespace. Instead, spaces between words are stripped entirely, turning readable prose into concatenatedwordblobs.
Does this stop you from using Cursor
No - Cursor works, but with this issue