RTL (Right-to-Left) text direction support
Preflight Checklist
- [x] I have searched existing requests and this feature hasn't been requested yet
- [x] This is a single feature request (not multiple features)
Problem Statement
Claude Code currently has no RTL support in its interface. For users who work in Hebrew, Arabic, or other RTL languages, this creates a significant usability problem:
When Claude responds with mixed Hebrew/English text, the display breaks and becomes difficult to read
There is no way to configure text direction in the conversation window
Users have to "guess" what is written due to incorrect text rendering
Request: Add RTL/bidirectional text support to the Claude Code interface (CLI + VSCode extension), similar to how VS Code handles RTL in the editor.
This would benefit all users writing in Hebrew, Arabic, Persian, and other RTL languages.
Proposed Solution
Add CSS direction: rtl and unicode-bidi: embed support for the conversation
pane, either:
- Auto-detect based on the dominant language of each message
- Add a user setting to force RTL mode globally
- Apply per-paragraph bidi algorithm (Unicode Bidirectional Algorithm - UBA)
This is standard browser/CSS behavior and should be relatively low-effort to implement
in the VSCode extension UI.
Alternative Solutions
_No response_
Priority
High - Significant impact on productivity
Feature Category
Interactive mode (TUI)
Use Case Example
- I work in Hebrew and English daily (Parallels reseller, Israel/MEA market)
- Claude responds with mixed Hebrew/English text
- The text renders LTR, making Hebrew unreadable — letters appear reversed
and words break incorrectly
- With RTL support, Hebrew users could read responses clearly without
having to copy text to another app to understand it
Additional Context
_No response_
10 Comments
Found 3 possible duplicate issues:
This issue will be automatically closed as a duplicate in 3 days.
🤖 Generated with Claude Code
+1 — Same issue here on the Claude Code desktop app (Electron) on Windows 11.
When typing or reading mixed Hebrew + English text, the line direction keeps flipping with every language switch, making it very hard to follow context. This affects both the input box and Claude's responses.
Environment:
Since Chrome extensions (like "Claude RTL") can't be installed in the Electron app, there is currently no workaround for desktop app users.
Would love to see at least a
direction: rtl/ auto-detect option in the app settings. 🙏+1 — This is a daily pain point for me as a Hebrew speaker using Claude Code in the VS Code extension.
My specific issue: When writing Hebrew with English terms mixed in (very common in dev conversations, e.g. referencing function names, file paths, or technical terms), the BiDi algorithm breaks the visual order of the sentence, making it hard to read.
What I've tried:
dalirnet.rtl-markdown,SarbandAkray.rtl)editor.unicodeBidi: "auto"in VS Code settingsWhat would help:
dir="auto"to message containers in the webview HTMLunicode-bidi: plaintextCSS to chat message elementsI’m joining this request! this is extremely critical.
+1
+1 I'm experiencing this issue as well. RTL language support is essential for a large portion of users, and the lack of proper right to left text direction makes Claude Code very difficult to use. Would love to see this addressed!
+1 — adding a specific surface that isn't mentioned above yet: Plan Mode's Plan Viewer (the panel that shows a plan file for approval) also renders RTL content (Hebrew) left-aligned instead of right-aligned, with the same BiDi issue described in this thread.
To generalize the ask across all the reports in this cluster, it would help if the fix covered every output surface, not just the chat webview:
Two concrete requirements that would resolve this for Hebrew, Arabic, and Persian alike:
direction: rtl(right-aligned), consistent with standard Unicode Bidirectional Algorithm behavior in browsers/markdown renderers.Applying
dir="auto"+unicode-bidi: plaintext(as suggested above) to all three surfaces, not just the chat webview, would cover this.+1 from a daily Hebrew user on Claude Desktop (Windows 10).
My entire workflow runs in Hebrew and the mixed-direction rendering makes long responses genuinely hard to read: any English token inside a Hebrew sentence (tool names, metrics like "CTR 17%", file paths) breaks the line direction, punctuation jumps to the wrong side, and bullet lists with mixed content become scrambled.
This affects every Hebrew, Arabic and Persian speaking user, hundreds of millions of potential users write RTL. Even a minimal fix would help enormously:
Happy to provide screenshots or test builds. Thank you!
Persian/Arabic user here. I want to add something I haven't seen in this thread: what specifically triggers the breakage, and a workaround that has been getting me most of the way there. It applies to all three surfaces — the terminal, the VS Code extension, and the desktop app.
The trigger is inline language mixing
When Claude 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.
Workaround: ask for one language per paragraph
I instruct Claude 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:
unicode-bidi: plaintexton prose containers plus an explicitdir="ltr"on code elements gets that for free.For anyone blocked right now: the one-language-per-paragraph instruction is a usable stopgap in the meantime.
For anyone hitting this in the terminal: I built a plugin that lays right-to-left replies out right-to-left in the Claude Code TUI. It's MIT-licensed: https://github.com/MohammedSaud404/rtl-terminal
!The same Arabic reply in Claude Code, without and with rtl-terminal
It right-aligns RTL paragraphs, puts bullets and numbers on the right, fixes backwards brackets, keeps code and links left-to-right, and works for Hebrew, Arabic, Persian, Urdu and other RTL scripts. Levels come from the full Unicode Bidirectional Algorithm (bidi-js, which passes all 91,707 cases of Unicode's BidiCharacterTest).
To be clear about scope: it works where Claude Code reorders RTL text itself, which is Windows Terminal, conhost, and VS Code's integrated terminal on any OS. In other macOS and Linux terminals, Claude Code strips the Unicode direction marks before they reach the terminal, so the plugin steps aside there. It doesn't cover the desktop app or the VS Code extension panel; those need a text-direction option in the plugin API (#99956).
Native RTL support is still the real fix. This is a way to read RTL comfortably until then.