Bug: single-dollar math parsing swallows dollar amounts in assistant prose ($3,641 … $200/mo becomes KaTeX garbage)

[tmttodd]

Upstream bug report: single-dollar inline math swallows dollar amounts in prose

Package: @deepseek-ai/dsh-client-ui-primitives (markdown renderer)
Severity: high for agent-output readability — money amounts and other $-bearing prose are silently destroyed
Environment observed: DSH Desktop 0.x (shipped app.asar, Sep 29 build), dark theme, macOS

Summary

parseGfmWithMath() registers the TeX math extension without options:

function parseGfmWithMath(text) {
	return recoverLocalImages(fromMarkdown(text, {
		extensions: [
			gfm(),
			cjkFriendlyStrong(),
			mathCompatibility(),
			math()          // <-- no options
		],
		mdastExtensions: [gfmFromMarkdown(), mathFromMarkdown()]
	}), text);
}

micromark-extension-math defaults singleDollarTextMath: true when unset
(confirmed in the shipped vendor bundle: let n={}.singleDollarTextMath; n==null&&(n=!0)).
So a pair of $ characters anywhere in a paragraph opens an inline-math node.

Repro

Assistant output containing dollar amounts:

Cost avoidance over 14 days: **$3,641** *in Sonnet — equivalent API terms*
(18,206 Opus-equivalent) — a $200/mo Max plan covers 0.8 days of that burn.

The $ in $3,641 and the $ in $200/mo are consumed as inline-math
delimiters. Everything between them — 3,641** *in Sonnet — equivalent API terms* (18,206 Opus-equivalent) — a — is handed to KaTeX and typeset as math:

• all spaces collapse (math mode ignores them): "inSonnet—equivalentAPIterms"
• the font switches to KaTeX's serif math fonts mid-sentence
• the markdown emphasis markers ** / * render as literal centered asterisks
• the throwOnError fallback never fires, because prose is valid TeX

Verified live: an assistant message rendered the sentence as
**3, 641** *inSonnet—equivalentAPIterms* inside a KaTeX span, with
$200/mo Max plan covers 0.8 days continuing as plain text after it.

Why the existing guard does not catch it

renderTexToReact renders with throwOnError: true and falls back to
throwOnError: false on failure. Dollar-amount prose parses as valid TeX, so
both paths "succeed" and the mangling is rendered without any error marker.

Suggested fixes (any one of these)

1. Disable single-dollar text math (recommended default for a chat/agent
   renderer, matches Claude Desktop / ChatGPT behavior):

   math({ singleDollarTextMath: false })

   $$…$$ display math and \(…\) / \[…\] keep working via the existing
   mathCompatibility() extension.

2. Gate dollar-math behind a user setting, defaulting off.

3. If single-dollar math must stay, require currency-hostile context before
   opening a math span (e.g. the opening $ must not be followed by a digit,
   or must be preceded by whitespace AND followed by a non-space non-digit) —
   this is what other chat renderers do to avoid exactly this failure.

Local mitigation shipped meanwhile

A client plugin (@local/dsh-readability) detects rendered span.katex
elements whose annotation[encoding="application/x-tex"] source is prose
(contains **, or * without any \command, or ≥4 word-like tokens) and
swaps them back to plain text with the consumed $ delimiters restored. It
never touches TeX containing backslash commands.

[slyyr]

The reported behavior is consistent with the Markdown math parser treating single dollar signs as inline-math delimiters, even when they are intended to represent currency.

I'd address this in the renderer rather than modifying the assistant's generated text.

For example, if the renderer uses micromark-extension-math, it can configure the extension to disable single-dollar inline math, provided that is compatible with the application's intended Markdown behavior:

math({
    singleDollarTextMath: false
})

This would allow ordinary text containing currency values to remain ordinary text instead of being parsed as a mathematical expression.

However, it could affect documents that intentionally use single-dollar delimiters for inline mathematics, so the change should be covered by regression tests.

I'd test at least these cases:

• $3,641 remains a currency amount.
• $200/mo remains ordinary text.
• Existing block-level mathematics still renders.
• Inline mathematics using the application's supported syntax still renders correctly.

The exact option should be verified against the installed extension version. If the project intentionally supports single-dollar mathematics, an alternative is to improve delimiter recognition so currency text isn't mistaken for math.

[utkesmer]

I often see this, it's not nice.