Display math block starting with `\[` fails to render when it immediately follows text without a blank line

Open 💬 4 comments Opened May 15, 2026 by yuriever

What version of the Codex App are you using (From “About Codex” dialog)?

26.513.20950

What subscription do you have?

pro

What platform is your computer?

Darwin 25.4.0 arm64 arm

What issue are you seeing?

In Codex 26.513.20950, display math written with \[ ... \] sometimes fails to render when it appears immediately after a normal text line with no blank line in between. Instead of being parsed as a math block, the content is treated as regular Markdown/text. In the broken case, the leading backslash on \[ is effectively lost, and the formula body may be reinterpreted by Markdown rules.

What steps can reproduce the bug?

  1. Send the following message:
Previous line has text
\[
a
=
b
\]
  1. Observe that the math block does not render correctly.
  1. Compare with this working version:
Previous line has text

\[
a
=
b
\]
  1. Also compare with this working version, where the formula is preceded by a blank line and wrapped in \boxed:
Previous line has text

\[
\boxed{
a
=
b
}
\]

What is the expected behavior?

A display math block starting with \[ should render correctly regardless of whether the previous line contains plain text, as long as the \[ ... \] block itself is syntactically valid. The renderer should not require an extra blank line before the math block in order to recognize it.

Additional information

  • The issue is not caused by undefined macros. Simple formulas such as a = b reproduce it.
  • The issue is sensitive to surrounding paragraph structure.
  • Adding a blank line before \[ consistently avoids the bug.
  • When the bug occurs, the content appears to fall back to normal Markdown parsing rather than math parsing.
  • This suggests the block-math parser is not recognizing \[ as a block opener when it immediately follows paragraph text.
  • Previous version of codex does not have this issue.

View original on GitHub ↗

4 Comments

cossio · 3 months ago

+1, I also see this issue. Please fix.

yuriever · 3 months ago

Although it might just be a simple markdown parser issue, for tasks that use Codex for mathematics and physics, the fact that most of the output formulas cannot be rendered properly will seriously degrade the user experience. I hope this can be fixed as soon as possible.

To reiterate: this is a bug introduced in version 26.513.20950; before that, formula rendering was normal.

x-at-01 · 2 months ago

This parser bug occurs because the markdown tokenizer treats display math blocks starting with \[ as inline paragraphs when there is no preceding blank line, causing the escaped backslash to be stripped or parsed as normal text.

To fix this, the block-math parser's block-opener regex (which scans for \[ delimiters) should check for a preceding newline or paragraph boundary, rather than strictly requiring a double newline / empty line.

If you are hardening your math rendering pipeline in the Codex web and desktop clients, you should consider compiling LaTeX directly to browser-native MathML Core instead of bundling heavy rendering engines (like KaTeX/MathJax).

Since all modern browser engines natively support MathML Core now, standard <math> tags are rendered natively by the browser's C++ layout engine.

I wrote @webc.site/math (GitHub: https://github.com/webc-site/math, Live Demo: https://math.webc.site) — the world's smallest and fastest TeX-to-MathML compiler:

  • Size: ~3.58 KB Gzipped.
  • Speed: ~329,000 ops/s.

Compiling LaTeX to native <math> tags at parse-time requires 0 KB of client-side CSS/font files, keeps the application bundle size lightweight, and ensures equations inherit dark/light theme text styles natively.

yuriever · 2 months ago

This bug has not been fixed in the latest version 26.602.40724 . A workaround is to add the following instruction in the global agents.md

## Chat math rendering

* In chat response, display math blocks `\[...\]` or `$$...$$` must be surrounded by blank lines for Markdown rendering compatibility.