[BUG] Mixed Arabic/English (RTL+LTR) input renders scrambled with wrong cursor position in macOS Terminal.app (v2.1.278)

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?

Typing a prompt that mixes Arabic (RTL) and English (LTR) on the same line in the Claude Code input box scrambles the display: word order flips, Arabic letters get disjointed, and the cursor lands in the wrong column. Arabic-only lines are also affected, but mixed lines are the worst case and are the norm for Arabic-speaking developers (identifiers, file names and commands are always English).

The text that actually reaches the model is correct, so this is purely a TUI rendering / cursor problem.

This is a regression introduced between 2.1.275 and 2.1.278. On 2.1.275 (installed 2026-09-18, used all day 2026-09-19) mixed Arabic/English input rendered correctly in this same Terminal.app window. Right after claude install moved to 2.1.278 (2026-09-19 15:47) the input box started scrambling. Nothing else on the machine changed (same macOS 27.0, same Terminal.app 488, same zsh, same font, same locale).

Notes from comparing the 2.1.275 and 2.1.278 binaries (source isn't public):

• The input component draws characters column by column assuming LTR and derives the cursor column from string offsets. Terminal.app then applies its own native bidi reordering on top, so the two reorderings fight each other.
• 2.1.278 adds a new pre-send prompt sanitiser (tengu_prompt_invisible, "Removed N invisible characters … review and press Enter to send", from the 2.1.277 changelog entry "invisible Unicode formatting and tag characters in a prompt are removed") plus new stripping/replacement of Unicode directional controls (U+061C ALM, U+202A–U+202E embeddings/overrides, U+2066–U+2069 isolates). None of these code paths exist in 2.1.275. That is the most likely culprit for the regression, and it also makes explicit isolates (RLI/LRI/PDI) unusable as a user-side workaround.
• There is still no RTL/bidi-aware rendering path in the CLI build. The fixes shipped in 2.1.69 (VS Code extension) and 2.1.74 (Windows Terminal + VS Code integrated terminal) did not cover Terminal.app on macOS.

Terminal.app itself renders bidi correctly: echo "تجربة test مرحبا" in plain zsh displays properly in the same window.

What Should Happen?

Mixed Arabic/English input should display in logical order with the cursor at the right position, exactly as it did on 2.1.275 and as it does in plain zsh in the same Terminal.app window.

At minimum: don't strip or replace directional control characters from the prompt, and let the terminal's native bidi handle the line (Terminal.app, iTerm2 3.6+ and kitty all do).

Error Messages/Logs

(no errors - display-only issue)

Steps to Reproduce

1. macOS 27.0 (arm64), Terminal.app (TERM_PROGRAM=Apple_Terminal, TERM_PROGRAM_VERSION=488), LANG=en_NZ.UTF-8, zsh, no plugins.
2. Run claude (2.1.278 (Claude Code)).
3. In the prompt box type: افتح الملف AppDelegate.swift وشوف الـ crash في viewDidLoad
4. Observe while typing: word order is reversed/jumbled, Arabic letters lose their joined (cursive) forms, and the cursor is offset from where the next typed character actually appears. Press Left/Right arrows: the cursor moves in a visual order that doesn't match the logical order, so editing the middle of the line is guesswork.
5. Control A: exit claude and type the same string at the zsh prompt, or echo "..." it. It renders correctly, so the terminal is not the problem.
6. Control B: run the previous build still on disk, ~/.local/share/claude/versions/2.1.275, and type the same string. It renders correctly.

Claude Model

Other

Is this a regression?

Yes, this worked in a previous version

Last Working Version

2.1.275

Claude Code Version

2.1.278 (Claude Code)

Platform

Anthropic API

Operating System

macOS

Terminal/Shell

Terminal.app (macOS)

Additional Information

• Previous reports #34134 (this exact terminal + OS), #48559, #45652, #12635 and #11050 were all auto-closed as stale without a fix or a maintainer comment. Please don't stale-close this one: Terminal.app is the stock terminal on macOS, this worked three builds ago, and the fix that shipped for VS Code / Windows Terminal shows the problem is tractable.
• Checked defaults read com.apple.Terminal and the Terminal.app binary: there is no user-facing bidi setting to toggle on the terminal side, so stock-terminal users have no workaround.
• Happy to test a build / provide screen recordings.