Feature request: RTL (Hebrew/Arabic) support in the Claude Code Desktop app, or a supported way to apply custom CSS

The ask

Two things, either of which would solve this for RTL-language users of the Claude Code Desktop app:

1. Native RTL rendering for chat content — the real fix.
2. Failing that, a supported extension point for user styles (a user-stylesheet file, or a documented setting to apply custom CSS/JS to renderer views), so RTL users are not forced into DevTools workarounds that break on every release.

Why this matters

Hebrew and Arabic are right-to-left. In the desktop app, Claude Code sessions currently render RTL content as if it were LTR:

• Ordered/unordered list markers sit on the left of Hebrew items, so numbered steps read backwards.
• Mixed Hebrew+English paragraphs (extremely common in code discussions — Hebrew prose, English identifiers) resolve to LTR when the first strong character is Latin, pushing the Hebrew to the wrong edge.
• Tables keep LTR column order.
• The composer does not follow the typed language.

The result is that reading a long Claude Code answer in Hebrew is genuinely hard, which is a shame because the product is otherwise excellent for us.

What we do today, and why it is not sustainable

We maintain a small open-source companion (https://github.com/Sabarhealth/claude-rtl-companion): a DevTools snippet that tags elements with dir and applies logical-property CSS, plus a launcher that re-applies it. No app files are modified — it is snippet-in-DevTools only, deliberately, to avoid touching app.asar.

It works, but it depends on internals that shift with releases. Over roughly three weeks, across 1.22209 → 1.25927 → 1.26832 → 1.30096, we had to adapt to:

• DevTools window titles changing format three times, and later being wrapped in Unicode bidi control marks (U+202A…U+202C), which broke window matching.
• The dev-tools permission moving from config.json to developer_settings.json.
• DevTools opening docked instead of as a separate window.
• The app shell becoming a local Vite renderer, with chat content in a WebContentsView that Ctrl+Alt+I and even "Show All Dev Tools" cannot attach to — so DevTools-based injection is unreachable on the current build and only the main-process inspector remains.

None of this is anyone's fault: we are relying on internals, and internals change. That is exactly the argument for a supported path.

Suggested minimal option

If full RTL is a large change, a much smaller step would already help enormously:

• Honor dir="auto" (or apply the bidi algorithm) on rendered message content and list containers, and use CSS logical properties (padding-inline-start, text-align: start) for markers and indentation.

That alone fixes the majority of the readability problems, without any user-facing setting.

Environment

• Claude Code Desktop app on Windows 11 (MSIX), reproduced on 1.22209.3.0 through 1.30096.5.0
• Windows display language: Hebrew

Related: #87309 (RTL-mirrored window renders a duplicate preview-pane layer).

Happy to share our CSS and dir-tagging rules — they are small, and most of the logic is "use logical properties and let the bidi algorithm work". We are also glad to test preview builds.

🤖 Generated with Claude Code on the user's behalf