Add ReasonML syntax highlighting to the TUI

What variant of Codex are you using?

Codex CLI (TUI), current main as of July 28, 2026.

What feature would you like to see?

Add first-class ReasonML syntax highlighting for Markdown code blocks and file diffs.

The TUI currently uses the two-face syntax set for code highlighting, but that set does not include a ReasonML grammar. There is also a concrete alias collision: the re token currently resolves to the "Regular Expression" syntax instead of ReasonML, so .re files can receive incorrect highlighting. .rei files and fenced code blocks labeled reason or reasonml are not properly highlighted either.

The desired behavior is:

• reason and reasonml fenced code blocks use ReasonML highlighting.
• .re and .rei diffs use ReasonML highlighting.
• Language identifiers are matched case-insensitively, consistent with the existing lookup behavior.

Additional information

I searched existing Codex issues and pull requests for ReasonML-specific highlighting support and did not find a matching request.

I have a working local prototype with a deliberately small runtime footprint:

• Bundle an MIT-licensed Reason.sublime-syntax grammar, pinned to a specific upstream revision.
• Load it into a dedicated lazy SyntaxSet, rather than rebuilding or extending the full two-face syntax set at runtime.
• Route reason, reasonml, re, and rei to that grammar before the generic syntax lookup.
• Return the resolved syntax together with its owning SyntaxSet, since Syntect requires both during highlighting.
• Cover alias resolution, Markdown rendering with an insta snapshot, and .re/.rei diff rendering.

The Reason-specific tests, formatting, snapshot checks, and just fix -p codex-tui pass locally. A full codex-tui test run was also attempted; the Reason-specific coverage passed, while the highly concurrent full run had unrelated existing test failures/timeouts across app lifecycle, pets, motion, and IDE IPC areas.

Per the repository contribution policy, I am not opening an unsolicited code PR. If this direction aligns with the maintainers' intended solution and you would like the implementation submitted, I would be happy to open an invited PR.