›_ Codex Issues
Codex Issues / #21511

macOS desktop app renders UI text with incorrect font/fallback

Open 💬 6 comments Opened May 7, 2026 by sxiaoying
💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

Codex macOS desktop app renders UI and code text with incorrect font/fallback

Summary

On macOS 26.4.1, the Codex desktop app renders UI and code text with an abnormal font/fallback. This is visible in both zh-CN and en-US UI. Other apps on the same machine, including VS Code, Terminal, WeChat, and system UI, render text normally.

This appears isolated to the Codex desktop app / Electron renderer font stack rather than a broken system font installation.

Environment

  • Codex app: 26.429.61741
  • Bundle id: com.openai.codex
  • macOS: 26.4.1 (25E253)
  • Hardware: MacBook Air, Apple Silicon
  • Locale/UI language: zh-CN
  • System Chinese font: PingFang SC is installed and visible to CoreText

Visible Symptom

Codex text appears to use an unexpected or degraded font/fallback. The issue is visible even when the Codex UI locale is switched to en-US, so it is not limited to Simplified Chinese text. It is especially noticeable in the new-thread/home UI, permission mode dropdown, and code/terminal-style text.

Other apps on the same machine render comparable English and Chinese text correctly.

Reproduction

  1. Install and launch the Codex macOS desktop app.
  2. Use the app in zh-CN locale and observe the font rendering.
  3. Switch the Codex UI locale to en-US and restart/reopen the app.
  4. Open the new-thread/home screen, permission mode dropdown, and code/terminal-style views.
  5. Observe that the abnormal font rendering still appears in English UI/code text.
  6. Compare with VS Code, Terminal, or native macOS UI on the same machine.

Expected Behavior

Codex should use normal macOS system UI and monospace font resolution, and render both English and Chinese text consistently with other macOS apps.

Actual Behavior

Codex renders UI/code text with an abnormal fallback/appearance. The issue persists after switching the UI locale from zh-CN to en-US. Disabling Codex font smoothing does not fix it.

Diagnostics

CoreText can resolve the expected fonts on this machine:

PingFang SC -> family=PingFang SC, postscript=PingFangSC-Regular
SF Mono -> family=SF Mono, postscript=SFMono-Regular
Menlo -> family=Menlo, postscript=Menlo-Regular

Codex's packaged CSS contains:

--font-sans-default:-apple-system,BlinkMacSystemFont,"Segoe UI",sans-serif

There is no explicit CJK fallback such as PingFang SC, Hiragino Sans GB, or Noto Sans CJK SC. However, the issue is not limited to CJK text; it is also visible in en-US UI/code text.

Local workaround:

  • Installing Noto Sans CJK SC
  • Setting Codex UI font state to Noto Sans CJK SC

This makes the UI more readable, but it is not the expected native macOS app appearance and does not explain why the default English/code font rendering is also abnormal.

Additional Notes

This does not appear to be a global machine/font corruption issue because:

  • VS Code renders English and Chinese text normally.
  • Terminal renders English and Chinese text normally.
  • macOS system UI renders English and Chinese text normally.
  • CoreText resolves PingFang SC correctly.

The issue seems specific to Codex desktop app font selection/fallback/rendering on macOS, not a global machine font issue.

<img width="330" height="620" alt="Image" src="https://github.com/user-attachments/assets/fa19b683-90ed-4f8e-a41f-8f609b35d8b2" />
<img width="675" height="370" alt="Image" src="https://github.com/user-attachments/assets/20ea9d5d-5991-47ac-8c93-f02696dc9ea1" />
<img width="1050" height="450" alt="Image" src="https://github.com/user-attachments/assets/aec82252-d504-4c6e-9367-5f27670fd807" />
<img width="575" height="310" alt="Image" src="https://github.com/user-attachments/assets/de2183fb-9b29-4c5e-b55a-b46489827165" />

View original on GitHub ↗

6 Comments

github-actions[bot] contributor · 3 months ago

