[BUG] Desktop app (macOS): RTL text (Persian/Arabic/Hebrew) renders broken, especially when mixed with LTR code and paths

Summary

In the Claude Code desktop app (macOS), assistant responses written in right-to-left languages render incorrectly. The problem is worst — and in practice makes replies unreadable — when a reply mixes RTL prose with the LTR technical tokens that are unavoidable in a coding tool: file paths, identifiers, commands, error strings, and inline code.

The composer is fine: text typed into the prompt box displays correctly while typing. Everything breaks on submit, in the rendered transcript.

Environment

• Claude Code 2.1.270, desktop app (Code tab), macOS 15 (Darwin 25.5.0), Apple Silicon
• Reproduces regardless of project or model
• Reporter's primary language: Persian (Farsi)

Steps to reproduce

1. Open the Claude Code desktop app on macOS.
2. Ask a question in Persian, Arabic, or Hebrew that will produce a reply containing file paths or code identifiers. For example: فایل src/auth.ts را بررسی کن و بگو تابع verifyToken چه می‌کند
3. Read the rendered reply in the transcript.

Expected

The reply lays out right-to-left. Embedded LTR runs (src/auth.ts, verifyToken, npm test) stay left-to-right inside it, per the Unicode Bidirectional Algorithm (UAX #9). Punctuation attaches to the correct end of each run. Paragraph alignment follows the paragraph's base direction.

Actual

• The paragraph base direction stays LTR, so RTL sentences are laid out against their natural direction.
• Directional runs are not resolved: an English path or identifier inside a Persian sentence lands in the wrong position, so the sentence must be mentally reassembled to be read.
• Sentence-final punctuation (., :, ?, ،) jumps to the wrong end of the line.
• Digits, list markers, and bullets in numbered or bulleted lists sit on the LTR side while the text sits RTL.
• Longer mixed replies are effectively unreadable; the reporter's practical workaround is to ask for English instead, in their own language's tool.

Why this matters

This is not a single-locale nicety. RTL scripts are the everyday writing systems of a large share of the world's developers:

| Language | Script | Approx. speakers | Notes |
|---|---|---:|---|
| Arabic | Arabic | ~400M | Official in 20+ countries |
| Persian / Farsi | Perso-Arabic | ~130M | Iran, Afghanistan (Dari), Tajikistan |
| Urdu | Perso-Arabic | ~230M | Pakistan, India |
| Hebrew | Hebrew | ~9M | Israel; large local tech industry |
| Pashto | Perso-Arabic | ~40M | Afghanistan, Pakistan |
| Kurdish (Sorani) | Perso-Arabic | ~8M | Iraq, Iran |
| Sindhi | Perso-Arabic | ~30M | Pakistan, India |
| Punjabi (Shahmukhi) | Perso-Arabic | ~80M | Pakistan |
| Uyghur | Perso-Arabic | ~10M | Xinjiang |
| Azerbaijani (Iran) | Perso-Arabic | ~15M | Written RTL in Iran |
| Balochi, Kashmiri, Dhivehi, Yiddish, Syriac, Thaana | various RTL | — | Smaller but affected identically |

Roughly one in eight people writes in an RTL script. Every one of them hits this the moment they ask Claude Code a question in their own language.

The mixed-direction case is what makes this specific to a coding tool rather than a general chat product. A monolingual Persian paragraph degrades gracefully; a Persian paragraph containing src/auth.ts:42 does not. Since file paths, symbols, commands, and stack traces are the substance of every Claude Code answer, essentially no useful reply in an RTL language renders correctly today.

Related issues

The problem is reported repeatedly across surfaces, which suggests bidi handling is missing at a shared layer rather than in one renderer:

• #38005 — RTL support for Hebrew & Arabic in Claude Desktop / Cowork
• #16814 — RTL support for Arabic content in Claude Desktop
• #79402 — RTL support + word-boundary wrapping for Hebrew/Arabic (desktop)
• #83969 — RTL: list markers, digits and the Code-mode composer render LTR
• #90530 — BiDi: question mark misplaced in pure Hebrew text (Desktop)
• #45652 — RTL text renders incorrectly in Claude Code terminal output
• #30100 / #29662 — RTL rendering broken in the VS Code extension
• #12635 / #11050 — original RTL feature requests

Suggested fix

For the desktop app's transcript renderer, the standard approach is small:

1. Detect the base direction of each rendered block from its first strong directional character (UAX #9 P2/P3), rather than assuming LTR.
2. Apply direction: rtl on blocks that resolve RTL, and set unicode-bidi: plaintext so each paragraph picks its own base direction and embedded LTR runs resolve correctly without markup.
3. Keep fenced code blocks and inline code LTR unconditionally — code is LTR regardless of surrounding prose.
4. Mirror list markers, blockquote bars, and bullets to the correct side for RTL blocks.
5. Align RTL paragraphs to the right edge (text-align: start once direction is correct).

For the terminal, the equivalent is a UAX #9 pass plus Arabic shaping before drawing. The community mod aliir74/claude-code-rtl demonstrates it works by piping transcript lines through fribidi, but it can only reach the terminal surface, so desktop-app users have no workaround at all.

Current workaround

None for the desktop app. Users either switch to a terminal (Ghostty) with the community mod installed, or stop writing in their own language.