[BUG] RTL text rendering broken when Hebrew and English are mixed in the same line (Desktop app)

Preflight Checklist

• [x] I have searched existing issues and this hasn't been reported yet
• [x] This is a single bug report (please file separate reports for different bugs)
• [x] I am using the latest version of Claude Code

What's Wrong?

Environment

• Claude Code Desktop app on Windows 11 Enterprise (10.0.26200)
• Desktop app version: 1.17377.2 (Microsoft Store install)
• Claude Code version: 2.1.197
• Display language of content: Hebrew (RTL)

Description

When Claude's responses contain Hebrew (RTL) text mixed with English (LTR) words in the
same line, the rendering is garbled: word order flips, English terms jump to the wrong
side of the sentence, and punctuation lands on the wrong end of the line.

Lines that are purely Hebrew render fine. The problem appears specifically in
mixed-direction (bidi) lines, which are very common in technical conversations —
Hebrew sentences naturally contain English file names, commands, product names, etc.

Steps to reproduce

1. Open Claude Code Desktop.
2. Ask Claude to answer in Hebrew about a technical topic, e.g.:

תסביר לי בעברית מה עושה הפקודה git rebase ומה ההבדל בינה לבין merge

1. Look at any response line that mixes Hebrew words with English terms.

Expected behavior

Mixed Hebrew/English lines should follow the Unicode Bidirectional Algorithm with the
paragraph direction detected from the first strong character (equivalent to
dir="auto" on the rendered message elements), so Hebrew sentences stay right-to-left
and embedded English terms display as inline LTR runs in their correct position.

Actual behavior

The visual order of words in mixed lines is scrambled — English words appear on the
wrong side of the Hebrew text and punctuation is misplaced, making the text very hard
to read.

Suggested fix

Render markdown message blocks (paragraphs, list items, table cells) with dir="auto"
(or explicit bidi isolation per element), so each block picks up RTL direction when it
starts with a strong RTL character.

<img width="2026" height="188" alt="Image" src="https://github.com/user-attachments/assets/e611b6ef-f021-475d-892c-7c3da2b5160c" />

What Should Happen?

Mixed Hebrew/English lines should follow the Unicode Bidirectional Algorithm, with the
paragraph direction detected from the first strong character (equivalent to setting
dir="auto" on the rendered message elements).

In practice this means: a sentence that starts with a Hebrew word should be rendered
right-to-left, with any embedded English terms (file names, commands, product names)
displayed as inline left-to-right runs in their correct logical position within the
sentence, and punctuation appearing at the correct end of the line.

Purely Hebrew lines already render correctly — only mixed-direction lines are broken.

Error Messages/Logs

Steps to Reproduce

1. Open the Claude Code Desktop app on Windows (tested on Windows 11 Enterprise,

app version 1.17377.2, Claude Code 2.1.197).

1. Start a new conversation and send a prompt that makes Claude reply in Hebrew

about a technical topic, so the response naturally mixes Hebrew (RTL) text with
English (LTR) terms. For example, send this prompt:

תסביר לי בעברית מה עושה הפקודה git rebase ומה ההבדל בינה לבין merge

1. Read the response. Any line that contains both Hebrew words and English terms

(e.g. "git rebase", "merge", file names, command names) renders garbled:
the visual word order flips, English terms appear on the wrong side of the
Hebrew sentence, and punctuation lands on the wrong end of the line.

1. For comparison, note that lines containing only Hebrew render correctly —

the bug is limited to mixed-direction (bidi) lines.

No special files or project setup are required — the issue reproduces in any
conversation where the response mixes Hebrew and English in the same line.

Claude Model

None

Is this a regression?

Yes, this worked in a previous version

Last Working Version

_No response_

Claude Code Version

2.1.197

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

PowerShell

Additional Information

_No response_