Hebrew RTL/BiDi rendering is broken in ChatGPT/Codex desktop workflows on macOS

Open 💬 2 comments Opened Jul 9, 2026 by ShalevZorany

Hebrew RTL/BiDi rendering is broken in ChatGPT/Codex desktop workflows on macOS

Environment

  • App: Official ChatGPT desktop app for macOS
  • Observed installed version on reporter machine: ChatGPT 26.707.31123, build 5042
  • Platform: macOS 27.0 (26A5378j), Apple Silicon / arm64
  • Region/language: Israel, Hebrew, right-to-left (RTL)
  • Workflow: ChatGPT desktop app with integrated Codex/GPT coding workflow
  • Related surface: Codex Desktop / Codex panels surfaced through the ChatGPT desktop workflow

Summary

RTL support for Hebrew in the official ChatGPT desktop/Codex macOS workflow is incomplete. This is especially disruptive in coding conversations, where a single message often mixes Hebrew instructions with English identifiers, file paths, terminal output, Markdown, URLs, numbers, GitHub issue/PR references, and inline code.

This is not only cosmetic. For Hebrew users, the visual order of text can become confusing enough that it slows down reading, makes instructions harder to verify, and makes coding workflows significantly less reliable.

Investigation notes

Steps to reproduce

  1. Open the official ChatGPT desktop app on macOS.
  2. Start a normal ChatGPT/Codex conversation.
  3. Use Hebrew as the primary instruction language.
  4. Include mixed LTR technical content in the same message, such as:
  • inline code
  • file paths
  • URLs
  • terminal output
  • Markdown lists
  • numbers
  • GitHub issue/PR references
  • English API/class/function names
  1. Send the message and compare how it appears in:
  • the composer before sending
  • the sent user message
  • the assistant response
  • Codex-related panels / transcript areas
  • sidebars or thread/task lists that display Hebrew titles
  1. Change the app language to Hebrew, if available, and repeat the same examples.

Reproduction examples

Paste these examples exactly as separate messages and compare the composer, sent message, and rendered assistant response.

Mixed Hebrew + inline code

תבדוק למה `npm test` נכשל אחרי השינוי בקובץ `src/app/page.tsx`, ואז תציע תיקון מינימלי.

Expected: Hebrew sentence reads right-to-left. Inline code stays left-to-right and does not reorder the surrounding Hebrew.

Hebrew + file path + line number

השגיאה נמצאת ב־`/Users/me/project/src/components/Header.tsx:42`, תבדוק אם ה־prop בשם `isOpen` מועבר נכון.

Expected: The file path and line number remain LTR as one isolated technical fragment. Hebrew punctuation and wording remain in the correct visual order.

Hebrew + URL + GitHub reference

תפתח את https://github.com/openai/codex/issues/30129 ותבדוק אם #26250 מתאר את אותה בעיית RTL.

Expected: URL and issue number remain readable LTR; the Hebrew sentence remains naturally RTL.

Hebrew + Markdown list

צריך לבדוק:
- האם `README.md` עודכן
- האם `pnpm build` עובר
- האם הקישור https://example.com/docs תקין

Expected: Bullets align naturally for RTL text, while code/URL fragments remain LTR and do not shift punctuation.

Hebrew + numbered steps

1. פתח את `Settings`
2. שנה את השפה ל־עברית
3. שלח הודעה עם `git status`

Expected: Numbered-list markers, Hebrew text, and inline code all remain visually coherent.

Hebrew + table

| קובץ | פעולה |
| --- | --- |
| `src/main.ts` | לבדוק import |
| `README.md` | לעדכן הוראות |

Expected: Table columns remain stable; inline code remains LTR; Hebrew cell text remains readable.

Hebrew + terminal output

הרצתי:
git status

וקיבלתי:
modified: src/app/page.tsx
untracked: docs/rtl-notes.md

Expected: Hebrew explanatory text is RTL, but terminal output remains LTR and monospaced.

