Composer has fixed LTR base direction — RTL text (Arabic/Hebrew) renders scrambled while typing

Description

Typing an RTL sentence that contains any Latin-script token (product name, command, IP address) renders scrambled while typing in the composer. After the message is sent, the same text renders correctly.

The character data is never corrupted — this is purely a display bug in the composer.

Steps to reproduce

1. Open the Claude desktop app
2. Click into the message composer
3. Type an Arabic sentence containing an English word:

انا عندي Synology NAS وعايز اشغل عليه MCP server

1. Watch the text as you type

Expected behavior

The paragraph lays out right-to-left, with the Latin words correctly positioned inside it.

Actual behavior

The paragraph lays out left-to-right. Punctuation jumps to the wrong side and Latin words land in the wrong position, making the sentence unreadable while composing.

Send the message and it displays correctly — confirming the logical character order was right the whole time.

Root cause

The composer has a fixed LTR base direction. Under the Unicode Bidirectional Algorithm, a paragraph's base direction governs how mixed-direction runs are ordered. Because the composer is treated as an LTR paragraph, Arabic text inside it is laid out as a foreign run rather than as the paragraph's primary direction.

Sent messages render correctly, which suggests message bubbles already resolve direction from content while the composer does not.

Suggested fix

Derive the composer's base direction from its content instead of fixing it to LTR:

.composer, .composer p, .composer div {
  unicode-bidi: plaintext;
  text-align: start;
}

Or the HTML attribute equivalent:

<div contenteditable="true" dir="auto">

Both make each block take its direction from its own first strong directional character. Arabic-first sentences become RTL, English-first sentences stay LTR. No manual toggle, and zero effect on LTR-only users.

Implementation note: the dir attribute alone is not sufficient in React-based editors — re-renders strip it off the element. I hit exactly this while building a browser extension for the same bug: setting dir="auto" via MutationObserver failed because React reset it on every keystroke. Switching to an injected stylesheet fixed it, because the rule lives in the document rather than on the element.

Reproduction test case

Two identical textareas, one default and one with the fix:

<textarea style="direction: ltr; unicode-bidi: normal;"></textarea>
<textarea style="unicode-bidi: plaintext; text-align: start;"></textarea>

Type the same mixed Arabic/English sentence into both. The first scrambles, the second renders correctly. Copying text from the first into the second displays it correctly, proving the character data is intact.

Environment

• Claude desktop app 1.26832.0
• macOS 27.0 (build 26A5388g), Apple Silicon (arm64)
• Arabic input source enabled at OS level

Impact

Affects every user writing in a right-to-left script — Arabic, Hebrew, Persian, Urdu. Mixing Latin technical terms into RTL prose is the norm in technical conversation, so this makes the composer painful to use for that entire user group.

No user-side workaround exists in the desktop app: it supports neither extensions nor custom CSS. I solved it in browsers with a small extension injecting the rule above, but that path is unavailable here.