Potential duplicates detected. Please review them and close your issue if it is a duplicate.

  • #21321

Powered by Codex Action

essicajaybarron-stack · 3 months ago

The first one is the best one I have ever seen and I love it so much 🥸🌻1️⃣🔟❤️✡️ _I luv Crowder it really is amazing and I'm Zack_

sxiaoying · 3 months ago
Potential duplicates detected. Please review them and close your issue if it is a duplicate. * Integrated terminal doesn't support Korean even if fallback font is configured. #21321 _Powered by Codex Action_

It's not a repetitive problem.

sxiaoying · 3 months ago

Additional finding / scope correction:

This issue is not limited to the standalone macOS desktop app. I can reproduce the same abnormal font rendering in the Codex VS Code extension panel as well.

Important distinction:

  • The VS Code native editor renders text normally.
  • The VS Code integrated terminal renders text normally.
  • The Codex VS Code extension panel renders text abnormally.
  • The standalone Codex macOS app also renders text abnormally.
  • The Codex VS Code extension can be used without installing the standalone Codex app.

So the likely scope is not the Codex macOS app shell itself, and not a system-wide macOS font problem. The common layer appears to be Codex's shared frontend/webview UI and its font stack / font variables / font smoothing behavior.

More precise hypothesis:

Codex shared UI/webview renders fonts incorrectly in both the macOS desktop app and the VS Code extension, while native VS Code editor/terminal text renders correctly.

Local observations:

  • VS Code user settings do not override editor/UI fonts; only chatgpt.localeOverride is set.
  • Codex's VS Code extension webview CSS has its own font stack and variables, including:
--font-sans: var(--vscode-font-family,var(--font-sans-default));
--font-mono: var(--vscode-editor-font-family,var(--font-mono-default));
--font-sans-default: -apple-system, BlinkMacSystemFont, "Segoe UI", sans-serif;
body { font-family: var(--vscode-font-family); }

This points more toward a Codex shared webview/frontend font fallback issue than a VS Code or macOS global font issue.

zikangliang · 3 months ago

Confirming this on a newer build.

Codex app: 26.521.10419
macOS: 26.5
Apple Silicon, zh-CN UI

Same abnormal/over-bold font rendering in the main thread/conversation area, while the sidebar renders normally. PingFang SC is present and selectable on my machine (PingFangSC-Regular).
Workaround that fully fixes it for me: in Settings → Appearance, set the UI font explicitly to PingFang SC. Once set, the conversation text goes back to a normal weight.
Since explicitly selecting the system font resolves it, this further points to the default --font-sans-default stack (-apple-system, BlinkMacSystemFont, ...) failing to resolve PingFang SC on its own, rather than any missing/broken font on the machine. Would be great to add an explicit CJK fallback (or fix the system-font resolution) in the default stack.

gliuuchangg-ux · 2 days ago

Confirming this regression on the current macOS desktop build.

  • App: Codex/ChatGPT Desktop 26.820.60940 (build 7119)
  • macOS: 26.5.2 (25F84)
  • Hardware: MacBook Pro, Apple M1 Max
  • Display: built-in Liquid Retina XDR, 3456 × 2234, standard 2× Retina scaling
  • UI language: zh-CN
  • No custom font or display settings

The font rendering became visibly worse immediately after today's in-app update. Compared with the previously installed build, conversation/UI text now looks less smooth and rounded, less sharp, and subjectively lower-resolution. Other macOS applications still render text normally on the same display.

Troubleshooting/observations:

  • Toggling Settings → Appearance → Font smoothing makes no meaningful difference.
  • The display is not using fractional scaling.
  • No forced device-scale factor or disabled-GPU launch flags are present.
  • Fully restarting the app does not restore the previous rendering.
  • The problem is isolated to this app and is especially noticeable on Chinese text.

This looks like a regression in the shared Chromium/webview font rasterization, default font resolution/fallback, or font-weight mapping rather than a macOS display or system-font problem.