Feature Request: RTL (Right-to-Left) support for Arabic content in Claude Desktop

This issue has been inactive for 30 days. If the issue is still occurring, please comment to let us know. Otherwise, this issue will be automatically closed in 30 days for housekeeping purposes.

As a Hebrew-speaking user from Israel, I find the lack of RTL (right-to-left) support in Claude Desktop a significant usability issue. Hebrew text is displayed left-to-right, which makes reading responses uncomfortable and unnatural. RTL support for Hebrew and Arabic is essential for users in the Middle East and beyond. Please prioritize this feature — it would make Claude genuinely accessible to millions of RTL-language users.

Hi! While waiting for official RTL support, I built a Windows patch that auto-detects Hebrew/Arabic text and applies the correct direction without breaking code blocks.
Repo: https://github.com/shraga100/claude-desktop-rtl-patch
It patches Claude Desktop's JS files directly, creates backups, and includes a restore option. Windows only, requires Node.js.
Hope it helps others until this gets built in natively!

Thank

Hi! While waiting for official RTL support, I built a Windows patch that auto-detects Hebrew/Arabic text and applies the correct direction without breaking code blocks. Repo: https://github.com/shraga100/claude-desktop-rtl-patch It patches Claude Desktop's JS files directly, creates backups, and includes a restore option. Windows only, requires Node.js. Hope it helps others until this gets built in natively!

Hi! Thank you so match. But I have Mac.

Same issue on the Claude Code desktop app on Windows. Hebrew text renders LTR instead of RTL, and mixed Hebrew/English content gets jumbled - words and fragments appear in the wrong order, making the text unreadable. The browser version (claude.ai) and the IOS app handles Hebrew correctly.

Same here. RTL support in Claude Desktop would be appreciated...

