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.

Confirmed on Windows x64 with the Microsoft Store Codex app version 26.715.7063.0.

The RTL/BiDi problem affects both:

• the message composer while typing Arabic;
• the rendered user and assistant messages after sending.

Arabic text is visually reordered and becomes especially difficult to read when mixed with English words, IP addresses, port numbers, file paths, commands, brackets, or punctuation. The same text displays correctly in other Windows applications, so this appears specific to the Codex desktop renderer/composer.

Expected behavior:

• Arabic-first paragraphs should use proper RTL direction and right alignment;
• embedded English, code, paths, numbers, and URLs should remain isolated LTR;
• the composer and rendered messages should preserve the same readable order.

This remains reproducible in version 26.715.7063.0.

Confirmed on Windows x64 with the Microsoft Store Codex app version 26.715.7063.0. The RTL/BiDi problem affects both: the message composer while typing Arabic; the rendered user and assistant messages after sending. Arabic text is visually reordered and becomes especially difficult to read when mixed with English words, IP addresses, port numbers, file paths, commands, brackets, or punctuation. The same text displays correctly in other Windows applications, so this appears specific to the Codex desktop renderer/composer. Expected behavior: Arabic-first paragraphs should use proper RTL direction and right alignment; embedded English, code, paths, numbers, and URLs should remain isolated LTR; * the composer and rendered messages should preserve the same readable order. This remains reproducible in version 26.715.7063.0.

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

Confirmed on the current Codex Windows app with Arabic content.

Environment

• Codex Windows app package: 26.715.10079.0
• OS: Windows 11 Pro
• OS version: 10.0.26200
• Build: 26200
• Primary language: Arabic
• Reproduced: 2026-07-24

Scope

This is more than left alignment. Mixed Arabic and LTR technical content is visually reordered inside assistant messages. The problem is especially severe with:

• English product or API names inside Arabic prose
• inline code and Markdown links
• Windows paths and URLs
• hashes or identifiers beginning with digits
• commands, numbers, punctuation, and version strings
• interface-generated progress/status text

In one reproducible case, a hash beginning with digits was visually split around a Markdown link, making the value appear to belong to a different part of the sentence.

Impact

This is not a cosmetic localization issue. It changes the visual reading order of technical instructions, paths, hashes, numbers, and commands. Arabic users must mentally reconstruct the intended sentence, creating a real risk of misreading operational steps.

Prompt-level workarounds do not solve the renderer. Requiring the assistant to place every Latin fragment on a separate line is not practical for developer workflows and cannot fix interface-generated status text.

Expected behavior

• Arabic prose blocks should be detected as RTL and use natural start alignment.
• Inline LTR fragments should remain isolated without reordering surrounding Arabic.
• Code blocks, terminal output, paths, URLs, commands, and identifiers should remain LTR.
• The composer, user messages, assistant messages, Markdown lists/links, and status text should behave consistently.

Suggested renderer-level fix

• Apply per-block direction detection such as dir="auto".
• Use text-align: start for prose blocks.
• Apply bidi isolation to inline code, links, paths, URLs, hashes, and identifiers.
• Keep preformatted and code blocks explicitly LTR.
• Add regression fixtures for Arabic mixed with inline code, links, paths, hashes, lists, tables, numbers, and status text.

This also reproduces the Windows-specific class of failure documented in #32157, now confirmed with Arabic on a newer app package.

In-app feedback was submitted from the affected Arabic/Windows session.

Feedback/session ID:

019f91f6-ddb1-7d73-a28c-c230b2db5cb6

The submitted feedback included the full reproduction description, environment, impact, expected behavior, and suggested renderer-level fixes. The feedback dialog did not allow the reporter to attach the screenshots directly. However, the screenshots were already provided inside the affected Codex conversation and show the mixed Arabic/LTR ordering failure in actual assistant output.

This links the public report to the internal affected session for investigation.

Persian/Arabic user here. I want to add a workaround that I haven't seen in this thread, and what it reveals about the trigger. Unlike the local patches posted above (codex-rtl and similar — thanks to the people who built those), this one needs no install and no patching, so it also works in the CLI and the VS Code extension, not just the desktop app.

The trigger is inline language mixing

When Codex answers in Persian or Arabic, it puts English words inside the RTL sentence — technical terms, filenames, library names, numbers. Those inline LTR runs inside an RTL paragraph are what break the rendering. The more English tokens in a sentence, the worse it gets. This matches the original report here: an Arabic sentence with one English word in the middle displays in the wrong order.

Workaround: ask for one language per paragraph

I instruct Codex to keep Persian/Arabic in one paragraph and English in the next one — even when the English part is a single word. That solves roughly 90% of the problem for me, and it is what I use day to day.

It is not a fix. You have to instruct the model every time, and it forces awkward writing. But it isolates the trigger precisely: the breakage is concentrated in paragraphs that mix both directions, not in RTL text on its own.

Why this points at the fix

The fact that simply separating the two directions into different paragraphs recovers most of the readability says the missing piece is per-paragraph base direction resolution — exactly what the Unicode Bidirectional Algorithm (UAX #9) rules P2/P3 specify, and what unicode-bidi: plaintext / dir="auto" enable in a browser or Electron context.

If each paragraph resolved its own base direction from its first strong character, my manual workaround would become unnecessary, and the remaining 10% would be handled too — the case manual separation fundamentally cannot address: a single sentence that legitimately contains both directions. In developer conversations that is the common case, since nearly every technical term is Latin script.

Two notes on scope:

• This is not only the desktop app. The same inline-mixing failure shows up in the Codex CLI/TUI (#34871) and the VS Code extension chat panel (#30414). The terminal case needs an actual UAX #9 reordering pass before emit rather than a CSS property, since most terminals implement no bidi engine of their own.
• Whatever the fix, it should keep code blocks, file paths, and inline code LTR while the surrounding prose resolves as RTL. unicode-bidi: plaintext on prose containers plus an explicit dir="ltr" on code elements gets that for free.