RTL issue

The Codex desktop app has inconsistent RTL rendering for Persian/Farsi messages. Persian text mixed with English words, punctuation, or inline code is displayed in the wrong direction and becomes hard to read.

Please add proper RTL support or a setting to force message direction for RTL languages.

Language: Persian/Farsi
Platform: Windows
App: Codex desktop app

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

• #19504

Powered by Codex Action

I’d like to add that this issue is not limited to Persian/Farsi. It also affects Arabic, Hebrew, Urdu, Pashto, and potentially other right-to-left languages.

In Codex, the basic RTL support itself seems to be missing or incomplete.

By contrast, ChatGPT has better RTL support in both the browser and the app, although it still suffers from the same bidirectional text rendering issue described here.

https://marketplace.visualstudio.com/items?itemName=Nad3r.agents-rtl
https://github.com/nad3rzz/agents-rtl

<img width="776" height="931" alt="Image" src="https://github.com/user-attachments/assets/4d4a8fec-5152-411c-b578-de47b73533c1" />

I ran into the same issue and built a small open-source workaround for Codex Desktop RTL rendering.

It fixes mixed Arabic/English direction and keeps code blocks LTR:
https://github.com/pawnsmaster/codex-rtl-toolkit

Would be happy to hear if it works for your case too.

I ran into this too and built an open-source patch for the Codex desktop app:

⭐ https://github.com/mmnaderi/codex-rtl

It patches the app locally, keeps code/file paths readable in LTR, adds smart RTL/force RTL modes, custom RTL fonts/line-height, and can be reverted with npx codex-rtl --restore.

It’s not a replacement for native upstream support, but it may help Arabic/Hebrew/Persian users meanwhile. I’m the author and would love feedback from people affected by this.

It works fine for RTL, but after running, I lost all my chats on the Codex workspace.

Native Persian RTL/BiDi support is still missing in ChatGPT Windows and the Codex VS Code extension

I am a paying Persian-speaking ChatGPT and Codex user. Proper right-to-left support has been repeatedly requested for a long time, but Persian text is still rendered incorrectly in both the ChatGPT Windows application and the Codex VS Code extension.

This is not merely a text-alignment issue. It is a bidirectional-text rendering problem.

Current problems

• Persian messages are not consistently rendered right-to-left.
• Mixed Persian and English text appears in the wrong visual order.
• Inline code, filenames, paths, commands, numbers, and punctuation reorder adjacent Persian words.
• The input composer and assistant responses behave inconsistently.
• Third-party RTL extensions that previously worked are no longer compatible with recent Codex extension versions.
• Users are forced to downgrade Codex or modify application files manually.

Expected implementation

Please implement native RTL and BiDi support in both ChatGPT and Codex:

• Use dir="auto" for message containers and the message composer.
• Apply unicode-bidi: plaintext to natural-language message content.
• Isolate code, commands, URLs, filenames, and paths with dir="ltr" and unicode-bidi: isolate.
• Provide an interface setting with Automatic, Right-to-left, and Left-to-right options.
• Add regression tests for mixed Persian/Arabic/Hebrew and English/code content.
• Ensure Markdown lists, tables, punctuation, inline code, code blocks, and copy buttons work correctly in RTL messages.

Impact

This issue makes long technical conversations extremely difficult to read and significantly reduces the usability of ChatGPT and Codex for millions of Persian, Arabic, Hebrew, and Urdu users.

Accessibility and internationalization should not depend on unsupported third-party patches. Please treat native RTL/BiDi support as a product bug and accessibility requirement rather than an optional cosmetic feature.

It works fine for RTL, but after running, I lost all my chats on the Codex workspace.

Don’t waste time on this issue. Use this one-click solution until OpenAI fixes it officially:
https://github.com/pawnsmaster/codex-rtl-toolkit

There is one important case beyond a global RTL rule or plain dir="auto":

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

The source is already in correct logical order: React is first, the Persian words follow it, and the period should appear at the visual left edge. dir="auto" / unicode-bidi: plaintext chooses LTR because React is the first strong run, even though the prose is overwhelmingly RTL. The inverse also occurs when an RTL token appears before English-majority prose.

For the app/extension renderer, I suggest:

• resolve direction per structural block (p, list item, heading, quote, and table cell), not once for an entire response;
• use Unicode strong-character majority (L versus R/AL), with first-strong as the tie fallback;
• set the chosen base explicitly, then isolate inline code, commands, paths, URLs, model names, and identifiers;
• keep code blocks and terminal transcripts LTR;
• expose Auto/LTR/RTL at the message/composer level;
• preserve logical source text for copy, accessibility, persistence, and search;
• leave pure-LTR content untouched.

This also avoids the risk reported above from tools that patch application files. A native integration should operate at the render boundary and be removable/idempotent, without modifying stored chats or model output.

Maintainer disclosure: I maintain BidiLens, an MIT-licensed toolkit built for this exact AI-output failure mode. Version 0.1.1 provides DOM, React, Markdown, streaming, terminal, CLI, and verification surfaces plus 918 schema-validated fixtures. I am offering it for engineering review/pilot and am not claiming OpenAI endorsement.

There is now a focused example of the policy integrated into another AI terminal renderer at NousResearch/hermes-agent#72508: it uses the host's existing bidi dependency, tests both majority directions and ties, and preserves an ASCII identity fast path. I would be glad to prepare the equivalent native patch when the relevant Codex app/extension renderer source is available.

The Windows CLI problem is a separate rendering layer tracked in #34871; CSS alone cannot solve terminal bidi or shaping.