RTL (Right-to-Left) Support for Hebrew & Arabic in Claude Desktop / Cowork

he problem is very annoying I would like to see it solved

check it out https://github.com/MSApps-Mobile/claude-plugins/tree/main/plugins/rtl-chat-fixer

Investigated this on Claude.app v1.2581.0 (macOS, Apple Silicon). The fix is 2 lines of CSS in a single existing injection point — no architectural changes needed.

Root cause

Claude.app loads claude.ai in WebContentsView instances. Each view already receives post-load CSS injection in .vite/build/index.js:

e.on("did-finish-load", () => {
  e.insertCSS("* { -webkit-app-region: no-drag !important; app-region: no-drag !important; }")
});

That exact string appears 3 times (main window + cowork artifact + one more view). Nothing in the injected CSS — or anywhere else — tells Chromium's BiDi engine to apply plaintext mode to text elements, so mixed Hebrew/English content renders in logical order instead of visual order.

Proposed fix

Extend each of the 3 insertCSS calls with:

p,li,blockquote,td,th,figcaption,h1,h2,h3,h4,h5,h6,textarea,[contenteditable]{unicode-bidi:plaintext}
pre,code,pre *,code *,kbd,samp{unicode-bidi:normal;direction:ltr;text-align:left}

• unicode-bidi: plaintext ≡ HTML dir="auto" — direction is determined per paragraph from the first strong character
• Targets text-content elements only, so layout (flex/grid/alignment) and text-align are untouched
• Code blocks stay LTR so technical content doesn't get false RTL detection

Why this is worth picking up now

• ~510M users affected (Hebrew 10M, Arabic 400M, Persian 110M). Many work in tech and mix RTL with English daily — every chat message is affected.
• Sibling issue #30080 (VS Code extension, reported 2026-03-02) was auto-closed as stale with zero Anthropic engagement. Please don't let this one go the same way.
• Fix is literally 2 lines of CSS in a single existing code path. No new dependencies, no new components, no claude.ai frontend changes required.

Happy to open a PR if the relevant code is in a public repo.

+1 on this. Daily user of Claude Code Desktop on Windows, working in Hebrew on a real CRM project. Mixed Hebrew+English renders badly — punctuation flips, inline English tokens and code snippets scramble, making it hard to read reviews or explanations that mix both languages.

The CSS fix proposed above is minimal and the injection point has already been identified. Would really appreciate prioritization — this isn't a nice-to-have, it affects core usability for RTL-language developers.

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!

I’m joining this request! this is extremely critical.

The lack of RTL (right-to-left) support in Claude Desktop is a major usability barrier for users working in Hebrew, Arabic, Persian, Urdu, Pashto, Kurdish, and other RTL languages - over 800 million native speakers worldwide.

Mixed RTL/English text (very common in technical and professional work) renders with scrambled word order, misplaced punctuation, and shifted numbers. This makes the app unusable for daily work in these languages.

The fix should be small at the CSS level - adding dir="auto" to message containers and unicode-bidi: plaintext to paragraph elements, while keeping code blocks LTR. The browser detects text direction from the first strong character automatically.

This is both an accessibility issue and a significant market opportunity in the Middle East and South Asia, where competing AI tools have already addressed RTL rendering.

Please prioritize this. The "stale" tag on this issue is misleading - the underlying problem affects daily users right now.

This is still a major issue.
RTL (Hebrew/Arabic) text is essentially unusable when mixed with English — which is the default in technical conversations. Word order breaks, punctuation flips, and inline English/code tokens get scrambled.
This isn’t a niche edge case — it affects real daily usage for hundreds of millions of users working in mixed RTL/LTR environments.
The fix is straightforward and already well understood:
Add dir="auto" to message containers
Apply unicode-bidi: plaintext to text elements
Keep code/pre explicitly LTR
This can be solved at the rendering layer with minimal changes, no architectural impact.
Would really appreciate prioritizing this — currently this blocks practical usage for RTL-speaking developers.

doesn't fix desktop but for vs code/cursor there's this: https://marketplace.visualstudio.com/items?itemName=Sapphify.claude-rtl-auto

I found this, didn't try it myself but I know its suppose to be from a
good source, hope it helps

