[BUG] CJK text completely unusable over SSH + tmux — compound rendering failures

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?

Claude Code is completely unusable for CJK (Chinese/Japanese/Korean) text when accessed over SSH through tmux. Three independent rendering failures compound into an unreadable, un-typeable experience. This is a critical gap for the remote SSH use case.

Environment

• Claude Code version: 2.1.80
• Server: macOS 26.2 (Apple Silicon), tmux 3.5a
• Client: iOS Termius (SSH) — also reproduced with other SSH clients
• TERM: tmux-256color
• Locale: en_US.UTF-8
• Auth: Claude Max (OAuth token for remote)

Three Independent Failures

1. Ink TUI render position drift in tmux (related: #29937)

Ink's full-buffer redraw mechanism loses sync with actual terminal cursor position inside tmux. After several tool calls or permission prompts, Chinese text from different render cycles overlaps and overwrites previous output. The corruption is in Ink's virtual buffer, not the terminal — neither Ctrl-L nor tmux redraw fixes it.

Without tmux (direct SSH): rendering is correct.
With tmux: progressive drift until unreadable.

2. iOS IME composition sequence dropped (related: #15705)

iOS terminal apps (Termius, etc.) emulate CJK input composition via a delete-and-reinsert sequence:

U+3131 (ㄱ) → DEL (0x7f) → U+AC00 (가)    # Korean
partial char → DEL → final char              # Chinese pinyin

Claude Code's input handler processes the DEL before the final character arrives, resulting in the composed character being silently dropped. The user types Chinese/Korean but nothing appears.

Gemini CLI and Codex CLI handle this correctly — they have proper grapheme cluster processing that waits for the full composition sequence.

This is not tmux-specific — it happens over direct SSH too, but is far more noticeable when combined with the rendering issues above.

3. Character width table mismatch between tmux and terminal

tmux's internal wcwidth() implementation may disagree with the client terminal's character width table for CJK double-width characters. When tmux thinks a character is 1-cell wide but the terminal renders it as 2-cell wide (or vice versa), all subsequent characters on that line shift, causing overlapping or gaps.

Mitigation: tmux -u + set -ga terminal-overrides ',*:UTF-8' helps but doesn't fully resolve it.

Steps to Reproduce

1. SSH into a Mac/Linux server from a mobile terminal (Termius iOS, or any SSH client)
2. Start a tmux session: tmux -u new -s test
3. Run claude inside tmux
4. Have a multi-turn conversation involving Chinese or Korean text
5. Observe: (a) output text overlaps after a few exchanges, (b) typed CJK characters disappear on iOS

Expected Behavior

CJK text should render correctly and be typeable, same as outside tmux and same as competing CLIs (Gemini CLI, Codex CLI).

Actual Behavior

• Chinese/Korean output progressively corrupts until unreadable
• CJK input from iOS is silently dropped
• Combined effect: Claude Code is completely unusable for CJK users over SSH+tmux

Workarounds

| Issue | Workaround |
|-------|------------|
| TUI drift | /clear to reset (loses visual context) |
| iOS IME | Copy-paste Chinese instead of typing |
| Width mismatch | tmux -u + UTF-8 terminal overrides |

Why This Matters

Remote SSH access (laptop → server, or phone → home machine) is a primary use case for CLI tools. tmux is the standard way to maintain session persistence over SSH. CJK languages cover ~1.5 billion native speakers. The combination of these three being broken means a large user segment effectively cannot use Claude Code remotely.

Gemini CLI and Codex CLI both work correctly in this exact environment, which suggests this is solvable.

Related Issues

• #29937 — TUI rendering corruption in tmux (Linux, 20 days open)
• #15705 — Korean input disappears on iOS SSH (83 days open, marked stale)