Same here. Support RTL languages in Claude Desktop for Mac (and WindowsO.

Thank > Hi! While waiting for official RTL support, I built a Windows patch that auto-detects Hebrew/Arabic text and applies the correct direction without breaking code blocks. Repo: https://github.com/shraga100/claude-desktop-rtl-patch It patches Claude Desktop's JS files directly, creates backups, and includes a restore option. Windows only, requires Node.js. Hope it helps others until this gets built in natively! Hi! Thank you so match. But I have Mac.

try this one:
https://github.com/soguy/claude-desktop-rtl-mac

I'm a daily Hebrew-speaking Claude user (Pro/Max subscriber) who relies heavily on both Chat and Cowork on the macOS Desktop app. The lack of native RTL support is a real barrier to my workflow.

Here's what I've tried so far:

1. Debug port injection (safe, non-destructive approach) — Tried launching Claude Desktop with --remote-debugging-port to inject RTL CSS via Chrome DevTools Protocol. All three methods failed: direct binary flag, open --args, and ELECTRON_EXTRA_LAUNCH_ARGS. Electron 30+ blocks --remote-debugging-port as a CLI argument, and Claude Desktop doesn't expose it any other way.

1. Community asar patch (soguy/claude-desktop-rtl-mac) — This creates a patched copy of the app with RTL support injected into the renderer JS. Chat works with RTL — but Cowork and Code show "Invalid installation: Claude's installation appears to be corrupted" and refuse to run. These features apparently have stricter integrity checks that detect the modified asar.

So the current situation is: the only way to get RTL in Chat requires breaking Cowork, which is the feature I need most.

On the web (claude.ai via Chrome), RTL works fine with browser extensions like RTL Responder. But the Desktop app — especially Cowork — has no browser extension ecosystem to fall back on.

What would help:
A simple dir="auto" or unicode-bidi: plaintext on message containers and the input area would solve 90% of this. The browser's native BiDi algorithm handles Hebrew/Arabic detection automatically — no custom logic needed. Code blocks can stay LTR with a targeted override.

This affects every Hebrew and Arabic speaker using Claude Desktop. Given that Cowork is desktop-only and has no Chrome extension workaround, native RTL support in the Desktop app is the only viable path forward.

Thank you for considering this.

Adding my voice as a Hebrew speaker: this is a real usability issue, not just cosmetic. When Claude responds in Hebrew or I write prompts in Hebrew, the text renders LTR and it's genuinely disorienting to read, especially when it combines English and Hebrew text.

Please fix, Hebrew in Claude (Chat) is LTR and should be RTL

+1

As a persian speaker it is frustrating. Please fix this.

+1

+1

+1

+1

Hi! I'm adding my voice to this issue as an Arabic speaker. The lack of RTL support makes Claude Desktop genuinely difficult to use — Arabic text renders LTR, alignment is wrong, and mixed Arabic/English responses are confusing to read. This affects millions of Arabic speakers who want to use Claude. I hope Anthropic prioritizes this soon. Thank you!

+1 — this is a serious accessibility gap.

Hebrew speaker here, paying Claude user, using Claude Desktop daily for work. The current LTR-only rendering makes Hebrew responses genuinely difficult to read, and mixed Hebrew/English content (common in tech) gets scrambled by the BiDi algorithm because message containers have no directional attributes.

The fix is well-documented: dir="auto" on message containers + unicode-bidi: plaintext on paragraph elements. Community patches (shraga100/claude-desktop-rtl-patch, soguy's Mac patch) already prove this works — but requiring users to bypass code signing to read their native language is not acceptable as a long-term solution.

This affects 520M+ users across Hebrew, Arabic, and Persian. Please prioritize.

Adding a Windows + Cowork perspective.

I'm a Hebrew-speaking developer using Claude Code daily, primarily through Cowork on Windows. The lack of RTL support is a real workflow blocker for me, not a cosmetic one:

• Mixed Hebrew/English content gets scrambled — common in tech contexts where I write prompts mixing Hebrew explanations with English code/identifiers. The BiDi algorithm has nothing to anchor to without dir="auto", so the visual order doesn't match the logical order.
• Cowork is desktop-only — unlike Chat, there's no browser fallback. The web extension workarounds (RTL Responder etc.) that work on claude.ai are not an option here.
• Community patches are not a viable path — the Mac patch (soguy/claude-desktop-rtl-mac) is already documented as breaking Cowork due to integrity checks (see @shai-2-0's comment above). On Windows (shraga100/claude-desktop-rtl-patch) the situation is better but every Claude Desktop update wipes the patch, and asking users to bypass code signing to read their native language isn't a sustainable solution.

As others have noted, the technical fix is minimal:

• dir="auto" on message containers and the input area
• unicode-bidi: plaintext on paragraph elements
• A targeted LTR override for code blocks (<pre>, <code>)

This leans entirely on the browser's native BiDi algorithm — no custom detection logic needed. Given that Cowork has no extension ecosystem, native RTL support in the Desktop app is the only realistic path for Hebrew/Arabic/Persian users who depend on this feature.

+1 to prioritization.

It's important to note that this is not solely about a few languages, such as Persian (Farsi), Hebrew, or even Arabic. That's why they sometimes downplay these issues and overlook the priority.

+1 to prioritization.

Until this is officially supported, I’ve developed a userscript workaround that fixes both the text direction (auto RTL/LTR) and font rendering issues in web.

How to use:

1. Install the Tampermonkey extension.
2. Create a new script and paste the code from the Gist above.
3. Save and refresh the page.

A useful reference for implementing RTL support is:

https://rtlstyling.com/posts/rtl-styling/

It covers many RTL edge cases (Arabic, Hebrew, mixed content, punctuation, layouts, etc.) and could help ensure a complete RTL implementation rather than only reversing text direction.

I agree—the lack of RTL support in Claude Desktop for both Mac and Windows is a clear accessibility gap. For users who rely on the official desktop application, the strict LTR-only rendering makes native Arabic responses genuinely difficult to read, especially with mixed-language content getting completely scrambled. This issue must be fixed natively within the desktop app itself, not via web browsers. Proper Arabic support is essential for us to work efficiently, so please prioritize a native solution for the desktop applications.