Bug: Arabic/RTL text appears reversed in the interactive TUI before and after submission

Summary

When I type Arabic in Kimi Code's interactive terminal UI, the underlying Unicode text is correct,
but the terminal paints it in the wrong visual order and does not reliably shape the letters. The
same sentence can look fixed in the editor and become inverted again immediately after submission,
because the composer and submitted user message use different rendering paths.

In plain language: Kimi understands the Arabic; the interactive TUI displays it incorrectly.

This remains reproducible with the official native Windows x64 Kimi Code 0.34.0 binary.

What version of Kimi Code is running?

• Official Kimi Code CLI 0.34.0
• Official Windows x64 artifact SHA-256:
  36bd5659fb5d310edc06ac6196dac6e7f7528bfdf04d41f3bed9b29caaf4d206
• The screenshot below was captured from that unmodified artifact executed from a temporary folder.
  It was not installed over my active CLI.

Which platform/subscription and model were used?

• Kimi Code managed OAuth subscription (managed:kimi-code)
• K3

The selected model is not material to the bug; it occurs before the prompt reaches the model and in
the local rendering of the submitted user message.

What platform is the computer?

Microsoft Windows NT 10.0.26200.0 x64

Reproduced in classic cmd.exe with UTF-8 transport enabled (chcp 65001). Windows Terminal also
cannot be assumed to provide application-level bidi layout for terminal cell output.

What issue is visible?

I typed the logical text مرحبا بالعالم but did not submit it. This is a direct, sanitized crop of
only the official TUI editor row:

The editor remains a left-to-right terminal line, while the Arabic appears reversed/disconnected.
Mixed Arabic/Latin/numbers and cursor positions are also visually wrong.

Surface	Observed behavior
Interactive composer	Logical Arabic is emitted directly to terminal cells without a bidi visual layout/cursor map
Submitted user message	A separate plain-text path can invert the same Arabic again after send
Non-interactive --prompt	Arabic is preserved correctly, which confirms storage/model transport is not the problem

Steps to reproduce

1. Run official kimi interactively in cmd.exe or Windows Terminal.
2. Type مرحبا بالعالم.
3. Type hello مرحبا 123.
4. Move the cursor through the Arabic run and submit the message.
5. Compare the editor and submitted message with a browser or another bidi-aware renderer.

Control test:

kimi --prompt 'أجب بالنص التالي فقط: مرحباً بالعالم' --output-format text

The response is correct Arabic. Setting code page 65001 is still useful for UTF-8 input/output, but
UTF-8 does not implement the Unicode Bidirectional Algorithm, contextual Arabic shaping, RTL
alignment, mirrored punctuation, or logical-index-to-terminal-cell cursor mapping.

Why there are two bugs to fix together

The composer and transcript do not share one bidi presentation layer:

• packages/pi-tui/src/components/editor.ts builds editor display lines from logical line /
  chunk.text values.
• apps/kimi-code/src/tui/components/messages/user-message.ts renders the submitted user text using
  a separate plain Text path.

An editor-only experiment improved the prompt while typing, but the text became visually inverted
again after submission. A production fix needs one shared renderer for both paths.

Expected behavior

• Arabic is contextually shaped and displayed right-to-left.
• Latin and number runs inside Arabic keep their UAX #9 ordering.
• The logical Unicode string stored and sent to the model remains unchanged.
• Cursor movement, selection, highlighting, wrapping, and truncation map between logical grapheme
  positions and visual terminal cells.
• ANSI/style spans move with complete grapheme clusters.
• Combining marks, emoji ZWJ sequences, and mirrored punctuation remain correct.
• The solution does not double-reorder on terminals that provide native bidi support.

Experiments already completed

1. Arabic Presentation Forms — withdrawn. Emitting U+FE70–U+FEFF produced symbols with the
   active Windows console/font. Presentation Forms are compatibility characters and are not a
   portable terminal fix.
2. Display-only UAX #9 in the editor — incomplete. It improved the composer, but the submitted
   user-message path still failed.
3. Shared display-only proof of concept — promising but needs hardening. It keeps logical Unicode,
   reorders grapheme clusters for display, right-aligns RTL-base physical lines, and covers both
   editor and transcript. ANSI spans, wrapping, cursor mapping, punctuation mirroring, and terminal
   capability/configuration still need a production design.
4. Browser-backed workaround — reliable today. The official kimi web backend/session already
   preserves Arabic. A small local desktop shell embeds it in WebView2 and applies browser-native bidi
   without changing prompt bytes, model access, tools, credentials, or session format.

The presentation policy used by the workaround is:

element.setAttribute('dir', 'auto');
element.style.unicodeBidi = 'plaintext';
element.style.textAlign = 'start';

It is applied at document creation and to future composer/message nodes with a MutationObserver.
pre, code, kbd, and samp remain explicit LTR with unicode-bidi: isolate.

Sanitized result, including separate composer and post-send Arabic checks:

The workaround still depends exclusively on the official local Kimi CLI/Web server. It is evidence
that the backend/session text is correct, not a replacement for an upstream terminal fix.

Validation completed

• @moonshot-ai/pi-tui: 718 passed, 0 failed during the terminal proof-of-concept work.
• Focused submitted UserMessageComponent tests: 6 passed, 0 failed.
• @moonshot-ai/pi-tui typecheck: passed.
• @moonshot-ai/kimi-code typecheck: passed.
• Native Windows build: passed.
• Official 0.34.0 pure-Arabic TUI reproduction: confirmed.
• Browser workaround pure Arabic, English, mixed text, post-send text, and LTR code isolation:
  confirmed.
• Same live Kimi session post-send DOM geometry: logical first word قم is rightmost, followed by
  باكمل, then العملية; direction: rtl and unicode-bidi: plaintext: confirmed.

Suggested upstream architecture

Please add a reusable, ANSI-aware bidi presentation API used by both the editor and transcript. It
should accept logical Unicode plus style spans, resolve paragraph direction with UAX #9, wrap into
physical lines, visually place whole grapheme clusters, and return both terminal cells and a
logical↔visual cursor map. Keep Presentation Forms out of stored/submitted text and include an
explicit terminal capability/configuration strategy so application-side and terminal-native bidi do
not double-reorder.

Recommended tests: pure Arabic, mixed Arabic/Latin/numbers, diacritics, ligatures, emoji ZWJ,
mirrored punctuation, ANSI spans, wrapping, truncation, cursor/selection mapping, and both pre-send
and post-send paths.

Full sanitized evidence and workaround files

The public evidence pack contains the exact cropped reproduction, two sanitized workaround
screenshots, the full validation matrix, bidi-bootstrap.js, and the standalone RTL showcase:

https://gist.github.com/112-stack/4eb8d9eddf4fa0fa17ba570e5f80e70f

No published image or file contains a bearer token, account identity, private transcript, session
identifier, or user workspace path.

Start with packages/pi-tui/src/components/editor.ts and apps/kimi-code/src/tui/components/messages/user-message.ts, then review the shared display-only proof of concept described in the issue. Run the @moonshot-ai/pi-tui tests, focused UserMessageComponent tests, and both package typechecks. Done means one bidi-aware presentation path covers composer and submitted messages while preserving logical text and cursor, wrapping, styling, and grapheme behavior.