RTL (Arabic/Hebrew) text renders reversed in all Claude Code TUI surfaces — assistant messages, tool-result previews, and live input

Environment

• Claude Code 2.1.245
• Terminal: Warp
• OS: Linux Mint 22.3 (kernel 7.0.0-28-generic)

Summary
RTL text (tested with Arabic) is not bidi-reordered anywhere in Claude Code's own terminal rendering. Confirmed in three distinct surfaces, all drawn by Claude Code itself:

1. Assistant message text — when Claude's own response includes Arabic (e.g. quoting a test string back to the user), it renders reversed in the transcript, even though the underlying string is correct (verified by writing the same string to a file and reading it back with an external bidi-aware tool — see comparison below).
2. Tool-result file preview — inline preview of file content (e.g. from the Write tool) containing Arabic renders reversed, even though the file's actual bytes on disk are correct.
3. Live input box — typing Arabic directly into the prompt renders it reversed character-by-character in real time, before submission.

Repro

1. Ask Claude Code to include an Arabic sentence in its reply, or to write one to a file and quote it back. Observe the Arabic renders reversed in the assistant's message.
2. Have Claude Code write that Arabic sentence to a file via the Write tool; observe the inline tool-result preview also renders it reversed.
3. Type any Arabic sentence directly into the prompt; observe it renders reversed live as you type, before you even submit.
4. Comparison (proves the data is fine, only Claude Code's rendering is wrong): read the same file's raw content afterward via a plain external command, outside Claude Code's TUI (e.g. cat file.txt, or piped through fribidi -c UTF-8 for full bidi correctness). The text displays correctly there — confirming the bug is isolated to Claude Code's own rendering paths, not the terminal (Warp) globally and not the underlying data.

Related existing reports: #34134 (closed not-planned), #38656, #45652, #48559, #29545, #29575, #29662, #29710, #75240 — this report's contribution is isolating that it's all three TUI-internal surfaces (not just one), plus a working comparison case proving the file data itself is correct and only Claude Code's own text rendering is at fault.

Suggested direction: apply the Unicode Bidirectional Algorithm to text before rendering in the message/transcript renderer, the tool-result preview renderer, and the input line editor — all three appear to share the same missing step.

Screenshots to follow in a comment.