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

[reggiechan74]

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

• [BUG] Pasting Korean (CJK) into the prompt is mojibaked (UTF-8 -> Windows-1252) with the no-flicker renderer on Windows (still repros in 2.1.167) #65806 — Korean (CJK) paste-in mojibake on Windows via the no-flicker renderer (closed not-planned). Same renderer, opposite direction, different platform.
• Unicode Input Handling Fails for Vietnamese Characters #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.

[github-actions]

Found 3 possible duplicate issues:

1. New renderer (CLAUDE_CODE_NO_FLICKER=1): Japanese text clipboard copy garbled on Windows (UTF-8 → CP932 mojibake via OSC 52) #42417
2. [BUG] Korean text gets corrupted when copying (via /copy or selection) with new renderer enabled #42482
3. No-flicker mode breaks Korean (CJK) text copy on Windows Terminal #42954

This issue will be automatically closed as a duplicate in 3 days.

• If your issue is a duplicate, please close it and 👍 the existing issue instead
• To prevent auto-closure, add a comment or 👎 this comment

🤖 Generated with Claude Code

[aslom]

Possibly the same renderer subsystem, though my symptom is different from the CJK
mojibake — flagging in case it helps localize the cause.

On macOS + plain iTerm2 with the fullscreen / no-flicker renderer (the default),
copy-on-select reports a successful OSC 52 copy but nothing reaches the macOS
pasteboard at all (not corrupted — simply absent). Setting "tui": "default"
in ~/.claude/settings.json and restarting returns me to native iTerm2 selection
and the problem disappears, matching your "default fixes it / fullscreen
reintroduces it" finding.

So both the corruption you're seeing and the dropped-write I'm seeing sit on the
fullscreen renderer's copy/selection path — your case mangles the bytes, mine
loses the write entirely (in my setup the OSC 52 sequence depends on iTerm2's
"Applications in terminal may access clipboard" permission, which is off by
default). Same code path, two different failure modes. Tracking the no-clipboard-
write case separately in #66192.

Claude Code: 2.1.168 · macOS · iTerm2 · "tui": "fullscreen" (default).

[heishen6]

+1

[weilr]

Is there any other way besides setting "tui": "default"?

[sjals93]

Confirming this is not macOS/OrbStack-specific — same bug reproduces on Linux + VS Code integrated terminal.

Environment

• Claude Code: 2.1.177
• OS: Ubuntu 22.04 (Linux 5.15)
• Terminal: VS Code integrated terminal 1.124.2 (TERM_PROGRAM=vscode, TERM=xterm-256color)
• Locale: ko_KR.UTF-8 (locale is correct — not an encoding-setup issue)

Repro

1. Let Claude Code render Korean (CJK / wide) text to the terminal.
2. Select & copy that rendered output.
3. Paste into any other app (or back into the same terminal) → mojibake / corrupted bytes, even though it looked correct on screen.

Notes

• Only the copy-out path is affected. Pasting CJK text into the prompt works fine on Linux.
• Codex CLI in the exact same VS Code terminal does not have this problem, which points squarely at Claude Code's renderer rather than the terminal.
• Started appearing ~a week ago, consistent with the no-flicker/fullscreen renderer being the default.

Workaround confirmed working: setting "tui": "default" in ~/.claude/settings.json (then restarting the session) eliminates the corruption.

[AmaralVini]

Same bug on Windows + accented Latin characters (this issue is macOS/CJK, but it is the
same fullscreen renderer copy path).

Environment

• Claude Code 2.1.197
• Windows 11 (10.0.26200.8655)
• VS Code integrated terminal 1.124.0, shell cmd.exe + Clink
• tui: "fullscreen"

Repro: mouse-select rendered output containing Portuguese text, Ctrl+C, paste.

Result: UTF-8 decoded as Latin-1/CP1252 in the clipboard; the on-screen display is correct.

Displayed	Copied
é	é
ã	ã
sessão	sessão
índice	índice
não	não

What I ruled out

• Copying the same accented text from a native Windows cmd.exe window works fine.
• Copying non-Claude-Code output (e.g. echo) from the same VS Code terminal works fine.
• Display is always correct, so it is not a console code page issue.
• tui: "default" (or /tui default) fully fixes it, isolating the cause to the
  fullscreen/no-flicker renderer.

Note: Shift+drag (native selection) does not help in fullscreen; the constant redraw
clears the selection before Ctrl+C can act.

Likely the Windows Set-Clipboard copy path encodes as Latin-1 instead of UTF-8. The Windows
CJK variant (#42417) was reportedly addressed in v2.1.97 via Set-Clipboard, but it did not
generalize to accented Latin characters.