Mixed RTL/LTR text (Arabic + English) renders with scrambled bidi order in chat panel

Problem

In the Claude Code VS Code extension chat panel, content that mixes Arabic (RTL) with English code spans or technical terms is rendered inside an LTR-context container. The Unicode bidi algorithm then reorders mixed-direction runs in ways that look scrambled to a human reader: English code spans like post_type and based_on appear in unexpected positions within Arabic sentences, making the response hard to follow.

This is a common case for Arabic-speaking developers, who naturally mix Arabic prose with English identifiers, code, and technical terms when chatting with the assistant. The same issue affects Hebrew, Persian, Urdu, and any other RTL language.

Reproduction

1. Open Claude Code in the VS Code extension panel.
2. Send a message such as:

> اشرحلي الفرق بين post_type و prompt_template_key في الـ news service، ولو شيلنا الـ based_on field هيحصل ايه؟

1. Observe the response. English code spans appear out of expected reading order inside the Arabic sentences.

Expected behavior

Each rendered paragraph should pick its base direction from its first strong character (Arabic → RTL paragraph, English → LTR paragraph), with the other-direction runs treated as isolates rather than reordered into the parent context.

Workarounds attempted (all failed)

1. Wrapping responses in <div dir="auto"> — the markdown renderer in the chat panel escapes raw HTML, so the tags appear as literal text in the output.
2. VS Code font / editor settings — the chat panel is a sandboxed webview and does not inherit editor.fontFamily, editor.wordWrap, or related editor settings.
3. Custom CSS injection via Custom CSS and JS Loader extension — the injection lands in the workbench shell but does not penetrate the webview iframe's CSP, so it has no effect on chat content.

Proposed fix

A one-line CSS change in the chat panel webview's stylesheet:

/* Apply to the rendered message container — whatever class the extension uses */
.message-body,
.markdown-body {
  unicode-bidi: plaintext;
}

Or equivalently, set dir="auto" on the rendered message container element in the webview template.

Both approaches make every paragraph infer its direction from the first strong character. Effects:

• Pure-English responses: unchanged (LTR).
• Pure-Arabic responses: render correctly RTL.
• Mixed Arabic + English responses: each paragraph picks the dominant direction; embedded other-direction runs render as isolates instead of being merged into the parent's context.

unicode-bidi: plaintext is a CSS-defined safe default for displaying user-generated text of unknown direction — it is the recommendation in the CSS Writing Modes spec and in the HTML <bdi> element documentation.

Why the user can't fix this themselves

VS Code exposes no setting to control text direction in chat panels or webviews (microsoft/vscode#86667 — RTL support, open since 2019). The chat panel's webview content and CSS are owned by the Claude Code extension, so this is the only layer that can fix it.

Environment

• OS: Windows 11
• VS Code: 1.96.x (latest stable)
• Claude Code extension: latest
• Affected locales: Arabic (verified), expected to also affect Hebrew, Persian, Urdu, Yiddish, Mandaic, and any other RTL script.

Severity / Audience impact

This blocks usable Arabic-language interaction with Claude Code in VS Code. The model already responds correctly in Arabic; the rendering layer is what makes the output unreadable. A one-line CSS change unlocks a large user base (Arabic alone is ~400M speakers).