TUI: support Markdown math rendering for inline and block LaTeX
What version of Codex is running?
Observed in the current Codex terminal workflow. I do not have a precise version string to attach here.
Which model were you using?
Observed while using Codex in the terminal UI.
What platform is your computer?
macOS on Apple Silicon in a terminal-based Codex workflow.
What issue are you seeing?
Codex renders regular Markdown reasonably well in the terminal UI, but LaTeX math in Markdown is not rendered.
In practice, inline math such as $W = W_0 + BA$ and block math such as:
$$
q^T k = (q^C)^T k^C + (q^R)^T k^R
$$show up as raw Markdown/LaTeX source instead of readable equations.
This makes Codex less useful for:
- ML and math-heavy notes
- paper reading
- algorithm derivations
- technical documentation with equations
What feature would you like?
Support Markdown math rendering in the Codex terminal UI, ideally for both:
- inline math:
$...$ - block math:
$$...$$
Possible implementation directions:
- render to a terminal-friendly plain-text or Unicode pretty-printed form
- add a math-aware Markdown parsing/rendering stage
- optionally support KaTeX-compatible parsing before terminal rendering
Even a partial first step would help:
- preserve math blocks as visually distinct blocks
- improve spacing/escaping for common expressions
- avoid broken rendering for common LaTeX patterns
Why this matters
Codex is especially useful for coding, research, and technical writing workflows. In those workflows, mathematical notation is common. Right now the terminal UI handles prose and code, but not equations, which creates a gap for engineering and research use cases.
Reproduction
- Open Codex in the terminal UI.
- Ask it to write or display Markdown containing inline and block LaTeX math.
- Observe that the expressions are not rendered as readable equations.
Expected behavior
Math expressions should display in a readable rendered form, or at minimum in a terminal-friendly normalized representation that is much easier to read than raw LaTeX source.
Additional context
This request is specifically about the terminal / TUI rendering path, not browser-based Markdown renderers.
7 Comments
This would be an extremely useful feature
bump! would also love this
bringing up claude code's same feature req for friendly competition 👀
Ideally, I’d like to see richer math rendering in terminals that support inline graphics, such as Kitty graphics, iTerm2 inline images, or SIXEL.
I’d still want a plain-text or Unicode fallback for unsupported terminals, SSH, tmux, and similar environments, but an optional graphics backend would make math much easier to read where available.
For anyone hitting this in the terminal today, there is a stopgap that works now: a small skill, claude-math, that makes the model emit math as inline Unicode (− ∑ᵢ pᵢ · log pᵢ, ≤, ℝ, matrices, set-builder) instead of LaTeX, so it stays legible in any TUI. It is the plain-text/Unicode fallback @miyaji255 describes, works over SSH/tmux, and is copy- and search-safe.
It is a Codex CLI skill (same SKILL.md format Codex reads):
npx claude-math install --codex
To be clear it is a workaround, not the native inline/block rendering this issue asks for (a graphics backend via Kitty/iTerm2/SIXEL would be the real fix). Just useful until then. The same skill exists for the Claude Code side of this request.
Repo: https://github.com/vladimirrott/claude-math
A Unicode-output skill is a useful stopgap, but it cannot replace native TUI math rendering. I reproduced this while testing a skill-only formatter for Codex CLI.
Simple powers can be mapped, for example x^2 → x², but Unicode has no complete superscript or subscript alphabet. Common expressions therefore still leak source-like notation:
This is the same readability problem, only for formulas beyond the small Unicode subset. A native TUI implementation should parse inline and block Markdown math, render it when the terminal supports an appropriate backend, and provide a readable Unicode or structured-text fallback otherwise. It should work in ordinary assistant messages without requiring an Apps SDK or MCP card.
Thanks @DanChai22, this was a great push. You aimed straight at the weak spot, and it made the tool better the same day.
You were right. A Unicode-only skill cannot render arbitrary LaTeX, and the stacked bounds were the worst offenders. So I shipped a fix to claude-math today:
I fully agree with the bigger point, and it lines up with what @miyaji255 said: a skill is a stopgap. The real fix is native TUI rendering that parses inline and block math, renders through a graphics backend when the terminal has one (Kitty, iTerm2, SIXEL), and falls back to readable Unicode or structured text everywhere else (SSH, tmux, CI logs), in ordinary assistant messages, no Apps SDK or MCP card. @alramalho the Claude Code side (#63139) is asking for the same thing, so a shared mental model helps both.
Two calls a native renderer still has to make, and I would genuinely love your opinions:
@water2078 @gnshb @alramalho @miyaji255 @DanChai22 what do you all think? Happy to hand the conversion rules over as prior art if they are useful for a built-in version.
claude-math is MIT and you can read every line: https://github.com/vladimirrott/claude-math . Open source is at its best when someone points at the rough edge and it just gets fixed. Thanks again for doing exactly that.
Thanks for the quick update. For the plain-text fallback, I prefer the compact structured form you implemented, such as
∑[i=1..n]and∫[a..b]. It remains readable, searchable, and stable across SSH and tmux.I would make the rendered Unicode form the default, but always preserve the original LaTeX and provide a raw-source toggle. The transformation can be lossy, so users still need access to the exact source for copying and verification.