Repository navigation
desktop: render LaTeX math in messages #51432
Description
Summary
Feature request: render LaTeX math in messages. When an assistant reply contains
LaTeX delimiters ($...$, $$...$$), the desktop app shows the raw text (backslashes,
underscores, braces) instead of typeset math, which makes any math-heavy answer hard to
read.
Environment
- opencode version: v2.0.12
- OS: Microsoft Windows NT 10.0.26200.0 (Windows 11, x64)
- Terminal: TERM=xterm-256color, TERM_PROGRAM unset, COLORTERM unset
- Shell: C:\WINDOWS\system32\cmd.exe (opencode shell config: powershell)
- Install/channel: release (installed via npm, C:\Users<user>\AppData\Roaming\npm\opencode.ps1)
- Active plugins:
./herdr-opencode(defined in~/.config/opencode/cli.json)
Reproduction
- Ask the agent a question whose answer naturally contains math, e.g.
write the fixed-point identity: $$p'_{161} = p_{161} + A\,(p_{161} - p_{161}) = p_{161}$$ - Read the reply in the OpenCode desktop app.
- The message displays the literal source:
$$p'_{161} = p_{161} + A\,(p_{161} - p_{161}) = p_{161}$$
instead of a rendered formula.
Expected Behavior
Inline ($...$) and block ($$...$$) math should render as typeset math, the same way it
does on GitHub / in MathJax- or KaTeX-enabled Markdown readers. If rendering everything by
default is undesirable, a config toggle (for example markdown.math / an inline-math
option) would be enough.
Actual Behavior
The math source is rendered as plain text. $$, \, _, {}, \cdot and friends are all
shown verbatim.
Additional Context
- This is a feature request, not a bug: the message content is correct Markdown; only the
rendering layer does not typeset math. - I checked the V2 docs (
llms.txt, Intro, Web) and found no documented LaTeX/math
rendering option or toggle, so I'm not missing a setting as far as I can tell. - Why it fails today: math is not part of CommonMark/GFM, and typesetting it needs a
dedicated engine (KaTeX or MathJax) plus math fonts. A plain Markdown renderer therefore
prints the delimiters as literal text. - Likely relevant to other clients too (desktop/TUI/web) if they share the same Markdown
renderer, but I can only confirm the desktop app. - Current workarounds: emit plain-text formulas (
p'161 = p161 + A·(p161 − p161) = p161),
wrap formulas in fenced code blocks, or write formulas into a.md/.pdfand view them
in a math-capable reader.
Reacted by Mohamed Hafdi Idrissi
Metadata
Metadata
Assignees
Labels
No labels
Activity
github-actions commentedon Sep 26, 2026
This issue doesn’t fully meet our contributing guidelines.
What needs to be fixed:
[FEATURE]:.Please edit this issue to address the above within 2 hours, or it will be automatically closed.
This issue might be a duplicate of existing issues. Please check:
If you believe this was flagged incorrectly, please let a maintainer know.
github-actions commentedon Sep 26, 2026
This issue has been automatically closed because it was not updated to meet our contributing guidelines within the 2-hour window.
Feel free to open a new issue that follows our issue templates.
Focus786 commentedon Sep 26, 2026
Additional evidence: it is not only that math is not typeset — the Markdown renderer also
corrupts the LaTeX source, so the user cannot even read the raw formula correctly.
Sent as a standalone message:
Displayed in the desktop app (v2.0.12) as literal text:
Two changes are visible, both explained by CommonMark/GFM parsing rather than math parsing:
p'_{161}→p'{161}: the first two_are paired as emphasis and consumed, so theunderscores disappear. The remaining
_are intraword (preceded by a letter) and stay.A\,(...)→A,(...): the backslash escapes ASCII punctuation, so\,renders as,.This happens for a standalone message too, not only when the formula is mixed with prose.
Inside a fenced code block the source is preserved verbatim, but it is still not typeset.
Repro (desktop, Windows 11, v2.0.12):
$$p'_{161} = p_{161} + A\,(p_{161} - p_{161}) = p_{161}$$._eaten as emphasis,\,reduced to,.Expected: either typeset math, or at minimum no silent corruption of the source. Rendering
math (KaTeX/MathJax) would fix both, but it may also be worth ensuring that math delimiters
and their contents are excluded from emphasis/escape processing.