Windows: Arabic RTL text renders as separated/reordered characters in Codex CLI

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

Bug

Arabic text in the Codex CLI TUI on Windows is rendered as separated and reordered characters, making it unreadable.

Environment

  • Codex CLI: 0.145.0
  • OS: Windows
  • Shell: PowerShell with UTF-8 enabled (code page 65001)

Expected behavior

Arabic should render with proper right-to-left direction and joined letter shaping.

Actual behavior

Codex CLI displays the Arabic letters separately and in the wrong order.

Additional context

Arabic renders correctly in Claude Code on the same PC, so this appears specific to the Codex CLI TUI. Screenshot attached.

View original on GitHub ↗

2 Comments

github-actions[bot] contributor · 1 month ago

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

  • ##34686
  • ##34287

Powered by Codex Action

CodeinScrubs · 1 month ago

This report combines two related but distinct terminal problems:

  1. bidirectional paragraph ordering/base direction; and
  2. Arabic joining/shaping across terminal cells.

A blanket string reversal can make one screenshot look better while breaking numbers, punctuation, English identifiers, copy/paste, cursor mapping, styles, and other scripts. The source should remain in logical order, and the final TUI rendering stage needs to account for UAX #9, grapheme/style boundaries, and the capabilities of the terminal/font actually in use.

Useful regression fixtures should include both:

مرحبا gpt-5
React یک کتابخانه جاوااسکریپت بسیار محبوب است.

The second case is important because first-strong auto-detection chooses LTR from React, although the strong-character majority is Persian. Conversely, an RTL-first line whose majority is English should retain an LTR base. Pure ASCII/LTR lines should stay on the current identity path.

Maintainer disclosure: I maintain BidiLens, an MIT-licensed cross-platform bidi toolkit. Its @bidilens/terminal adapter, ANSI-aware utilities, and 918-fixture corpus can provide detection, isolation, and test evidence, but I would not propose dropping a JavaScript package into this Rust TUI. The right Codex fix should be native to the renderer and should explicitly document terminal/shaping limitations.

A host-native version of the direction policy is under review in NousResearch/hermes-agent#72508. I would be glad to help translate the fixtures and policy into focused Rust tests/implementation for Codex once maintainers confirm the preferred rendering architecture.