Arabic (RTL) text is character-reversed in interactive prompt and chat responses on Windows Terminal

Summary

When typing Arabic text directly into the interactive kimi chat prompt, the text is echoed back on screen with every character in reversed order. The same reversal also appears in the assistant's own response text when it contains Arabic mixed with Latin/digits, inside the chat panel Kimi Code draws in the terminal.

Environment

• Kimi Code CLI version: 0.41.0
• OS: Windows 10 Pro (build 10.0.19045)
• Terminal: Windows Terminal (modern build, ConPTY)
• Locale: system locale French (Windows UI), typed content is Arabic (Unicode Arabic block)

Steps to reproduce

1. Open Windows Terminal.
2. Run kimi to start an interactive session.
3. At the > prompt, type the Arabic word مرحبا (logical order: م ر ح ب ا).
4. Observe the prompt line as you type / immediately after pressing Enter.

Expected result

The prompt should echo مرحبا in the correct logical/visual order, right-to-left, exactly as typed. As a working reference, Anthropic Claude Code CLI renders the identical input correctly in the same Windows Terminal window on the same machine.

Actual result

The prompt echoes the text with every character in the opposite order: ابحرم. This is not only alignment/direction; the individual character order is reversed.

The same reversal is visible in multi-line assistant response text mixing Arabic and English/digits, for example مرحبا Hello 123 renders scrambled inside the bordered chat panel.

Additional technical evidence

• This appears specific to the interactive raw-mode input-line editor / redraw path, not Kimi's underlying text generation. kimi -p "<text>" captured to a file returns the Arabic text byte-correct and in the right logical Unicode order.
• A real chunk-timing probe showed non-interactive output arriving as 3 separate stdout writes about 13 ms apart, with one boundary landing between an Arabic word and a following Latin segment. Partial-fragment terminal rendering can compound BiDi problems for mixed RTL/LTR text.
• Pasting Arabic instead of typing it has not been confirmed to solve Kimi specifically.

Suggested area to investigate

The component that redraws the input line/chat panel on each keystroke or content update likely needs proper Unicode BiDi resolution before drawing. Please avoid naively reversing RTL runs. Buffering complete logical lines before rendering and applying directional isolates to embedded Latin/digit runs are practical approaches that worked in a local compatibility wrapper.

Raw logs/stdout should stay in original logical Unicode order; the fix should be in the interactive rendering layer.

Start with the interactive raw-mode input-line editor and chat-panel redraw path on Windows Terminal, since the issue identifies these as the affected areas. Reproduce Arabic input and mixed Arabic/Latin response rendering, compare with kimi -p output, and verify that interactive text preserves logical Unicode order without reversing RTL characters or corrupting chunked output.