כל מי שמשתמש ב-Claude Code בעברית מכיר את התסכול הזה 😤
שורות הולכות משמאל-לימין ואתם חורקים שיניים בניסיון להבין מה לקרוא.
השבוע אני 10 שעות ביום בתוך Claude Code (בקרוב אנגיש לכם את המידע הזה, יש
פריצות דרך הזויות!!). מצב Deep work על פרויקטים, וככל שאני יותר זמן בפנים,
ככה התסכול הקטן הזה גוזל יותר אנרגיה. כל פעם שאני שואל שאלה בעברית, התשובה
חוזרת מבולגנת - חצי משמאל, חצי מימין.
ואז נחשפתי לתוסף גאוני (תודה ליחיאל בר-יהודה המפתח) שפותר בדיוק את זה. כל
הצ'אט עם Claude מסתדר RTL נקי. העברית מימין לשמאל, והקוד נשאר באנגלית כמו
שצריך. עובד מושלם וחינמי לגמרי.
ככה מתקינים ב-30 שניות:
✅ נכנסים ל-VS Code, Antigravity או Cursor.
✅ לוחצים על Extensions בצד שמאל
✅ מחפשים: Claude Code RTL Support ומורידים
זהו (:
*כמובן אתם צריכים שיהיה לכם את קלוד קוד מותקן לפני כן.
עדן
#בינה_אנושית_בעולם_מלאכותי

בתאריך יום ה׳, 7 במאי 2026, 04:14, מאת TheMaker @.***>:

Ziondido left a comment (anthropics/claude-code#38005) <https://github.com/anthropics/claude-code/issues/38005#issuecomment-4393356464> doesn't fix desktop but for vs code/cursor there's this: https://marketplace.visualstudio.com/items?itemName=Sapphify.claude-rtl-auto — Reply to this email directly, view it on GitHub <https://github.com/anthropics/claude-code/issues/38005#issuecomment-4393356464>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/CA42D6NQWFCTVX7LSP7VNEL4ZPPPJAVCNFSM6AAAAACW4XDL76VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHM2DGOJTGM2TMNBWGQ> . Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>. You are receiving this because you commented.Message ID: @.***>

I support this, it needs a real solution. I work with Android Studio and there is no solution for this, please. The situation is unbearable.

+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.

+1 from a Hebrew-speaking user on Windows 11.

I work daily in Claude Desktop with Cowork, and the current RTL
rendering makes mixed Hebrew/English/code responses practically
unreadable — words appear in scrambled order, and switching
between Hebrew text and English code blocks visually "jumps."

The proposed dir="auto" + unicode-bidi: plaintext fix is exactly
the right approach (it's the same pattern Slack and Notion use).

This would be a major quality-of-life improvement for Hebrew/Arabic/
Persian speakers working with Claude. Would love to see this
prioritized. Thank you!

Adding my voice to this, because honestly it's the single biggest source of friction in my day-to-day, and I don't think the Cowork angle has really been driven home yet.

I'm a Max subscriber and I run Claude Desktop on both Windows and macOS. Most of my real work isn't in the plain chat — it's in Cowork, where I'm running multi-step tasks, reviewing the files it generates, and going back and forth on outputs. I work in Hebrew, and like pretty much everyone doing technical work in Israel, almost every sentence I write mixes Hebrew with English: framework names, file paths, commands, product names. That mix isn't an edge case for us, it's just how we talk.

And right now that exact mix is what breaks. It's not that the text is "a little off" — the word order in any mixed line comes out genuinely scrambled. Something as ordinary as פתח טאב חדש ל-claude.ai ורענן אותו עם Ctrl+Shift+R lands on screen with the Hebrew words in the wrong order and the English/code pieces dropped in the wrong spots. I end up reconstructing every line in my head just to read what I or Claude actually wrote. Over a full Cowork session it's genuinely draining, and it's the kind of thing that makes me lose my train of thought mid-task. It hits both what I type and what Claude sends back.

The frustrating part is that the web is basically solved. There's a Stylus userstyle and the gilhanan/claude-rtl extension, and I use one on claude.ai in the browser — works great. But those are browser-only by nature, and Cowork doesn't exist in the browser. It only lives in the Desktop app, and the Desktop app is the one place none of these fixes can reach. So for the surface where I spend most of my time, there's just nothing.

The only thing that does reach the app is the unofficial binary patch (shraga100/claude-desktop-rtl-patch), and I'm not willing to go near it on a Max account — by its own README it rewrites app.asar, patches the hash inside claude.exe, and gets around the cowork-svc integrity check, which it openly says can break verification and risk the account under the ToS. I shouldn't have to choose between unreadable Hebrew and an unsigned, modified app. The fact that several of these patches and extensions even exist should say something about how many of us are quietly struggling with this.

The actual fix is small and well understood. Give the message containers, the input box, and the Cowork text surfaces a real base direction — dir="auto" plus an actual direction: rtl on RTL paragraphs, so the BiDi algorithm orders the embedded English/code runs correctly (alignment alone doesn't fix the ordering, the per-element direction is what does). Keep pre/code locked to LTR with unicode-bidi: isolate so a Hebrew comment can't flip a code line. A simple auto/rtl/ltr toggle in settings would be the cherry on top. It's the same thing VS Code and every modern editor already do, and the browser fixes already prove the approach works — it just needs to live inside the Desktop and Cowork renderer.

This affects a lot of people — Hebrew, Arabic, Persian, that's hundreds of millions of speakers — but I'll speak for myself: I picked Desktop specifically for Cowork, and in my own language the feature I'm paying for is close to unusable. I'd gladly help test a fix on either Windows or macOS, in Hebrew, in Cowork, whenever it's ready. Thanks for reading this far.

Still reproduces on Claude.app v1.9659.2 (macOS, Apple Silicon) — confirming this is not stale.

Verified that @achiya-automation's proposed injection point is still present in the current build:

• The main-process did-finish-load → insertCSS("* { -webkit-app-region: no-drag !important; app-region: no-drag !important; }") call still exists (now packed in Contents/Resources/app.asar; 4 insertCSS call sites, 24 app-region: no-drag references).
• unicode-bidi:plaintext does not appear anywhere in the bundle — so the fix has not landed.

This means the 2-line CSS fix from the earlier comment maps cleanly onto the latest version with no rework needed:

p,li,blockquote,td,th,figcaption,h1,h2,h3,h4,h5,h6,textarea,[contenteditable]{unicode-bidi:plaintext}
pre,code,pre *,code *,kbd,samp{unicode-bidi:normal;direction:ltr;text-align:left}

Real-world impact: I work daily in Hebrew + English mixed, and every chat message in Claude Desktop / Cowork / Claude Code renders in logical order instead of visual order, which makes mixed-language content unreadable. Switching to claude.ai in a browser is the only current workaround, which defeats the purpose of the desktop app for RTL users.

Please don't let this go stale like the VS Code sibling issue (#30080). The fix is small, well-scoped, and confirmed to still apply.

Reading in Claude is a complete disaster when the text is in Arabic mixed with English words. I literally have to copy the entire response into Microsoft Word just to be able to read it properly — the word order gets completely scrambled due to missing RTL support.

How is it possible that the great Anthropic is neglecting this catastrophic issue for hundreds of millions of users? This affects not only Arabic speakers, but also speakers of Hebrew, Persian/Farsi, Urdu, and other RTL languages worldwide. RTL support is a basic accessibility requirement, not a luxury feature. Please prioritize this!

if you can fix this problem as soon as possible

Can you fix it soon?

Also affecting claude.ai web + desktop app for Hebrew, June 2026, still broken

For anyone who needs this on the macOS desktop app right now (not just the web), I built Claude-UniMath — an RTL patch that also handles math correctly, isolating KaTeX/LaTeX as upright LTR islands inside Hebrew/Arabic/Persian text:

https://github.com/DavidiBellaire/Claude-UniMath

It's a stopgap until native RTL ships — which I'd still love to see. Hope it helps others here. 🙏

+1 — and flagging that Cowork makes this materially worse than regular chat.

I rely on Cowork for production Hebrew work (engineering plating-line spec tables, accounting payment-demand generation), where replies constantly mix Hebrew with English identifiers, file names, and numbers. The result is the "scrambled BiDi" problem: words flip sequence, parentheses and punctuation jump to the wrong side, and (team) / מ-500 / ל-Q3-style fragments land in the wrong place. Long mixed paragraphs become genuinely unreadable.

This is an accessibility issue affecting hundreds of millions of RTL speakers, and right now it blocks Cowork as a serious tool for any RTL professional workflow. Please prioritize the renderer-level fix.

+1 — this is a real daily pain point. I use Claude Desktop on Windows in Hebrew, and the lack of RTL makes both Hebrew responses and my own input render with broken word order. The only current workaround is an unofficial patch that modifies the app binaries and breaks on every auto-update. Native RTL support (auto-detecting direction per message/paragraph, like dir="auto") would solve this cleanly for both Hebrew and Arabic users. Would love to see this prioritized. 🙏

+1 - its strange that a simple problem have not been solved fast.

+1 , there's a large community of Hebrew speaking developers in Israel hitting this daily, and the lack of native RTL support is pushing some toward third party patches that modify the Claude Desktop binary directly and install a self-signed certificate to bypass Windows' trust checks. That's a real security risk just to get readable text, and it breaks on every update.
A native fix like dir="auto" on message containers would remove the need for that entirely, and would help Arabic speakers too.

+1 from a Hebrew-speaking Mac user. This is a daily problem for me — mixed Hebrew/English in Claude Desktop renders with scrambled word order and punctuation on the wrong side, which makes longer conversations genuinely hard to read.
I tried the community workaround (the macOS asar patch that injects RTL CSS). It does help with alignment, but it's buggy, breaks on each app update, and requires re-patching and bypassing code signing — clearly not something most users should have to do. The dir="auto" approach described above would solve this natively and cleanly. Please consider prioritizing it; it affects a large number of RTL users who work in mixed Hebrew/English every day.

Hebrew-speaking user here. Mixed RTL+English text in Cowork is unreadable. Words scramble, punctuation flips, sentences fall apart.

Cowork is desktop-only with no browser workaround, and most of its RTL users aren't developers. They're lawyers, business owners, medical professionals who just see broken text and give up.

Hebrew, Arabic, Persian. Hundreds of millions of users. Please prioritize this.

As an Arabic-speaking user, I face this exact issue on claude.ai web (not just Desktop/Cowork) — Arabic text mixed with English words becomes unreadable, and the input field also doesn't handle RTL correctly while typing on laptop. This significantly affects daily usability for Arabic speakers.

+1 — this is a real blocker, not a cosmetic one. I'm an Israeli real-estate lawyer and I draft contracts and agreements in Hebrew in Claude Desktop / Cowork every day. Hebrew mixed with English (company names, legal terms, clause references) comes out with scrambled word order and punctuation on the wrong side, which makes reviewing my own drafts genuinely error-prone — exactly the place you can't afford rendering mistakes. dir="auto" on message containers plus LTR-locked code blocks would fix the bulk of it. Please prioritize native RTL support.

Update from testing the current shipping build (v1.15962.1, macOS Apple Silicon):

I read the Electron fuses on the signed app. Every injection-related fuse is locked down:

• EnableEmbeddedAsarIntegrityValidation = Enabled
• EnableNodeCliInspectArguments = Disabled
• RunAsNode = Disabled
• EnableNodeOptionsEnvironmentVariable = Disabled

This is a properly hardened build — good security hygiene. But it has a direct consequence for RTL: every community workaround (the asar-patch projects) is forced to disable EnableEmbeddedAsarIntegrityValidation and re-sign the app ad-hoc just to inject the RTL CSS. That strips Anthropic's signature, breaks on every auto-update, triggers Gatekeeper "damaged", and in multiple reports breaks MCP servers (the injected RTL JS leaks into Node host files with no DOM).

Net effect: because the app is correctly hardened, the large RTL-language user base has no safe self-serve fix. The only safe path is native support.

The fix remains minimal on your side — the unicode-bidi: plaintext rule (~2 lines) I documented earlier in this thread, at the existing did-finish-load → insertCSS injection point. It sets per-paragraph direction on text elements only and explicitly keeps code/pre LTR, so layout and technical content are untouched.

This is a genuine accessibility gap (per-paragraph BiDi / WCAG) affecting Hebrew, Arabic, Persian, Urdu and more. Could the a11y / Cowork team prioritize it? Happy to help validate a build.

I'm a native Arabic speaker and this bug makes Claude Desktop on Windows genuinely difficult to use for daily work. Arabic text renders with scrambled word order, misplaced punctuation, and broken alignment — both in my own messages and in Claude's responses, especially when Arabic is mixed with English (which happens constantly in technical conversations).
This isn't a cosmetic issue — it directly affects usability for the ~400M Arabic speakers who might otherwise use this product. Native RTL support (proper dir="auto" handling on message containers, with code blocks forced to LTR) would fix this without requiring users to resort to unofficial third-party patches that modify signed binaries just to get readable text.
Would really appreciate this being prioritized. Happy to help test a fix if needed.

אני משתמש בעברית ומאד מפריע לי שהטקסט הוא לא RTL

This (very serious) bug appears also in the new linux claude-desktop app.

Feature Request: RTL (Right-to-Left) Support in Claude Desktop for Windows
Claude Desktop for Windows has no support for right-to-left (RTL) text rendering. When responses are in Persian (Farsi), Arabic, or Hebrew — especially when mixed with English words or technical terms, which is extremely common — the Unicode BiDi algorithm scrambles word order and punctuation placement, making the text unreadable.
This affects hundreds of millions of native RTL-language speakers (Persian, Arabic, Hebrew) and makes the desktop app effectively unusable for extended conversations in these languages. On the web version, third-party browser extensions can patch this, but the desktop app has no equivalent workaround available.
Suggested technical fix:

Add dir="auto" or unicode-bidi: plaintext to message container elements, so direction is detected automatically based on the first strong character.
Keep code blocks (pre, code) forced to LTR even inside RTL messages.
Optionally, provide a manual toggle for users who want explicit control over direction.

This has already been reported as a duplicate issue multiple times (e.g. #38005, #16814, #12635). Given how many independent reports exist, it would be great to see this prioritized.
Thank you!

For anyone hitting this — I built rtlwrap, a small wrapper that fixes RTL/Arabic/Persian/Hebrew rendering for any terminal program, including Claude Code's full-screen UI. No patches to Claude Code or your terminal needed:
rtlwrap claude
It works by running the program on a PTY and reshaping text in transit. Might not be the "official" fix this issue is asking for, but it solves the immediate pain today. Happy to take feedback if anyone tries it.

We rely on Claude Desktop and Cowork for daily Arabic work (reports, meeting minutes, formal correspondence), and the missing RTL support makes mixed Arabic/English content very hard to read. Community patches exist, but they break Cowork's signature verification — so we can't have both Arabic readability and Cowork.

A simple dir="auto" on message containers and the input field (keeping code blocks LTR) would fix this for 500M+ RTL-language speakers. Would gladly test a beta.

Adding a concrete use case to weigh in on priority.

I run a small accounting office and rely on Claude Desktop daily — specifically Cowork and Computer Use for local automation (scheduled morning tasks, working with local files/spreadsheets, etc.). All of my work is in Hebrew.

The lack of RTL support isn't just a cosmetic issue for me: since the work requires local file access (Cowork/Computer Use), switching to claude.ai in a browser tab isn't a real option — the browser version already handles Hebrew RTL correctly, but it can't do the local-file/automation work I need. So right now there's no way to get both RTL text and Cowork/Computer Use at the same time.

A community patch exists (shraga100/claude-desktop-rtl-patch) that adds RTL via ASAR injection, but it requires replacing the app's code-signing certificate and adding it to the Windows trusted root store — which most business users (myself included) aren't comfortable doing on a work machine, for good reason.

Would genuinely appreciate native RTL support in Desktop/Cowork — even a basic unicode-bidi: plaintext rule on message containers (keeping code blocks LTR) would cover the vast majority of the pain point. Happy to test a build if one becomes available.

We ran into this at Locstars (we do translation/localization, so we work in RTL daily) and built a fix, which surfaced something worth flagging for the desktop side.
The web fix is small. Setting dir="auto" on message containers — or unicode-bidi: plaintext on prose elements — plus keeping pre/code at direction: ltr and isolating math/arithmetic in LTR spans, resolves Arabic/Hebrew/Urdu/Persian rendering without regressing LTR content. We implemented exactly this as an unofficial, open-source browser extension — live on the Chrome Web Store (listing), full source at github.com/LocstarsLLC/locstars-claude-rtl. It collects no data and handles mixed RTL/LTR sentences, lists, tables, code blocks, and the composer, live during streaming. The detection engine and CSS rules are small and self-contained — happy to contribute them directly.
The desktop app is a different story — and only Anthropic can fix it. On Windows the desktop app is an MSIX package under the protected WindowsApps folder (signed + tamper-checked + auto-updating), and remote debugging is disabled in the production build (--remote-debugging-port yields no reachable endpoint, even when the flag is reliably passed via Invoke-CommandInDesktopPackage). So no third-party extension or patch can fix RTL on desktop without compromising app integrity — which isn't something anyone should ask users to do.
The good news: the desktop client renders claude.ai web content, so a native RTL fix on the web app fixes the desktop app at the same time — one small change covers both surfaces. That's the ask: apply the dir="auto" + minimal unicode-bidi fix natively. We're glad to contribute the exact rules and test cases.