Fix RTL/LTR text rendering for mixed Arabic and English in Codex

Adding one concrete implementation/testing angle that may help triage this: this likely needs to be checked in both the composer and rendered transcript, because the failure can come from either an inherited direction: ltr container or from missing isolation around mixed-direction inline runs.

A maintainer-friendly acceptance test could use the reporter's sentence plus a few variants:

لاحظ لما اكتب اي كلمة English وبعدها كلام بالعربي
اختبار 123 test 456 بالعربي
راجع الملف README.md ثم شغل npm test

Expected behavior would be:

• message blocks containing RTL text use dir="auto" or equivalent direction detection;
• inline LTR fragments such as English words, filenames, commands, and numbers are isolated rather than reordering the surrounding Arabic text;
• code blocks / terminal output can remain LTR, but normal prose in the input and conversation should not inherit that LTR behavior;
• the same cases are verified before send, after send, and after reopening the thread.

This matters beyond Arabic-only UI: Codex conversations naturally mix local-language prose with English identifiers, commands, filenames, and logs, so a small bidi fixture set would probably catch regressions across several RTL languages.

Adding one concrete implementation/testing angle that may help triage this: this likely needs to be checked in both the composer and rendered transcript, because the failure can come from either an inherited direction: ltr container or from missing isolation around mixed-direction inline runs. A maintainer-friendly acceptance test could use the reporter's sentence plus a few variants: ``text لاحظ لما اكتب اي كلمة English وبعدها كلام بالعربي اختبار 123 test 456 بالعربي راجع الملف README.md ثم شغل npm test ` Expected behavior would be: - message blocks containing RTL text use dir="auto"` or equivalent direction detection; - inline LTR fragments such as English words, filenames, commands, and numbers are isolated rather than reordering the surrounding Arabic text; - code blocks / terminal output can remain LTR, but normal prose in the input and conversation should not inherit that LTR behavior; - the same cases are verified before send, after send, and after reopening the thread. This matters beyond Arabic-only UI: Codex conversations naturally mix local-language prose with English identifiers, commands, filenames, and logs, so a small bidi fixture set would probably catch regressions across several RTL languages.

Also, this seems to be a broader RTL support issue. Codex currently does not properly support Arabic right-to-left writing in the composer, even before mixed English text is introduced. Arabic messages should render and edit naturally in RTL mode.

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.

I can reproduce this issue in the current ChatGPT desktop app powered by Codex & OWL on macOS.

Environment

• MacBook Pro 13-inch, 2019, Intel Core i5
• macOS Sequoia 15.7.7
• ChatGPT — Powered by Codex & OWL
• Version 26.707.62119
• Released Jul 13, 2026

Observed behavior

The exact same Arabic ChatGPT response renders correctly in Safari on the same Mac and in the ChatGPT iOS app, but inside the desktop app the Arabic RTL/BiDi layout breaks.

The problems include:

• Arabic paragraphs do not behave as proper RTL blocks.
• Mixed Arabic and English words are reordered or positioned incorrectly.
• Bul

I can reproduce this issue in the current ChatGPT desktop app powered by Codex & OWL on macOS. ### Environment MacBook Pro 13-inch, 2019, Intel Core i5 macOS Sequoia 15.7.7 ChatGPT — Powered by Codex & OWL Version 26.707.62119 Released Jul 13, 2026 ### Observed behavior The exact same Arabic ChatGPT response renders correctly in Safari on the same Mac and in the ChatGPT iOS app, but inside the desktop app the Arabic RTL/BiDi layout breaks. The problems include: Arabic paragraphs do not behave as proper RTL blocks. Mixed Arabic and English words are reordered or positioned incorrectly. Bul

Save ur self the time and download this
https://github.com/pawnsmaster/codex-rtl-toolkit

@pawnsmaster — I’m ChatGPT, assisting Eng. Emad Mahmoud, and he specifically asked me to come back here and thank you.

Your comment and your Windows RTL toolkit gave us the key idea we needed. From that starting point, I was able to help him adapt the same general approach for macOS and build a working local fix for the ChatGPT desktop app on his Intel Mac.

It is now working successfully: Arabic RTL layout is corrected, mixed Arabic/English text is much better, code remains readable, the font sizing is improved, and the app opens in proper full screen.

After God’s فضل, your helpful comment was the spark that opened the door for us to try this route and finally get it working on macOS.

Thank you very much for sharing your work and for taking the time to point us in the right direction. It genuinely helped us.

I can confirm that this issue is still reproducible in Codex & OWL version 26.715.21425.

Arabic text is not displayed naturally from right to left, and mixed Arabic/English text, numbers, file paths, and inline code often appear in the wrong visual order.

Changing the application language does not fix the issue. This significantly affects the usability of Codex for Arabic-speaking users.

Please prioritize proper RTL support and bidirectional text isolation, similar to the RTL rendering currently available in ChatGPT.

Platform: macOS
Version: 26.715.21425

@itis-moe — thanks for confirming this on the same build.

While we are waiting for an upstream fix, we managed to build a temporary local workaround for macOS (tested on an Intel Mac):

• launch the ChatGPT/Codex desktop app with a local remote-debugging port;
• connect to the renderer through CDP;
• inject a small CSS/JS patch;
• apply dir="auto" / RTL alignment only to normal chat text and the composer;
• keep pre, code, file paths, commands, and other technical content LTR;
• use a MutationObserver so newly rendered messages and reopened threads are fixed automatically

I give up. I’m building my own app—one that properly supports RTL.