Expected behavior

  • Hebrew messages should be detected as RTL and right-aligned where appropriate.
  • Mixed Hebrew/English text should follow correct Unicode Bidirectional Algorithm behavior.
  • Inline LTR fragments such as code identifiers, filenames, paths, URLs, branch names, commands, stack traces, and GitHub references should be isolated from surrounding Hebrew text.
  • Code blocks, terminal output, diffs, logs, paths, URLs, and tables should remain LTR and readable.
  • Lists, bullets, numbered steps, tables, Markdown, and inline code should not visually reorder punctuation or break the sentence.
  • The composer should behave correctly before send, not only after the transcript renders.
  • The sent user message and assistant response should render consistently after reopening the thread/task.
  • Changing the app language to Hebrew should improve interface directionality, but message rendering should still be correct even when the UI language is English.
  • Sidebar conversation/task titles and Codex panels should handle Hebrew titles naturally.

Actual behavior

  • Hebrew and mixed Hebrew/English coding messages are not consistently rendered with RTL direction.
  • Text alignment often appears LTR even when the dominant paragraph language is Hebrew.
  • English/code fragments can visually disturb the surrounding Hebrew sentence.
  • Punctuation, parentheses, issue numbers, paths, and inline code can appear in confusing positions.
  • Markdown lists, numbered steps, and tables are at risk of becoming visually hard to scan.
  • Code-oriented content needs to remain LTR, but ordinary Hebrew prose should not inherit LTR behavior from surrounding technical UI containers.
  • Changing the app language to Hebrew is not sufficient if the chat transcript/composer still lacks message-level direction detection and bidi isolation.

Screenshots or screen recording to attach

Please attach:

  1. A screenshot of the composer before sending one of the examples above.
  2. A screenshot of the sent message in the conversation.
  3. A screenshot of the assistant response containing mixed Hebrew, inline code, paths, and Markdown.
  4. If possible, a short screen recording showing:
  • typing/pasting the Hebrew mixed-content example
  • sending it
  • comparing the desktop app rendering with the same text in ChatGPT web or another app that handles BiDi correctly
  1. Include the app version from About ChatGPT / About Codex.

Impact

This materially affects Hebrew-speaking users, especially developers using Codex/GPT workflows.

The affected workflow naturally combines:

  • Hebrew instructions
  • English code
  • terminal output
  • file names and paths
  • URLs
  • GitHub issue/PR references
  • Markdown
  • numbers
  • mixed Hebrew/English explanations

When RTL/BiDi handling is wrong, the user has to mentally reconstruct the sentence order, verify whether code/path fragments are in the right place, and often rewrite messages in English to avoid UI breakage. That reduces productivity and makes the product significantly harder to use for RTL-language users.

Suggested technical fixes

  • Apply dir="auto" or equivalent direction detection to user and assistant message blocks.
  • Use text-align: start rather than hardcoded left alignment for natural paragraph alignment.
  • Apply bidi isolation to inline technical fragments:
  • unicode-bidi: isolate
  • <bdi> where appropriate
  • direction-aware rendering for inline code, URLs, filenames, commands, branch names, and issue references
  • Keep code blocks, terminal output, diffs, logs, and preformatted text explicitly LTR:
  • direction: ltr
  • unicode-bidi: isolate
  • stable monospaced layout
  • Test both composer and transcript rendering.
  • Test after send, after editing/regeneration, and after reopening a conversation/task.
  • Add a regression fixture suite for Hebrew, Arabic, Persian, and Urdu mixed with:
  • English words
  • numbers
  • Markdown
  • inline code
  • fenced code blocks
  • file paths
  • URLs
  • GitHub references
  • terminal output
  • tables

Why this may feel like a regression

The issue becomes much more severe with the integrated Codex/GPT desktop workflow because coding conversations contain far more mixed-direction technical content than ordinary chat. Even if basic Hebrew chat was previously tolerable, Codex-style usage exposes many more BiDi edge cases in the composer, transcript, side panels, file references, terminal output, and Markdown rendering.

View original on GitHub ↗

This issue has 2 comments on GitHub. Read the full discussion on GitHub ↗