CJK text corrupted (mojibake) when copying terminal output — no-flicker/fullscreen renderer is the cause; tui: "default" fixes it [macOS + OrbStack]

Summary

When the no-flicker / fullscreen renderer is active ("tui": "fullscreen" in settings, equivalent to CLAUDE_CODE_NO_FLICKER=1, which is the default), copying CJK (Chinese) text out of the terminal produces mojibake on the clipboard. The text renders correctly on screen, but the copied bytes are corrupted, so it pastes garbled into any destination (another app, a web form, the Claude Code prompt itself).

Switching to the classic renderer with "tui": "default" completely fixes it — a clean, deterministic toggle.

This is the copy-out / output direction, on macOS, and is distinct from the previously reported Windows paste-in issues (#65806, #3961).

Environment

• Claude Code: 2.1.168
• Node: v22.22.2
• Terminal: VS Code integrated terminal v1.123.0 (TERM_PROGRAM=vscode, TERM=xterm-256color)
• OS: macOS 15.7.7 Sequoia (build 24G720) host, with Claude Code running inside an OrbStack Linux VM (Linux 7.0.5-orbstack x86_64)
• Locale: C.UTF-8 (full UTF-8; display/fonts correct)
• Trigger setting: "tui": "fullscreen" (≡ CLAUDE_CODE_NO_FLICKER=1) — the default
• Fix setting: "tui": "default"

Steps to reproduce

1. Ensure "tui": "fullscreen" (default) in ~/.claude/settings.json.
2. Start claude in the VS Code integrated terminal.
3. Have Claude print some Chinese text, e.g. 陳嗣森 你好世界. It renders correctly.
4. Select that Chinese text in the terminal and copy it (Cmd+C). Holding Shift to force native xterm.js selection does not help.
5. Paste into any destination — a text field, Gmail, or back into the Claude Code prompt.

Expected behavior

The pasted text matches what was on screen: 陳嗣森 你好世界.

Actual behavior

The pasted text is mojibake — UTF-8 bytes interpreted as Latin-1/Windows-1252 (e.g. 中文 → 中文), and in some cases bytes are dropped, yielding invalid UTF-8. The exact garble varies by content.

Root cause (deterministic toggle)

Setting "tui": "default" in ~/.claude/settings.json and restarting Claude Code fixes the corruption — copying terminal output then yields correct CJK in all destinations. Setting it back to "fullscreen" reintroduces the corruption. So the defect is in the no-flicker / fullscreen (alt-screen) renderer's handling of wide (double-width) characters on the copy/selection path.

What is NOT the cause (isolation evidence)

Tested by holding the paste-target constant and varying the source:

| Source of copy | Result |
|---|---|
| Native macOS app (web page) → paste anywhere | ✅ clean |
| VS Code editor tab → paste anywhere | ✅ clean |
| Paste into the Claude Code prompt (from a clean source) | ✅ clean |
| Claude Code terminal output → paste anywhere (tui: fullscreen) | ❌ garbled |
| Claude Code terminal output → paste anywhere (tui: default) | ✅ clean |

So the macOS clipboard, the VS Code editor's clipboard path, OrbStack's byte delivery (the glyphs render correctly, proving correct UTF-8 reaches the terminal), and the paste/input path are all fine. The only variable that breaks it is the Claude Code fullscreen renderer.

Workaround

Set "tui": "default" in ~/.claude/settings.json and restart. Trade-off: the classic main-screen renderer flickers more on redraws and loses the alt-screen virtualized scrollback.

Related

• #65806 — Korean (CJK) paste-in mojibake on Windows via the no-flicker renderer (closed not-planned). Same renderer, opposite direction, different platform.
• #3961 — earlier related report, closed stale.

This report adds: macOS, the copy-out direction, and a deterministic tui toggle that turns the bug on and off.