Many C++ module filetypes don't get syntax highlighting

Resolved 💬 2 comments Opened Jun 14, 2026 by chriselrod Closed Jun 16, 2026

What version of Codex CLI is running?

codex-cli 0.139.0

What subscription do you have?

Pro

Which model were you using?

gpt-5.5

What platform is your computer?

Linux 7.0.11-1-cachyos-server x86_64 unknown

What terminal emulator and version are you using (if applicable)?

foot version: 1.26.1 +pgo +ime +graphemes +toplevel-tag +blur -assertions

Codex doctor report

What issue are you seeing?

When codex proposes a diff to *.cxx or *.cpp files, the diffs are rendered nicely with syntax highlighting.
When it proposes diffs to *.cxxm or *.ixx files, they don't get syntax highlighting. Removals are red, additions are green. These don't seem to be recognized as C++, even though *.ixx is MSVC's standard for module interface units.

What steps can reproduce the bug?

Ask codex to create or modify a file with the ixx or cxxm extension.

What is the expected behavior?

Diffs to these files to be rendered in the same way as diffs to *.cpp or *.cxx files.

An alternative solution would be to have something like .gitattributes, where you can add *.ixx linguist-language=C++ to specify how extensions are interpreted.

Additional information

_No response_

View original on GitHub ↗

2 Comments

wgu9 · 2 months ago

I took a look at this and found the issue is in the TUI syntax lookup path rather than the diff renderer itself.

diff_render::detect_lang_for_path passes the file extension through to highlight_code_to_styled_spans. The syntax lookup in tui/src/render/highlight.rs::find_syntax already patches a few aliases before calling syntect/two-face. ixx and cxxm do not resolve in the bundled syntax set, so the renderer falls back to plain diff coloring.

A minimal fix would be to add:

"cxxm" | "ixx" => "cpp",

to that alias table. I also validated this with:

a syntax lookup regression covering cxxm and ixx
a diff-render regression that creates module.ixx and module.cxxm add diffs and asserts they produce syntax-highlighted RGB spans

Local validation:

just fmt
just test -p codex-tui -> 2867 passed, 4 skipped
just fix -p codex-tui -> passed

Since docs/contributing.md says external code contributions are invitation-only, I’m not opening an unsolicited PR. If this approach matches the intended fix, I’m happy to submit the small patch.

wgu9 · 2 months ago

I traced this on current main; the issue appears to be in the extension-to-syntax mapping rather than in the diff renderer itself.

Current flow:

codex-rs/tui/src/diff_render.rs calls detect_lang_for_path(path), which returns the raw file extension string.
That raw extension is passed into highlight_code_to_styled_spans(...).
codex-rs/tui/src/render/highlight.rs::find_syntax has a small patched alias table for names that two-face does not resolve by itself (csharp, c-sharp, golang, python3, shell).
cxxm and ixx are not in that alias table, so they do not resolve to the existing C++ syntax and the diff falls back to plain add/remove coloring.

Minimal fix outline:

// codex-rs/tui/src/render/highlight.rs
"cxxm" | "ixx" => "cpp",

Suggested regression coverage:

Extend the existing patched-alias test in render/highlight.rs to include cxxm and ixx.
Add a diff_render.rs test that builds an added-file diff for module.ixx and module.cxxm, then asserts the rendered spans contain syntax-highlighted RGB foreground colors, matching the existing .rs extension coverage.

This keeps the mapping in the current single owner (find_syntax) instead of adding another extension registry in diff_render.rs.

Per docs/contributing.md, I am not opening a PR unless a Codex maintainer explicitly invites one, but I can submit the focused patch + regression tests if wanted.